A little review of kdecore & kdeui

[David Faure]

On Thursday 06 April 2006 01:21, Thiago Macieira wrote:
> In any event, the question of whether we should have a libkdenetwork core 
> library is still a valid one

BTW, let's not forget that many of those who investigated application startup times
have said: we should group our libraries, not split them. Some even suggested a
"libkde" with everything in it. I know that it seems messy, I know that Qt is going the
split-up route (so we should do at least a core/gui separation), but still, we can
use subdirs inside the libs code (like qt) while still providing only few (bigger) libs
rather many smaller ones, since it seems to help startup times.

> >./kapplication.cpp:556:  (void) KClipboardSynchronizer::self();
> What does that do? Why do we need a clipboard synchroniser? What's missing 
> from QClipboard?
No idea, better ask Lubos or check the logs.

> >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).
> 
> That's Benjamin's position. Mine is that we want to build upon KDE 
> existing functionality, so I would let them link to kdecore+kdeui+kio.
That sounds like the current kdelibs/kutils then [which also links to kparts,
but kparts is too small to be its own lib in kde4 anymore, it should be merged up].
Your solution would also go against the idea of reusing "tool" classes in qt-only
programs. That means no dependencies to other kde libs. If there are deps to
kde libs then those are not standalone tools at all.


Anyway, in order to minimize the number of libs over all, I think we should
just put those (non-gui) tools in kdecore/tools and link them into libkdecore.so.
I would also move KArchive and derived classes, and gzip/bzip2 filters there btw.
Ah about those, you said "moving them to KIO" in your proposal? Haha. I have
just moved them up from kio into kdecore, since kcharsets needs them.
(Well maybe that makes kcharset part of kdecore/framework again).

> >But I thought it wasn't possible to link a static lib into a shared lib?
> It isn't.
OK, then we can forget immediately about providing some tool classes in a static lib.
We might as well just install the .cpp files instead :-)

> >If that's the case, how would kdecore's KConfig use KLockFile then?
> 
> It wouldn't be a public class called KLockFile. It would be a simple lock 
> file mechanism working behind the scenes.

And how would other apps do locking then? As I said, I see a need coming up for it,
even though I don't know if the current implementation fits kdepim's needs.

> >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...
> 
> That defeats the purpose of the tools: it's not used by the libraries at 
> all. It's used by applications.

You didn't understand what I wrote, I think... there is almost no app code in kde,
all the code is in libraries...
-rwxr-xr-x  1 dfaure dfaure    8298 Mar 30 19:24 konqueror
-rwxr-xr-x  1 dfaure dfaure 3890424 Mar 30 20:50 libkdeinit_konqueror.so

> I still maintain my position that file descriptors are to be avoided in 
> KDE code, especially in KDE applications' code. Where possible, use the 
> existing functionality (QFile, QFileInfo, QtNetwork/KNetwork, etc.). Note 
> that all of those derive from QIODevice.

I agree about apps, but I maintain that kdelibs itself needs it very much.
For KDE_lstat to get the user/group of a symlink (which QFileInfo can't do).
For calling utime() (which at least job.cpp and kio_file need to do) - well I could
convert QFileInfo::lastRead() I guess, but if I'm going to make one unix-specific
system call I might as well use KDE_lstat as well to get the data in the same format...

> In fact, kde_file.h should be a private header (_p.h)

If that means all of kdelibs can still use it then I agree... But I guess you mean
non-exported, and then kio wouldn't be able to use it anymore.
[Well, one idea is to merge kio with kdecore, but I'm not sure how yet precisely]

> Wouldn't you love if QLineEdit had text completion as powerful as KDE's? 
> We would too.
Actually we need text completion to be even more powerful than KDE's at this
point, since kmail would need substring completion rather than startsWith-type
completion. Completion is a such a huge beast to tackle, and Trolltech seems
already so overwhelmed with more important things to do in Qt, that I don't
actually believe that in the foreseeable future, Qt will provide a completion
mechanism powerful enough for KDE's needs. But I'm happy to be proven wrong :)

I realize now that your list was more in terms of "what to do in Qt",
rather than "how to reorganize kdelibs now". My idea was rather to discuss
kdelibs reorganization, mainly, so obviously the angle is different (I was basing
my thoughts on what Qt does now - or will do for sure in 4.2 - rather than on
what Qt might do one day ;)

> >> KSqueezedText (I think it's already in)
> >
> >In where? ;)
> 
> Hmm... itemviews has one already. It's style-dependent. So why not have it 
> in other widgets?

Right ("Qt can do" vs "Qt might do" here again).
But it shouldn't be style dependent, whether KIO's progressdialog's QLabels
are squeezed; they should always be, to avoid wider-than-screen dialogs.

> >> 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.
> 
> You're missing the point: we'd like to see that convenience stuff rolled 
> back into Qt.

OK - good luck convincing the "minimalist API" people at TT :-)

> >> 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).
> 
> Right... spellchecking would be a problem.

Not a problem, a reason for KTextEdit's continued existence :)
The need for code in kdelibs is not "a problem" IMHO.

> >> KCompletionBox (text completion)
> In any event, this should not be a public class.
It was needed in kdepim's more advanced completion - see Till's separators in the LDAP completion.
Flexibility is good.

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