SEP
15
2003

KDE 4.0: Die kapp, die!?

Submitted by Daniel Molkentin

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.

Comments

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?

By KDE User at Mon, 09/15/2003 - 22:41

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.

By Daniel Molkentin at Mon, 09/15/2003 - 22:51

Obviously, a less different KDE4.0 is more likely to be sooner than a more different one; at least that's how I'd judje it/predict the Discussions (i.e. KDE3 was relatively easy as "one can port apps trivially"). At the rate you and Tim are going it, I am thinking KDE3.4 :-)

By Maksim Orlovich at Tue, 09/16/2003 - 01:39

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 :)

By KDE User at Tue, 09/16/2003 - 00:31

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.

By KDE User at Tue, 09/16/2003 - 00:35

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

By KDE User at Tue, 09/16/2003 - 05:02

The split widgets were there since at least Qt3.0, and are not used on purpose, because they were believed to be /less/ usable.

By Maksim Orlovich at Tue, 09/16/2003 - 14:30

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?

By KDE User at Tue, 09/16/2003 - 18:00

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.

By KDE User at Wed, 09/17/2003 - 04:56

Most the ones I've just tested popup immediately if you move the mouse. Usability feature. Nice.

By KDE User at Thu, 09/18/2003 - 02:27

Pages