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. -
Fortran support. This includes a frontend for
ftnchek
and compiler options, dialogs for g77 and the
Portland Group compilers. -
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. - 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. -
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
When I wrote my last posts, T was hesitating to say something like :
Please, I only want to have answers about my questions, please don't answer something like :
> the Basic language itself is sucky
> Basic will just give them bad programming habits
> Basic specifically is bad
and so and so...
Hmmm....
I don't want to answer about such things. Only I agree with the page ""Why is KBasic useful for the Linux community ?" : http://www.kbasic.org/1/manifesto.php3
I try an other way for my question :
Gnome has a policy about Basic (it is GBasic and screenshots show it is advanced). What is the policy of KDE ? Let the Basic only out of Gideon and the other languages (even some few used as fortran), or let work together Gideon and KBasic ?
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).
Mr Ayatollah said :
> KDE's policy on Basic should be : "No Basic allowed"
Now it is a bad answer, because KBasic exists.
Why is KBasic useful for the Linux community ? : http://www.kbasic.org/1/manifesto.php3
My question was :
> > What is the policy of KDE ? Let the Basic only out of Gideon and the other languages (even some few used as fortran), or let work together Gideon and KBasic ?
And I add :
Are some contacts existing between the Gideon team and the KBasic team ?
If no, I hope that such a communication will be open...
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.
Basic Coding != Bad Programming Practice
It's a myth these days -- the language provides a GOTO..it doesn't force you to use it. :)
The "Goto problem" is a wrong problem : Other languages have it, including C.
Anyway, everyone should be free to use the language they like without being put in ghettos...
Have a nice week-end.
Looking down your nose at basic is exactly why Linux is not more successful. Most windows apps are developed with basic. Enabling this ability for Linux would kick off the biggest development spurt in the history of development spurts. It is petty and short sighted to take the attitude that basic is inferior. Make it superior. Bring those millions who develop things for work they do that keeps them using bill's junk. All the time I have to develop small apps to control some device or make some computation etc. I do this in vb because it is simple and quick. I have tried to make sense out of the socket wrench set plethora of compilers and environments. I don't have a life time to try and make something work. vb works now and fast and uses the c compiler so it executes plenty fast. Or you could just continue on believing the world will adopt what ever you decree. ms works because they try to fill markets like the one you are ignoring.
Is this because Basic is such a brilliant language, or because Basic is just one out of many easy to use languages and the one Microsoft decided to use for its RAD tool?
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 cant 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 dont 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.
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.
>Always the same old screenshots...
To me it looks like they are concentrating on the core language functionality right now, the interpreter, not the GUI tools such as the form designer. So there isn't anything new to take screenshots of. Althogh there doesn't seem to be much development of any kind going on anymore...
The reason Fortran is being added to Gideon and KBasic is not is that Fortran is a complete language and KBasic is still in the pre-alpha stages. When (if?) KBasic matures it could be added to Gideon, but won't it have its own integrated IDE and form designer?
>Also, there is PyKDE for Python. Is'nt it in duplication with the Python of Gideon ?
You seem to be confusing the language binding with the IDE. PyKDE is a language binding, a set of Python functions to access KDE features. Gideon's Python support is just a set of nice features in Gideon's editor and project manager to make it easier to edit python files and projects.
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
To say basic is sloppy, well some are, but look @ RealBASIC. Really, take a good look at it. It is more structured then any other basic aside from ASIC (very old school, nevermind) and it is just a tip of the iceburg. A *BIG* reason Windoze beat OS/2 & Geos was that you could quickly and simply design applications with Visual Basic. OS/2 used Rexx and C/Pascal and Geos used C and an API only. Funniest thing is, NT kernel all the way until 4 had the "OS/2" string in it, and OS/2 Warp 4 was by far the most advanced O/S on the planet when it came out but it was not easy to program for, and died.
The first person who makes a viable COMPILED basic for Linux will usher in the next Operating system standard and make a ton of money. I know, I watched computers since they 8K. 8192 bytes. total. Over 65 Thousand TIMES less then what is standard today/ :)
Having looked at the KBasic website just now, I would have two points to make:
First, looking at the syntax KBasic supports made me cringe. I firmly believe that BASIC in any carnation is bound to be evil. (I would certainly suggest using Python as your first language! or one of the many of the other available scripting languages besides BASIC.)
Second, this doesn't matter, because (from what I've seen, at least) KBasic is out to liberate Visual Basic users, rather than provide a useful language. They certainly aren't out to win over Python, PHP or Perl users! In this sense, KBasic is the most wonderful thing available to those stuck with lots of VB code! If successful, those who programmed in VB will be able to get away from it, and even port their code to an alternative OS. This is very good.
Perhaps those making the transition will someday buckle down and learn a new language, like Python. If they do so, however, they can make the transition smoothly, still being productive in KBasic while learning a real language like Python.
So KBasic certainly has my stamp of approval, whatever that is worth!
CodeInsight anyone?
Maybe one day emacs embedded in KDevelop with the editor framework?
I'd love to have this ! =)
Yeah, I like emacs myself, but I can't help but wonder just how much more bloated a Kdevelop + emacs distribution would be (two separate installs, tons of disk space needed =). It'd probably be easier to integrate XEmacs though, because it was designed to be embedded into X applications.
Most of the posts here are quite negative towards MDI. Why is that? I think it is probably the best "invention" yet.
I hate being able to view just one editor pane at once. So, please, keep the MDI-stuff in Gideon. At least as an option, that would make me happy. (Window splitters aren't that bad either, so keep them too. ;)
Window-in-window MDI is a pretty flamewar-magnetized issue, mainly because most newbies are confused by it. This is something I can attest to personally, as I've seen time and time again people wondering why, when they minimize their document windows in M$ Orifice, they can't find them on the taskbar to restore them.
Also, it's important to note that MDI does not neccesarialy imply window-in-window. There are other mehods, like the frame splitters you mentioned, also konsole style where you can have several documents, but only view one, and also tabbed style, plus probably many others I've never heard of.
I'd be more inclined to go for an enchanced frame style, where you don't lose any window space for documents, and that still makes it easy to organize frames.
Also, what would really be nice is the kicker taskbar menus that were recently implemented (another article on the Dot talks about this, can someone provide a link?). How about a list of MDI documents in each window displayed on the menu of any MDI app, as well as the system currently in place just for KDE-noncompat or SDI apps?
Absolutely!!!
Grats to the Whole KDevelop team!
MDI is a word with different definitions. Often its interpreted as a handling of multiple docs in a way you can see since Win3.1 and MS-Office. Others called tabbed views, docked windows or embedded docs MDI, they are right, too - all this is a kind of a M_ultiple D_ocument I_nterface.
My personal friend (*ironic*) is the first MDI-paradigma. I think windows in window (win-in-win) does not fit in a virtual desktop system like x-windows, here KDE. Here we don't have a single desktop like M$-Win, we are used to organize our work on many screens and are used to have a powerful global taskbar/pager to navigate. The (I call it) classic MDI does not fit this X paradigma. The win-in-win-problems can you see also with current KOffice-KPart: in an extra windows I could edit much better, than now in an active KOffice-KPart. Another problem is the using of classic MDI-windows as application toolbox. This does not work well as KPart, too. You are not able to use this toolbox outside the KPart-frame (see: krayon-frame in kword)
On the other hand, there are realy good examples of intelligent MDI: Konqi split-views, KDevelop-1.4-CVS (very flexible: tab-view, tear-off and of course classic MDI), Konsole (easy but useful), Kate fast file selector and so on. But PLEASE, don't use classic MDI.
Why dont someone implement a class for Gideon that make code autocompletion ? I mean, while you are coding, if a sentence belongs to the language sentence, then, the kdevelop autocomplete the sentence.
If i am writting for example:" fo ..." then, kdevelop has to writte"for _ = _ to _ step _" where _ is a space. Or put the {} automatic.
Or another idea is to integrate a sintaxis corrector (i dont remember the name of the program).
What do you think about these ideas?
It's a little known fact that Gideon has Objective-C support - class browser, syntax highlighting. If you use a 'patched for Objective-C' version of gdb ,it works fine with John Birch's gdb front end. But it still needs a GNUStep, and 'Kangaroo' (forthcoming KDE Objective-C api) project templates.
-- Richard
I know they're not for the same thing, but this story reminded me that Quanta has gone w/o updates for a very long time. It's one of my favorite KDE apps. Anyone know if development will continue?
Its in kde CVS, it compiles very well with current KDE-CVS but I don't see so much new features comparing to the last stable release. There are some UI-improvements.
Supports Gideon code completition ? It's fine thing for sclerotic people like me... Espetially for me it is more important tool than class browser.
"Furthermore, even KDevelop plugins can now be written in Java."
I'am not sure it is a good idea. Java is slow, the JVM is memory-hungry. Java is an excellent
solution to slow down a 1Ghz computer to a 100Mhz one, and a good vector for multi-platform viruses.
Therefore, my question is : Do we really need Java plugins in KDevelop ?
IMO yes. 1) it demonstrate whats possible with current KDE desktop technologies 2) some developer don't like C/C++ 3) you can use the complete available Javasourcecode (Java Debug Architecture)
4) you don't have to use it if you don't like it
:-)
"IMO yes. 1) it demonstrate whats possible with current KDE desktop technologies 2) some developer don't like C/C++ 3) you can use the complete available Javasourcecode (Java Debug Architecture)"
"4) you don't have to use it if you don't like it"
1) Is KDevelop a demonstration program for KDE
or a useful application ? A feature have to be
useful (good functionality/costs ratio) and not only "possible to implement".
2) Sure! Sun (and others) propose some very nice development environments for them.
4) Yes, but maybe I have to pay for it
(see http://dot.kde.org/992083107/992372437/992420887/ )
"Is KDevelop a demonstration program for KDE
or a useful application ? A feature have to be
useful (good functionality/costs ratio) and not only "possible to implement" "
Yes, features should be useful, but please don't forget that this is a hobby project. I I think if someone wants to implement a "strange" feature or technology demonstration its ok if it doesn't break the application completely.
"Sure! Sun (and others) propose some very nice development environments for them."
I disagree. They have IDE's but I know many people who would really like a fast and easy to use IDE for Java. Under Linux JBuilder,Forte... are _slow_, even on a GHz computer with hundreds of Megabytes RAM. :-(
" think if someone wants to implement a "strange" feature or technology demonstration its ok if it doesn't break the application completely."
Ok, Ok, I am not a policeman too :-)
"They have IDE's but I know many people who would really like a fast and easy to use IDE for Java. Under Linux JBuilder,Forte... are _slow_, even on a GHz computer with hundreds of Megabytes RAM. :-("
This is THE recurrent problem with Java.
It works properly, as long as everything around it (IDE, various software layers, etc..) is *not* written in Java. Java needs C/C++ code, but as a C++ user/writer, I don't want to be slow-down by a (maybe) poorly designed and (certainly) misused language.
"I don't want to be slow-down by a (maybe) poorly designed and (certainly) misused language." - you mean C++ of course :-)?
The Java runtime is not inefficient - server side Java works very well. But Swing is a dog as you correctly point out.
The KDE Java bindings ignore the conventional wisdom you talk about - I don't care how much C++ is involved as long as I end up with a useful and efficient Java api to KDE.
-- Richard
1) There is no conflict between demonstrating KDE
technologies and beeing a useful application.
For many people, Konqueror is the most useful
KDE application, and it is essentially a quite
thin layer on KParts, KIO and KHTML which can be
used in other applications as well.
2) And others propose nice desktop environments,
nice IDEs and nice web browsers as well, So let's
stop KDE development!
4) No, you only pay for what you want, nothing more. That's the whole point of the modularization in KDevelop's HEAD branch.
Yes, this is a demonstration of 'Internet enabled KParts'. But it wasn't written for that purpose - the requirement was for a useful api to write the KDevelop Java debugger. That side of the deliverables wasn't experimental.
A smiley followed the comment about Java slowness here (start up time for the initial Java part is the only real problem):
http://dot.kde.org/992083107/992372437/992420887/
Gideon is much more efficient compared with the Java plugin architecture for NetBeans.
-- Richard
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
You have actually heard of native compiled Java, haven't you? Or is GCC development something that happens to other people?