Skip to content

Gideon Development Update

Saturday, 9 June 2001  |  Numanee

Two months ago, we announced the birth of Gideon, codename for the next generation version of KDevelop that was most notable for its modularity and extensibility. Since then, Gideon has made enormous strides -- not the least of which includes Java, Perl, Python, PHP and Fortran support, full Python scripting, and an editor framework that will allow one to plug in a favourite editor. Furthermore, thanks to the remarkable efforts of hacker Richard Dale, KDevelop plugins can now be developed in Java. Read on for the full update from Bernd Gehrmann including screenshots and download link.



Bernd Gehrmann writes:

It's been two months since KDevelop's HEAD branch has had a story on the dot. In this time, a lot of functionality has been added, so I thought I'd provide a little update. :-)

  • Java support. Java programs can now be maintained with automake-based project management. Classes are displayed in the class view and class browser. The application wizard includes a template for Java programs based on the Qt/KDE API and using Richard Dale's Koala framework. Furthermore, even KDevelop plugins can now be written in Java. (sic!) This may, for example, be used in the future for a debugger based on the Java Platform Debugger Architecture.

    Screenshot: Debugging the Qt scribble example program in Java.

  • Perl, Python and PHP support. Functions and classes are parsed and available in the class view. The documentation TOCs are integrated into the documentation tree with the documentation index being (partially) searchable. Python docstrings can be browsed dynamically through an ioslave based on pydoc. Work is underway to allow the configuration of php.ini and the usage of the PHP debugger.

    Screenshot: Editing the Sketch program.

  • Fortran support. This includes a frontend for ftnchek and compiler options, dialogs for g77 and the Portland Group compilers.

    Screenshot of Fortran support.

  • A new and flexible editor framework, not yet fully implemented. This will allow one to plug in other editors, even when they have a different feature set than KWrite or use different UI paradigms.

    Screenshot: Editing KDevelop.

  • A port of the gdb debugger frontend from the current KDevelop.

  • Full scripting through Python. The scripting framework needs almost no maintenance. The interfaces of all DCOP classes in KDevelop are automatically available in Python.

  • An integrated Konsole part.

    Screenshot showing the konsole part and some scripting examples.

  • An integration of Artistic Style for indenting source files and configuring the indentation style.

  • A frontend for ctags for "turbo-grepping" through all identifiers in a project.

    Screenshot showing ctags and Artistic style integration.

  • A new view that allows one to view files grouped by their file type. Groups are configurable by the user.

  • An improved application wizard. Apart from the usual KDE and Hello World stuff, this includes templates for kicker applets, KControl modules, KIO slaves, and even GNOME applications.

That's about the main points I recall off the top of my "HEAD". ;-) Of course, many many details have been improved or newly implemented, such as, for example, a Tools menu, an overhauled and much more user-friendly project management interface, automatic loading of the previous project at startup, an improved compiler frontend, etc.

A source snapshot is available here.

There are still many areas where we could use more developers, whether to add features, complete existing ones, or to polish the user interfaces. Please don't hesitate to get involved!

Comments:

Re: KBasic - Carbon - 2001-06-11

I really wasn't saying anything about KBasic in my post above, I was just blabbering about Python. I haven't used KBasic myself, and there's a reason for that : the Basic language itself is sucky. I have yet to seen it done properly, and the closest it ever came to being useful, Visual Basic, was so utterly proprietary, and the IDE was so utterly useless, it was silly. Basic was designed as an introductory language before moving on to something more powerful and useful. In much the same way as the Athera widget set, it was taken beyond this model and people attempted to use it for useful stuff. The result was horrendously difficult to read and just plain stinky. I guess my point is, if you want a language that's easy to learn and still useful, including GUI stuff, try (in the near future :-) KDevelop/Python/PyKDE. Attempting to have people write useful progs or even "Hello World" progs with Basic will just give them bad programming habits. Believe me, I started out on Visual Basic, and the minor inconsistencies with every other language out there (no semicolon at end of statement, '=' having two meanings) wreaked havoc for me . When I started out on PHP, I was constantly and annoyingly assigning variables instead of comparing them in 'if' clauses. Your question isn't disturbing though! Believe me, although Basic specifically is bad, it's always good to have a simplistic, easy-to-learn, RAD-oriented programming language, as long as it's not too proprietary. But perhaps this would really be more suited toward (dun dun dun) Gideon/Python/PyKDE! :-)

Re: Basic and KDE : what policy ? - Carbon - 2001-06-14

