A little review of kdecore & kdeui
rodda at kde.org
Thu Apr 6 10:59:30 BST 2006
On Thursday 06 April 2006 09:21, Thiago Macieira wrote:
> David Faure wrote:
> >On Wednesday 05 April 2006 23:32, Thiago Macieira wrote:
> >> classes that stay
> >> =================
> >> KAction* (verify that it can die)
> >It certainly can't.
> I undertand, but why? And can they be made to derive from QAction, at
> least? Cursory glance reveals they share much of the same functionality
> and API (even some of the properties!).
Yes, no doubt we need to keep KAction and most derived classes, however all of
them now inherit from QAction. A few derived classes are superfluous and
I'll clean them up at some point.
KAction itself provides above + beyond QAction:
* default shortcuts, user configurability flag for shortcuts
* global shortcuts now :)
* saving and loading of customised shortcuts
* automatic Kiosk integration
* an easy way to upgrade QToolButtons to (potential new class) KToolButtons
should we ever find it necessary
* integration into KActionCollection and shortcut configuration dialogs
* backwards compatability api (quite important, especially plug(),
isPlugged(), and signal activated())
> >> die
> >> ===
> >> KGuiItem / KStdGuiItem
> >Why? This framework promotes consistency between KDE applications, and
> > you want to kill it? Qt provides many things, but not that. Consistency
> > between apps is exactly kdelibs' job.
> I thought this could be merged with KStdAction + widgets. Maybe I was
> wrong. But remember we did a cursory look into all classes, by looking at
> the header files and lxr.kde.org for some of the unusual classes (my
> personal favourite are the KXYSelector and KArrowButton).
I think we'd be better off modifying KGuiItem to more closely resemble basic
Q/KAction data. Probably would be better with a nicer name too.
> > KKeyServer (depending on feature on Qt)
Yes, pretty please :) I think this is essential...
> >> kde3support
> >> ===========
> >> KTreeWidgetSearchLine
> > Isn't that the new non-qt3support one?
Yes, I'm surprised by this comment too. I heard such a widget would be easier
to implement in Qt 4.2, but it still won't have the rich features (column to
search selection, etc).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel