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
Great Stuff!
looks amazingly!
-gunnar
can anybody tell me how to get the window-geometry of a mainwindow + window decorations?
the QT docs
(e.g. file:/usr/lib/qt-2.3.0/doc/html/geometry.html )
say that frameGeometry()
is including the window frame
and geometry() is excluding it!
But
kmainwindow->frameGeometry().height- kmainwindow->geometry().height == 0
... frameGeometry() doesn't seem to include the window frame :((
frameGeometry() is a QFrame (== client side) thing and has nothing to do with the frame drawn
by the window manager.
There is no way for an application to find out
the window manager frame geometry.
That's not true... "xwininfo -frame" will tell you.
That's unreliable. It depends on how the window
manager reparents windows. There are window
managers that create two nested windows and
reparent the client window into the inner one.
In that case you will get a wrong result.
i really look forward to see the new version :)
What about RAD and CodeInsight?
Is it possible to make KDevelop fully RAD like Delphi while not requiring the RAD module.
Will there be a feature like Delphi's CodeInsight?
Those two are my most wanted features.
And will there be tabbed MDI support?
In the current version, I need to click on the Window menu to be able to switch to another open document, which I find very annoying.
A tabbed solution like GnomeMDI would be much better.
IMO, GnomeMDI isn't the answer to all ui
questions. It is designed for applications that
have only one type of document, view resp. In
an IDE you want to browse source code and
documentation at the same time, or you want to
work with two source code windows side by side.
Also, tabs become unusable when there is a large
number of them.
OTOH, KDevelop's user interface will certainly
become more flexible in the future.
It's just an example.
BTW, GnomeMDI for GNOME 2.0 supports Window-in-Window like QT/Winblow$ does.
> BTW, GnomeMDI for GNOME 2.0 supports
> Window-in-Window like QT/Winblow$ does.
If I have anything to do with it, that shit is being removed. It's ugly as fuck.
If you want to troll, go to Slashdot.
All the deprecated code is already removed from gnome-libs in CVS.
Only good code is left, which mean the window-in-window MDI mode (which is optional) is good code.
He isn't trolling, he is fully right. Drawing
window decorations is the window manager's job.
Imitating that by the application will always
suck. It doesn't integrate with the window
manager's look and feel, it uses different
buttons for maximizing or closing windows, and
it doesn't adjust to the window manager's focus
policy.
No, he isn't. The Window-in-Window mode is just one of the many modes in GnomeMDI.
You can also choose for the Toplevel or Tab mode.
So there's nothing one can complain about.
Besides, QT and KDE also do the Window-in-Window thing.
Somehow I get the impression that gnome advocates
can not read. Here it is again:
>> BTW, GnomeMDI for GNOME 2.0 supports
>> Window-in-Window like QT/Winblow$ does.
>If I have anything to do with it, that shit is >being removed. It's ugly as fuck.
That's what you responded to. So you are
trolling, not him.
I don't believe him. How does he know that that code is "shit" and is being removed?
Link to mailing list archive please.
> How does he know that that code is "shit" and is being removed?
He doesn't know any of those because he said neither of those! Re-read the original message again:
> > If I have anything to do with it, that shit is being removed. It's ugly as fuck.
He only sais that _IF_ he was concerned he'd vote to get Window-in-Window MDI out, not that someone actually decided to do so!
Also he _NEVER_ said the code was ugly, only that the Window-in-Window MDI itself is ugly.
*sigh* Please read what people say first and don't take everything personally. It would make your life so much easier...
How do I know it's shit?
I used it.
It's ugly.
It may be good code, but the end results are nothing to be proud of.
And your assertion that only "good code" is left in gnome-libs is just laughable.
Ignore the above post. It's posted by a troll who stole my nickname.
Oh no it wasn't
Oh yes it was. Now shut up and go steal others' nicknames.
No MDI works well with a large number of files, all implimentations will suck becuase there is no perfect way to do it. Also Gtk 2.0 supports Doc/View very well, Qt Doc/View is difficult.
No, it does not work well with a large number of
files. As soon as you have perhaps 5 files open,
the tabs won't fit into the window width (on a
usual 17" monitor) and you have to scroll. And
scrolling a tab bar is a lot slower than choosing
a file from a popup menu.
For the other statement, I suggest you go
trolling on gnotices.
you also can place tabs on two or more rows (like together do). that way you can access a lot of files really fast
And at the same time you fill valuable vertical screen space with your tab rows.
Besides, you can reach the same effect by putting
buttons with all file names in a tool bar. In
this way, you don't restrict the user interface
to one show one file at a time, which is what
tabs do.
i have no problem sacrificing screen space to be able to reach every file in one click (because when coding, i really have to switch a lot, and 90% of the procedures i write are really small, so i can see a whole procedure in together in an editor window that takes less than 50% of the screen (i also have an uml class view open)
anyway ... seems we ran into a matter of taste yet again :) configurability for president !
I agree that it quite annoying to have more than one mouse click to switch to another source file. The tabbed editor in KDE Studio provides a nice solution in my opinion, but it is probably a matter of taste. The ultimate solution could be to make it configurable (I know, it seems to be the solution for everything ;-)
(Huuaa - my friend MDI;-)
<
Another discussion is here:
http://linuxtoday.com/news_story.php3?ltsn=2001-06-09-008-20-PS
I would love to see this support palm os dev. I would do it myself but I wouldnt know where to start.
yes, rad support would be great. look at borland kylix as an example. i think kdevelop should move in that direction.
Maybe you should try the designer of Qt 3.0 :-)
I don't think it makes much sense to integrate
a dialog editor into KDevelop that can't
seriously compete with Qt designer. So turning
KDevelop into a rad environment would need an
ambitious developer with much energy :-)
As Gideon has already C support I think it would be nice to have an application template for the Palm OS (including makefile,configure...) first and then some plugins for starting the emulator ,transfer the program,GUI editor and so on. Please read the file HACKING to get an overview how to add plugins and study a small Gideon kpart. It'is not so difficult. :-) If you have problems you can subscribe to the KDevelop-Devel mailinglist.
I am very happy about Gideon, because we will be able to programe with any lenguage , as C, C++, Java, Php ...
But, the problem i see is that the documentation about new lenguages will not be created by KDE team. The QT/KDE documentation is great, one of the best docs over Linux documentation. Then, if Kdevelop support new languages, as Php for example, KDE team has to integrate the Php Manual from www.php.com, and there are lenguages that there is not a good work about their documentation.
Another thing i am thinking is why there is not a
documentation about ANSI C and C++ with the documentation in Kdevelop. I mean, when you are programming, sometimes you have question about some sentence, and you have to search a book to read how it is. Then, it would be great, if in the kdevelop documentation it has a section named ANSI C-C++.
And to finish my willings :-) , when Kdevelop will have an integrated GUI-Builder alo Borland C++ Builder? I mean, a "glade" integrated into Kdevelop (I dont like much more Qt-Designer because you cant code KDE or gnome aplications). Then, with this function, will be able to build big aplications, without worrying about the GUI interfaz. With this feature, will be able to programe Java aplications too.
I have to give to KDE and Kdevelop team, my congratulations about you work.
Actually, you can have Qt Desginer support KDE widgets. If you have the KDE headers installed, there's an option to add the KDE widgets to Qt Designer at compile time.
You may want to check if the packaged version that comes with the KDE distribution has that feature. My guess us yes, but it's been a time since I last checked it.
I'm with KDevelop 1.4 opened right now, and in the "Books" Tab I have access to the GNU C library documentation, STL documentation, Python doc., BONOBO docs., GTK, Glib, Quanta+, E2FSlibs, full Debian documentation, a C/C++ Reference et al. I don't know if it's a Debian "bug", but I can see (and even browse) these docs.
I'm using Debian 2.2 (x86) with KDE 2.1.1 form http://kde.tdyc.com and XFree86 4.0.3 from http://people.debian.org/~cpbotha.
Not a bug, but an integration of Debian's
docbase :-) I implemented this two years ago
when I still used slink. Nice to see that it
still works. Unfortunately other distros don't
have anything similar.
Docbase doesn't provide much meta info about
a documentation item though. In HEAD, you can
search through the documentation index of libc
and stl with autocompletion. For the Python,
Perl and PHP documentation, also the table of
contents is directly displayed in the doc tree.
I'm especially excited about the Fortran support. Fortran is not dead and having an open source IDE for g77 will be very, very useful!
Any plans for integrating g95 when it is ready?
Considering the current state of g95, this
appears like looking far into the future ;-)
Anyway, writing a parser for free form Fortran
is sigificantly more effort than for fixed
form FORTRAN 77.
One of the noticable things about the PHP (and possibly other language) docs is the user comment system. It's noticable in particular with PHP since almost all the in-code examples for the function reference are submitted by the users. It would be very nice indeed if developers, for any given release of the Gideon copy of the docs, included these coments as of that date.
Also, what about Kate? It seems suspisously similar to what Gideon is beginning to look like (Multi-doc editing, syntax highlighting, embedded konsole, etc). I'm not suggesting a merge, that would almost certainly not work well. However, what about making some sort of base "kde style mdi editor" framework, then using that as the basis of Kate (editing framework and hierarchial sidebar in kate would be nice), KDevelop, and, in the future, maybe even KWord (for power-user support for vim style editing in kword!)
Some people use Front Page and Visual Interdev
together to create SQLServer/ASP powered websites (I don't know how they work together ActiveX OLE thingamaboobies). Any cool ways to do similar things with Gideon kpart/konqui/some html source code editor and MySQL/PHP/Zope/Python etc. ??
....some html source code editor...
you mean someting like Quanta+ :)
Interdev can do ASP + SQL Programming together. Frontpage is for the newbies while Interdev is for the real asp developers.
You would not really use them both, it's basically one or the other (based on target user).
Kevin
Have to respectfully disagree with you here. I build some quite large and complex websites (London Stock Exchange, jobs.telegraph.co.uk) and my team all use HomeSite :-) I use Visual Interdev, FrontPage and Homesite, because each has it's stengths and weaknesses.
FrontPage has a good preview mode, InterDev ruins the pages a little less ;-> and HomeSite has the most capable text editor, but has sucky preview. It's all horses for courses really.
WohohohohohohohoW!!!
This rox man. You kde people never seize to amaze me. Why even bother to use windows? (rethorical question, everyone knows that the answer is "no reason")
I see Perl, Python, Fortran, but nothing about Basic...
Why ?
How is going KBasic ?
Has KBasic some interactions with Gideon ?
Is really KBasic the only solution inside KDE to nearly program in Basic ?
Or is existing something else like to translate Basic in Python, for example ? (not only about VB programs, but also about MS Office VBA programs...)
You can follow the KBasic progress at http://www.kbasic.org/.
-N.
Thank you. But I know this site from several months, and I am surprised to see, today, that Fortran is suddendly coming, while nothing seems changing about KBasic... Always the same old screenshots... Although, yes, it seems there are some progress... many more slower than Gideon-Fortran...
I am wondering whether devopping Basic inside Gideon would not be better ??...
Also, there is PyKDE for Python. Is'nt it in duplication with the Python of Gideon ?
But, certainly, there are many things I don't understand...
No. PyKDE is a library that allows you to access
the KDE API from a program written in Python.
KDevelop is an IDE. You can write programs using
PyKDE with the help of KDevelop. I think it'll
make a good combination :-)
>Also, there is PyKDE for Python. Is'nt it in duplication with the Python of Gideon ?
Not really. PyKDE/PyQT allows _any_ python app, written in kdevelop or not, to create and use QT/KDE widgets, signals/slots, etc.
However, python support in kdevelop allows you to write python apps inside kdevelop, whether or not said apps use PyQT/PyKDE is up to the developer. The point is, you could and still can use kdevelop to develop non-KDE or KDE apps, and now you can do this with other languages then C++.
Thank you, I understand about Python. And I see that KBasic is not similar to PyKDE, but is similar to Gideon/Python.
So, again, I don't understand about Basic. It is now possible to write Fortran, Perl and Python apps inside Gideon, and quickly. Why not Basic ?
Isn't is a better way than the slow KBasic ?
Perhaps my question is disturbing, sorry...
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! :-)