cies' blog

i never felt enough need to blog... yet. well... here it is; enjoy.

KDE 4
below you find some of my thought on KDE4, please dont take them too serious, there just some ideas i have in mind.

so: in KDE 4 it might be nice to...

• ...minimize the use of dialogs; like the find and replace dialogs, they can be put them in search/sidebars (like the firefox searchbar)) -- there is a big anti-dialog rant below

• ...make the shade the mainwindow (as in less brightness) when it has a modal dialog (like OSX attaches the modal dialog to the mainwindow)
  

• ...change the current modules stucture of KDE:
• only groups of apps that share their specific libs should have a module (kde-pim, koffice)
• keep kdelibs and kdebase
• the rest could be in app repositories that show the state and/or level of inclusion into kde (something like: kde-apps, kde-apps-testing, kde-apps-unstable, kde-apps-unmaintained and the same for contibuted-apps-*)
  

• ...name (at least) the KDE4 release (i like Roberto's "Kaleidos", so it will be "KDE Kaleidos") -- we can always name KDE5 something else (KDE "Hasta", anyone? :-)
  

• ...use the CIG (corporate identity guide -- about the use of colors and logo's), even though it might not be finished yet. i something like a draft of the KDE CIG once on the 2004 aKademy, i liked what was in there, it looked solid.
  

Some more ranting about dialogs
I just hate them like popups. Ofcourse we need some (settings, file open/save) but many we dont need. Like all the dialogs showing me a 'status' (saying: "loading...", and sometimes a progress bar), didnt we invent the status bar for that? Also all the dialogs telling me about some error, cant i just be noted of the error in the content of the application? (I'm not talking about Dr.Konqi -- i dont want to make him mad)

There are many cases in which we can ditch dialogs. Maybe it is an idea to write a little guideline thing for when, and when-not to use dialogs.
I also hope that in KDE4 the often discussed universial (down)load manager will be there. Then all the "Loading..." dialogs can but put in there.


Kopete styles
after making Efficient, a Kopete style (right now the most popular in kde-look), got into some problems with kopete styles in XML/XSL. there are some serious memory and cpu issues with the current solution, and it is quite difficult to extend the current solution without making it even more resource hogging.
many good looking themes use the notorious "TransformAllMessages" flag and some ugly hacks. this is a pity. to make it work nice a lot of caching within the XSLT has to be done. alltogether it is not easy...
i went dreaming of an alternative.

i thought it might be better to have the sytes as a plugin (c++), instead of an XSLT. This would be fast, but than the styles will not be x-platform anymore, the plugin would likely be able to crash Kopete, and it would be difficult to be made by 'users'.

then i thought of KJS... it is in KDE already and it would fit the bill nicely (IMO). Having the kopete styles in KJS would solve quite a few problems. final question: will KJSEmbed (or QSA) be in a KDE4 base install, so all applications can make use of it?


KTurtle
i have been working hard on a rewrite of KTurtle. it is right now mainly on my harddisk and a backup, but if anyone would like to help i can put it in some repository.

i first rewrote the interpreter. all commands are now meta-programmed by a ruby script (so a new command can be created by adding code in one or two places). the interpreter is statefull and much cleaner in in code. i also ported the whole thing to qt4(.1-snapshots), i plan to keep it depending on qt4 only for a while and intergate it with KDE4 (libs, buildsystem, etc.) later, keeping a build option for a qt-only build.
right now is have to put some more efford in the GUI, the canvas, and the intergration with the interpreter before i have something nice to show.