A little review of kdecore & kdeui

[David Faure]

On Wednesday 05 April 2006 23:32, Thiago Macieira wrote:
> KTempFile -> KTemporaryFile (replace with QTemporaryFile?)
This was already discussed and the result was that QTemporaryFile doesn't support
custom extensions iirc.

> KSaveFile (tool?)
This class is -essential- to risk-free saving of files (in particular for the "disk full") situtation.
It is used by KArchive classes (KZip etc.), and I think it should stay in kdecore.

> KNetwork family (move to another library?)
To have no QtNetwork dependency in kdecore? Why not; depends if anything else
in kdecore needs QtNetwork anyway.

> Tools/Components: (kdeutils or static library[ies], simple classes without interdependency, used by very few apps)
> ================
> KCharset
> KCheckAccelerators -> should it be private, inside KApplication?
Yes I wonder why it's exported.

> KClipboardSync -> probably used by klipper only
./kapplication.cpp:556:  (void) KClipboardSynchronizer::self();

> KDateTime -> can it be replaced with QDate/Time with extended range?
> KLockFile -> used only by KConfig
We might want to use a proper locking solution in more places though, anyway... (kabc, kmail etc.)

Anyway, the above means that libkdetools (don't call it kdeutils that's already taken ;) would be -under- kdecore, right?
This answers your question about its dependencies then... only Qt (QtCore, probably).

But I thought it wasn't possible to link a static lib into a shared lib?
If that's the case, how would kdecore's KConfig use KLockFile then?
And more generally how would we use that static lib from all the libs we write in kde?
Almost everything is a lib, due to kparts and kdeinit modules...

> KNotificationRestrictions (!)
Seems to have an X11 dependency -> kdeui?

> classes that can either be removed or moved into KDE3Support
> ==============
> KSortableValueList -> too specific!
... and not needed anymore.

> KTypeList -> maybe rework? Looks ugly.
Well, templates...

> Extra
> =====
> KDEDModule
I initially created a new lib for that one, but many said, justly "why a new lib for just one class, put it in kdecore".
Which I did, and which I still think makes sense :)
In fact this has no other dependency than qt so it could go to libkdetools too if
that's not a shared lib (otherwise I see no gain in doing that)

> Other stuff:
> ============
> - kglobalaccel_win.h is in kdecore. Why?
Already fixed

> - remove old, empty headers
> - mark private headers with _p.h
Yes

> - get rid of kde_file.h
No (see previous discussion on this list...)
Or how else did you plan to get rid of it (and why?)

>   rollback into Qt
> ================
> KActiveLabel
LOL. How will Qt call kfmclient, exactly?

> KComboBox (text completion)
> KLineEdit (text completion)
So Qt plans to provide a text completion mechanism as general as kde's?
I see a setAutoCompletion() in QComboBox, but this is nowhere as flexible
as kcompletion - not even close. Remember that we autocomplete addressees
in kmail's composer using LDAP, etc. And that the user can choose a completion mode.
And that KLineEdit obeys the kde-standard accels for copy/paste/cut/undo/etc.,
thus making those configurable. I think you guys should hold your horses a bit
with the "Qt does it all" approach; it doesn't, and can't, and doesn't need to.

> KSqueezedText (I think it's already in)
In where? ;)

> KStatusBar
Sorry but KStatusBar provides a much easier to use API than QStatusBar, as previously discussed.
It's a convenience layer over QStatusBar; why kill the convenience layers?
Qt did so (bye bye QHBox), but there's no reason for KDE to do so as well.

> KUrlLabel
Replaced with...?

> KTextEdit (text completion)
KTextEdit will do spellchecking as well, as soon as kspell2 code can be used from kdeui
(I thought the plan was to do such high-level reorg rather than trying to kill individual kdeui
classes; apparently that's still something we need to think about).

> KCompletionBox (text completion)
which Qt provides with... ?

> classes that stay
> =================
> KAction* (verify that it can die)
It certainly can't.

> KBugReport (new feature: should restart app)
??

> KCommand (split and move the non-GUI parts into kdecore - might also be a tool)
I thought about doing such a split. But I didn't find a good use case for that.
Who would provide undo/redo in a non-gui (but still kde) tool ??

> KFontDialog, Requester, Combo (tools?)
Tools makes more sense if it's non-gui, IMHO.
Most of kdeui (i.e. everything except the mainwindow/toolbar/action core) 
is already mostly a collection of independent classes which don't use kdecore
much anymore. So I would simply have kdeui/framework and kdeui/widgets.

> ui tools
> ========
> KWordWrap
> KAnimationButton
> KCharSelect*
> KDateWidget
> KTimeWidget
> KDateTimeWidget
> KLanguageButton
> KLed (convert to use QGradient)
> KProgressBar
> KRuler
> KStringListValidator
> KMimeTypeValidator
> KPixmapRegionSelector
> KRestrictedLine

The widgets should go to kdeui/widgets IMHO, but I'm not sure about things
like KWordWrap; I would make that kdeui/tools if the tools name wasn't already used ;)

> die
> ===
> KSelectionOwner, Watcher (move to klipper?)
Doubt it. Ask Seli, but I see:
kmenubar.cpp:      d->selection = new KSelectionWatcher( KMenuBarPrivate::makeSelectionAtom(),

> KPushButton
Hmm?? Since when does QPushButton know about KGuiItem?

> all of the KSpell (1) stuff
Yes.

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

> kde3support
> ===========
> KTreeWidgetSearchLine
Isn't that the new non-qt3support one?

> KInputDialog -> QInputDialog
Well if it's in kde3support then it's rather ->K3InputDialog.
Just to keep the same api and minimize the porting effort which is the whole point of kde3support.

> to kcontrol library
> ===================
> KCModule
I guess this (and kdebase/framework) means that kdebase being installed is becoming a
requirement before compiling other modules.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).