Well, that really was my answer : KDE's policy on Basic should be : "No Basic allowed". On the other hand, this is only my opinion. If the majority of the KDE community disagrees with me, then I will bow (grumbling and griping all the way, but still bowing :-) to their vote. Bazaar development is never about a huge group of people, such as the large and wide-spread KDE development team, obeying the commands of only one person. Also, please don't take my posts as a flame against KBasic. I'm absolutely fine with the objectives of KBasic, as long as it's not (IMHO) a language that shouldn't even exist in the first place. Moreover, I would be delighted if the KBasic team proved me wrong and built a Basic-oriented programming tool that knocked everyone's socks off I'm just highly doubtful that this can be done with Basic. Here's why : 1) There is not currently a significant existing Basic codebase, at least there isn't that I've ever heard of. Most Basic apps are either based on a proprietry, ultra-closed extension of Basic (i.e. Visual Basic), or are (for the most part) really, really old console apps. If I am wrong (and I might very well be) someone supply a URL to some sort of Open Source Basic-based project repository. 2) Basic teaches bad programming habits : Evil, old-fashioned things like GOTOs, which should never be used, and also auto-sensing of certain syntaxes to the point where certain methods become useless (such as what I mentioned earlier about the = sign). 3) There are better alternatives. I am aware of several languages that are much cleaner then Basic, but still easier to learn. For instance, Ruby or PHP (which has no KDE bindings currently, but it might be worth looking into).

Re: Basic and KDE : what policy ? - Carbon - 2001-06-15

