A few words before I rant (just a little) about the new oxygen style. I do like the working aspects of it, that is the tabbars, the hover-effect on the menubar. The Scrollbars look good, so it is on the right track IMHO. Still I’m a bit worried about its quality on older or not 100% supported hardware, so here’s what I’ve got when trying the oxygen style.
First of all I think I should explain my graphics hardware, because I can’t judge which problems come from the style and which might be problems of my graphics driver. I’m working on a laptop here, which has a Radeon Mobility 9200. I’m using the open source radeon driver, because the proprietary one is a) not open source and b) is the worst piece of driver I’ve ever tested. Seriously, its crashing X11 more often then it boots it up. Also noteworthy is that I’m running Xinerama here, not with the MergedFB mode, but with plain X11 Xinerama, the reason for this is simply that I couldn’t get MergedFB to work reliably and to provide the resolution I want – CRT with 1400×1050 and Laptop with 1680×1050.
Thats for the basics. Now I present to you 2 screenshots which show how the style looks here on the above mentioned hardware:
Now the first picture shows you what I get when just selecting Oxygen as style on a clean user account. The problems here are that my graphics driver doesn’t implement certain XRender functionality and unfortunately the style currently can’t detect that and switch to a more usable background mode. For the second picture I switched to the horizontal gradient version (IIRC), everything else is still default.
Things that are wrong: The handle of Splitters, the Scrollbar knobs – that is the up-knob when the scrollbar is at the top and vice versa, The dockwidgets detach and close buttons are broken. The vertical header of the CVS toolview on the bottom is not vertical, the text on the vertical bars of the right toolviews is flipped (maybe thats intentional, but if it is its still broken for me) and last but not least: The lineedit in the Filemanager has the same background as the windows which is really wrong. I also noticed heavy flickering when opening a menu and then moving the cursor along the menu bar, what flickers is the combobox on top of the central area.
So what I’m currently most concerned about is that KDE4.0 will ship with this style and more than just 2% of our users will end up with something like the first picture. I guess part of the problem is that the people working on the style have state-of-the-art graphics stuff in their machine’s and use proprietary drivers. Both of which is fine, but IMHO is not what the majority of KDE users can be expected to have. So please, everyone with not-that-decent hardware or strange graphics setup (like Xinerama seems to pose a problem, according to Thomas), test the new style and report errors you find to Thomas Lübking or Casper Boemann so we don’t screw the KDE 4.0 experience just because of the default style.
So to conclude: Yes, the style is still beta quality, but I’m not convinced it can fixed properly until the 4.0 release. Sure its still some months, but this thing needs much more testing then it currently gets.
So Ralf Habacker reverted a few ioslave changes in kdelibs and now ioslaves are working again on win32. This means I can finally take a few first screenshots of KDevelop4.
So without more text, just sit down and enjoy them (and please remember: KDevelop4 is still pre-alpha and will not release with KDE 4.0).
- KDevelop4 with 2 projects open in the Project Manager View
- Showing the New Project Wizard (I don’t yet know why its empty, there is already 1 project template on linux visible)
- KDevelop4 can do split view (even showing the same file in both views)
- You can as well have multiple instances of a toolview
- Last but not least, KDevelop4 will make use of multiple mainwindows
Apart from that there’s also been done some work on the instructions to get kde4 onto your windows machine using the MinGW compiler. See the KDELibs.com page for more information and also please report any errors you find in the instructions (I had to write them down from memory).
PS: Maybe next time I can show the subversion support in action (it already builts, but I didn’t get around to test it out)
A short update on the progress of my student Piyush Verma, who’s hard working on the python parser. We finally managed to fix all bugs in the parser we could encounter. That is we both ran the parser on real world projects we had lying around and it didn’t fail parsing any of the files. That means pretty much all of the Python 2.4 language can be parsed (I guess somebody can find corner cases if he wants to). Additional support for Python 2.5 (I don’t think Python 2.3 is worth the effort) will be added after SoC (hopefully ;).
Also during the last week we started to use acunote.com for managing the work in SoC and it has proved itself helpful to communicate tasks (in this case mostly the bugs) and patches this way. More about acunote.com can be found in my recent KDevelop blog. The parser also is now usable as a shared library making it possible to write unit tests for it with the Qt Test framework and use it later on in the KDevelop4 language support.
The upcoming tasks for Piyush include creating a suitable AST by annotating the kdevelop-pg grammar and then starting to look into duchain and integration with KDevelop4. So the progress he’s making is quite good, although the harder parts are comming now. I’m pretty confident that he’ll succeed bringing Python support into KDevelop4
The last two weeks I’ve done quite a bit of KDE4 stuff, partly due to the fact that the first week of june was a week without “real life work”. The reason being that I couldn’t get to my workplace easily. I’m living about 40 km from Rostock and about the same distance from Heiligendamm where the G-8 conference was held from Jun 6th till June 8th. During that time the streets to Rostock (where my workplace is) where blocked by demonstrators. So I’ve had quite some time to hack
The first thing that happened was filling the new KDE4 module named kdevplatform, the code for that comes from KDevelop’s lib subdirectory and a few of its plugins. The KDevelop Platform is a building base for IDE-like applications much like Eclipse SDK is. It provides various parts for an application, among them integration with an editor (using the KTextEditor interface), language support interfaces, project management facilities and a user interface library. This is completed by a very extensible plugin and extension interfaces architecture which allows plugins to break binary compatibility without breaking the application.
Also the OutputView interface in KDevPlatform got an overhaul, its now truly a MVC architecture. Any plugin can register itself with the outputview and give it a model to be displayed. The plugin can then feed its output into the model and it will be displayed in a separate tab in the outputview. There are still a few issues to be resolved wrt. fact that in KDevPlatform applications you can have multiple instances of a toolview and for the outputview this means having multiple views for the same data. This introduces a few problems when it comes to navigating the output. This is something that is unified for KDevPlatform, there will be 2 to 4 shortcuts that will work on a selected outputview’s current tab and move forward/backward through the output. Everytime the shortcut is activated a special action can be taken, for example in the make output the file with an error/warning is opened at that position. This will be fixed during this week, hopefully.
On the weekend Alexander Dymo presented a nice way to keep track of the SoC projects: acunote.com. Everybody doing a SoC or mentoring it can create an acunote account and project and track the progress there. Its a really nice application developed by Pluron the firm that Alexander works for. It allows to review commits and patches easily, to define tasks that should be done within specified amount of time and it predicts wether these tasks are likely to be done within that time.
The last week was not that productive, as I had to catch up with work again. However I managed to implement the various version control helper classes in the KDevPlatform vcs library. This library provides interfaces and a few helper classes currently to implement version control plugins. The interfaces define a basic set of actions that the plugin needs to fulfill and a set of optional actions (for example remote move/copy, cat, ls). The helper classes are mostly straight-forward, except the VcsRevision class. This one needed to be subclassable and it also needs to allow to pass it by value around using QVariant. The approach I took was to implement a private dictionary with proteced members which would store the information that the subclass wants to add. This way its possible to easily create a SubversionRevision out of a VcsRevision because the data that is needed on top of the standard things is still in the class. This part of KDevPlatform would greatly benefit from an implementation in Python (or probably Ruby or Perl as well), because those don’t have static type-checking.
Also in the last week Oswald Buddenhagen introduced a new class to kdelibs, KProcess. This is mainly a convenience wrapper around QProcess and obsoletes K3Process and its subclasses. Unfortunately, with this change Ossi also broke the win32 port, because he disabled K3Process for win32. So Christian and myself had to sit down and start porting kdelibs, kdepimlibs and kdebase to KProcess. It turned out that QProcess is not always as easy to use as the rest of Qt, but with the help of Ossi we figured everything out. Some changes couldn’t be comitted until today because they broke BC, due to the fact they changed installed headers (yes some classes in kdelibs could benefit from a API review). There are still a few things left in kdelibs and kdebase that need porting sooner or later, because K3Process and KProcess don’t mix well within one application. I’ve prepared a wiki page to coordinate porting efforts for the whole of trunk/KDE (I just realize this doesn’t include koffice, yet): http://wiki.kde.org/tiki-index.php?page=K3ProcessPorting
Last but not least I fixed an annoying shortcoming of the cmake macro kde4_add_test. It only created a target to build the application, but it didn’t add the target to the test-target. So one always needed the add_test macro additionally to have the test run by make test. To fix this the kde4_add_test macro was renamed kde4_add_test_executable and a new macro kde4_add_unit_test was introduced. The first one will just create a target that is only added to the “all” target when KDE4_BUILD_TESTS is defined at cmake time, the latter will also add the test to the “test” target just like add_test() does. More information for both macros can be found in the FindKDE4Internal.cmake file installed by kdelibs. Of course this also needed a port of all trunk modules to the new macros and along the way I fixed a lot of old stuff that still used if(KDE4_BUILD_TESTS) and set the EXECUTABLE_OUTPUT_PATH manually.
So the last two weeks where rather productive, the next things on my todo: include-directory-support for the QMake Manager, fix project file reading/writing and the settings dialog, look into KNewStuff2 for application templates (for starters), think about debug/run API. And hopefully some new screenshots (maybe with the oxygen stuff, although that still has quite some bugs for me)
Ok, so there it is, my own blog. Didn’t have a particular reason to start it, I’m not the kind of guy that goes around and tells everybody about his shiny new code feature. Still I think some things are worth mentioning once in a while
So for starters here’s some KDevelop4 related stuff. First of all Kris Wong worked on the DUChain and its viewer lately and made both work to a certain extent. The DUChain can tell you about the various things that are in a source files, about their relationship to each other and to other files in the code. It creates a network of definitions, declarations and uses of any class, variable, function, struct or whatever else the language has. The DUChainViewer creates a tree from this information and thus lets you view your source code pretty much as a parser would. Unfortunately I can’t give you a screenshot, as it seems its broken again right now
The other thing thats pretty cool is I am a mentor of a KDE Google Summer of Code project. Piyush Verma, my student, works on adding Python support to KDevelop4 and bases his work on an initial parser from me. Only that that parser never even work He started to get one of the most important and controverse feature of Python working: Indentation.
Now Python uses indentation for creating code blocks, so the content of an if-block is indented more than the if itself. Now the tricky part is that there are quite a few rules for indentation, one is that blocks on the same level need to have the same indentation, so the code that runs in the if part of an if-else has to have the same indentation as the else code. Also the used lexer (flex) doesn’t have any support for that, so Piyush had to write the logic for that around the usual lexing rules. The real problem comes in when you parse lists and dictionaries, because indentation doesn’t play a role if they are spanning multiple lines.
Luckily Piyush is very dedicated and does a real good job, so indentation works so far pretty well. As the rest of the parser is still in pretty bad shape its not yet clear if the indentation-algorithm works for all cases, but it is easily extendable. Piyush will now concentrate on getting the parser problems sorted out and adding testcases to make sure the parser understands most of pythons grammar.