A little review of kdecore & kdeui

[Hamish Rodda]

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

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060406/41be74b4/attachment.sig>