No, you misunderstand : I'm totally for KBasic, and I'm totally for it's objective of easy RAD. It's just that the language Basic, is frankly awful! I have read that manifesto, and (please don't take this as a troll, it's just my personal opinion) English-like _takes away_ from the usability of a programming language. First of all, not everyone knows English, and making use of a programming language totally or almsost totally dependent upon knowledge of a certain spoken language is restrictive to those who don't know that language. Moreover, English is not a good language for logical constructs. The point at which someone can write code by simply typing in, in their native language, what they are thinking, it is no longer programming, it's automagical. It may be possible, but it certainly isn't with Basic in it's current form, because right now Basic isn't even close to a direct translation of English into machine-compilable form. The manifesto seems to imply this, but this is not true, Basic follows very specific syntax rules, just like any other language. Also, (again IMHO) Basic teaching bad programming habits is not a non-issue. Even if you never use another langauge then Basic, it still makes it incredibly difficult to debug your code. Bad programming habits are not entirely about optimizations, as seems to be implied by the manifesto. Rather, it's about writing clean code that _makes sense_, not just to the compiler but to the writer 3 months later, and to other people wishing to understand the code. What I would suggest for an easy language is (yeah, I've said this before, but I sure do enjoy driving my point home! :-) PHP. PHP is nice in that it borrows from what's good about languages such as C, perl, etc., but avoids low-level stuff as much as possible. PHP is already capable of a huge amount, it's a well established language that already has an inceredible userbase in the Open Source community. It's currently the most popular module on the most popular web server in the world! Finally, I really wasn't trying to answer your question about Gideon/KBasic compatibality :-). I was just stating my personal take on the whole topic of Basic.

Re: Basic and KDE : what policy ? - Ben - 2003-07-31

It is because so many people/companies use it to develop real world applications. There is a large population of developers just waiting for this to happen. I don't know anyone these days that loves ms or wouldn't like to see Linux be successful. Linux developers have been so long concerned with the operating system, desktop and basic office tools that I don't think they are aware of the real world apps developed in vb. I am in radio and all the database software, which we use to analyze ratings, do traffic logs, accounting etc., are all developed with vb as are most other special purpose softwares. I write engineering programs in vb that are otherwise unavailable to me. While there are probably legitimate arguments regarding quality of these programs, there is the reality that vb brings the possibility of programming to professionals in disciplines other than programming, where their expertise is important. Gbasic set out to develop a vb compatible tool. Assuming it would work, that would instantly make available a huge number of programs. It, like all the others, seems to be dead in the water. Kbasic is dormant. Ybasic almost works has years to go. All these people are working alone and can’t seem to get together. Python with a rad environment like boaconstructor is the one most often put up as a replacement. I am learning that now but I don’t believe most people would go through what is necessary to find/install all the necessary programs then learn a completely new language. Can it really be that hard? Are Linux developers just biased against it? Reminds me of the old saying "cutting off your nose to spite your face". In other words somewhat self defeating. Someone explain this to me please.

Re: KBasic - davcefai - 2004-10-03

I have to disagree with the "Basic is bad" generalisation. Bad for whom? Bad for what? Remember that BASIC started out as an 8K ROM on computers which had from 16 to 64 KB RAM and ran at 1MHz. I suspect that a lot of the initial features were dictated by these limitations. Since then the language has developed out of all recognition. I personally started with Sinclair (Timex in the US) Basic and worked up through IBM Basic, PBasic, CBasic under CP/M, TurboBasic and the Visual Basic from VB3 upwards. With every move (over 25 years) I have been able to port programs I wanted to. Today, under Windows, I use VB6 and VBA in the MS Office suite. I can use MS Access or VB6 to access MySQL amd MS SQL Server databases with virtually no limitations. "Dave, we need to track the value of XXXX every minute and produce graphs accesible only by Production Managers" generally results in 10 minutes work on the Control System, 20 minutes on the Data Logging app (written in VB6) and another 20 in MS Access to produce the client module. Unfortunately this type of functionality seems not to exist currently under Linux - AND I DESPERATELY WANT IT TO! There must be a whole horde of people out there with similar needs to mine. An elitist "who needs BASIC anyway" mindset is only going to slow down the takeup of Linux. Take OpenOffice. They dumped BASIC in favour of a different language. It has made the migration from MS Office to OpenOffice EXTREMELY difficult. Yes you can migrate, but at the expense of dumping all the macros and custom code one had in MS Office. In other words, desirable as OpenOffice (and StarOffice) is, there is a serious hurdle to overcome in migrating. To my mind the problem is not "retraining" users - this is mostly necessary to stop the whining of "It's so different and not powerful enough for my needs" - but the rewriting of all the custom stuff in what appears to be a cumbersome and convoluted language, which is intended to be an "improvement" on BASIC. My view: forget the linguistics, the purism and the elitist views. BASIC has worked well for years and is familiar to LOTS of people. You don't have to use it if you don't want to. On the other hand having it available will make Linux a lot more attractive to prospective migrants. Don't get me wrong, I prefer Linux to Windows and OpenOffice to MS Office but the lack of BASIC is a major handicap.

KBasic - fine by me! - Esme - 2005-01-27

BASIC is a programming language; assuming use of a reasonably good version thereof, what makes a program good or bad is the programmer, not the language used. A bad programmer will generally find a way to write badly whatever the language they use to program in. True, some languages attempt to force good practice, but a truly (un)talented bad programmer will still be able to write bad code in them. Whereas a good programmer may be prevented from creating something uniquely wonderful by constraints imposed purely to try to force some particular style or methodology of coding. Also, equating MS Visual BASIC with the BASIC I learnt on many moons ago seems a bit like comparing chalk and cheese to me. I found VB got in the way of letting one actually code so much that it infuriated me to the point where I simply gave up before ever having created anything of use in it! I well recall arguments way back for and against the strong typing of variables etc, and which language was "better" (BASIC, Pascal, FORTRAN, COBOL, Lisp, FORTH...). IMHO, it's to some extent a matter of personal preference, and to some extent a matter of suitability for the purpose at hand. For simply giving those new to the whole idea of programming an idea of the basic concepts, old-time BASIC is wonderful. And it has its uses (I still have an old Sharp PC1211 handheld with 1.4k of RAM for BASIC programs, woo-hoo! Still use it now and then, too). Anyone wanting or needing what that kind of BASIC cannot deal well with (or at all) will look for another language that will do the trick. I know I will (I dream of one day giving the Gimp a more familiar front-end, if someone else doesnt do it first!) Personally, after a gap of many years away and some events that badly hurt my confidence, I want to get back into programming, and I'd welcome something like a good old-fashioned BASIC for Linux, to help shake the rust off and rebuild my confidence. I know I'll probably want to use Perl and Python in the long run, but I havent the time to muck about learning a totally new language at the moment. I look forward to seeing KBASIC, and hope to see FORTH and LISP one day, too! Esme

Do we really need Java plugins in KDevelop? - Richard Dale - 2001-06-13

Good question, well put! I wrote this in a recent email to Bernd: "But now, as it (javasupport part) is written in Java, it uses 5 Mb more memory, takes 8 seconds to start the javasupport module, and is harder to configure and slower to run..." ;-) I wrote the Java plugin api mainly to allow an easy interface to Sun's Java debugger api. There were some technical problems with the approach of piping commands to jdb, in the way that the KDevelop gdb front end works. On the other hand, here is my explanation I gave to Bernd of what I thought was interesting about Java KParts: "Here is the particular code snippet that I find 'exciting': urlLoaderClass = env->FindClass("kdevjavapluginapi"); if (urlLoaderClass == 0) { return; } addURLmethod = env->GetStaticMethodID(urlLoaderClass, "addURLString", "(Ljava/lang/String;)V"); if (addURLmethod == 0) { kdDebug(9013) << "addURLString(): no such method" << endl; return; } classPath = "file:"; classPath += instance()->dirs()->findResourceDir("data", "kdev$APPNAMELC$/kdev$APPNAMELC$.jar"); classPath += "kdev$APPNAMELC$/kdev$APPNAMELC$.jar"; env->CallStaticVoidMethod( urlLoaderClass, addURLmethod, env->NewStringUTF((const char *) classPath) ); cls = env->FindClass("$APPNAME$Factory"); if (cls == 0) { return; } This is from the initialisation code of the Java part project template. It is using the KInstance/KStandardDirs mechanism to locate a Java resource, a '.jar' file. Then it builds up a 'file:...' type URL for that resource and passes it to the Java class loader. When 'env->FindClass("$APPNAME$Factory");' function is invoked, the JVM looks for the class and loads it. If the URL had been an 'http:..' style URL the Java part would have been loaded from across the internet I hadn't been aiming to include this sort of capability, just wanting a decent api to use to write the debugger, which I was 'half excited' about. But when I realised the possibility of internet enabled KParts, I didn't do much else that week until I managed to get it working. On the other hand, I haven't really thought of a use for it yet - someone else might." I would say the jury is out :-).. -- Richard