Recently, a discussion about KApplication::random() popped up on kde-cvs. People were asking to move this in a Math tool class. This reminded me of something the KDE-Qt integration group in n7y discussed as a "would-be-nice-to-have" thing. But let me first describe my POV:
IMHO KApplication was way to long the place to store everything but the kitchensink. I'd love to get rid of KApplication in KDE 4 if that is possible somehow (or strip it down to a minimal layer that provides no new methods. The motivations:
- qApp does not provide all functionality we need but
- kapp is not defined (and hence crashes) when classes are used in designer or other qt apps.
- It's really hard to use KDE Widgets outside of a KDE application (because they internally rely on the kapp pointer. I tried to guard those calls to make the widgets usable with designer, but it's a really PITA).
- KApplication is quite bloated.
It would be nice if we could have the KDE libs a a nice add-on lib to Qt rather than something that "overrides" it. Saying that I know that we might want a certain control over our classes, but I see no reason why KApplication should provide added functionality (overriding for behavioral adjustments might be necessary, but it would at least make the kapp pointer obsolete)
Ettrich said that the custom event handling stuff could be removed. the KConfig/KStandardDirs/KLocale object and friends could be retrieved via KGlobal, which should then probably be a singleton. All the small convinience functions should probably move out to tool classes (KDE::Tools). That doesn't mean they have to be less convient! I see no reason why invokeMailer and co. should be in KApplication, except for the tempting short "kapp" macro. So IMHO:
- kapp must die
- KApplication could remain as a small wrapper around QApplication that overrides some virtual methods, but it's really questionable if we really need it.
To all those who are worried about backward compatibility: the KDE_COMPAT macro around deprecated methods is your friend there. I guess in the end the problem will be... manpower.
Syndicate Blogs
SVG Widgets?
How about moving to full SVG for the widgets, icons, text, etc?
Oh man.. KDE API's using prop
Oh man.. KDE API's using proper namespacing, KApp destroyed.. can I stop drooling yet?
Watch my words; the KDE API is going to be one damn fine API if this all gets done for KDE4
The only additional work I would like to see is the removal of most KWidget classes (adding the additional functionality in some other way).
It's just not the way to go.. (and some of them are full of hacks as well)
Example: Since Qt 3.2 (I believe, not sure) there's this nice looking (and very usable) feature to use toolbar buttons with a drop down menu on the right (one button that's split into 2).
This isn't your average one-button-with-arrow-on-it, no.. it's more like the win32 two-buttons-with-arrow-on-2nd-button.
However, KDE doesn't use this (yet?) because it wraps things up with custom (K)widgets (for no real advantages, imho).
The widget would have been used automagically if KDE didn't do that.
Now imagine having all KDE apps with those special buttons instead of the current weird things.. man.. another step closer to world domination
Incorrect.
The split widgets were there since at least Qt3.0, and are not used on purpose, because they were believed to be /less/ usable.
Like said, I wasn't sure abou
Like said, I wasn't sure about the Qt version.
But how is it less usable?
It actually offers *more* choice to the user (popping up the menu - or just pushing the whole button and execute an action immediatly), isn't that a good thing?
Hm, KDE people saying that choice is a bad thing.. am I dreaming?
It might be fixed in CVS, but
It might be fixed in CVS, but last I looked there was no consistency in KDE's button+menu widget. What I mean is that some of the buttons with the little arrow in them pop down the menu *immediately.* For instance, most of the menu buttons on kicker, including the "Terminal Sessions" button. The "Terminal Sessions" button used to, on a single click, invoke konsole with the default session (or was it the last-used session; I forget). You had to hold the button down for the menu. Now though, the menu pops up immediately (which reduces its usability to me at least, but that's not what I'm arguing here).
Ok, I got a little rambly. Anyway, what I'm trying to say is that *some* buttons with a little arrow on them pop up a menu immediately on click, whereas others have a default action if you click them, but pop up a menu if you hold down the button long enough. There is, AFAICT, no visual distinction. There should be!
Lastly, it would be nice if the right button (or something else, like ctrl+left button, or even middle button) could be used to pop the menus right away without having to wait.
Don't have to wait
Most the ones I've just tested popup immediately if you move the mouse. Usability feature. Nice.
Totally agree with you and the author!
That would be some great stuff! KDE's api really needs to be even easier to use and more consistent! These are some great steps tog etting tehre as are: http://www.kdedevelopers.org/node/view/172
btw. Just to clarify, with 'm
btw. Just to clarify, with 'most KWidget classes' I meant ones like KPushButton, KToolBar, K.
So that's not the common widgets and some other special cased ones.
Down with KAPP!!! BURn IT!!
LOL, I'm just joking I don't really know anything about it! But, it sounds like a better replacement can be found.
Now I've seen 3 blog entries about KDE 4, but isn't the next version of KDE 3.3?
Important
I think it's quite important to have a place to collect new ideas. I don't want to bother core-devel with it yet, but this place looks quite well suited to be an incubator for ideas regarding KDE 4.0. Those things have to be planned very carefully, you don't want to rush them.
Regarding your question of 3.3 vs. 4.0: I don't think that anything is decided yet.