A little review of kdecore & kdeui

Thiago Macieira thiago at kde.org
Sat Apr 8 00:23:48 BST 2006

David Faure wrote:
>> >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.

Then why Qt? If they are standalone, shouldn't they link to no libraries 
at all (except for libc)?

No, there's a baseline that we get to choose: what are the libraries that 
these tools are allowed to build upon.

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

Yes, I had moved KCharsets out. I had also seen that you moved that stuff 
out of KIO.

But I didn't and still don't understand why. What does KCharsets do that 
requires KFilterDev? I see the header being included, but not used 

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

Not necessarily. See below.

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

Our analysis is based on current usage: KLockFile is used only by KConfig 
and one app, according to lxr.kde.org.

But this is one thing that we need people NOT to reimplement. If they ever 
need a locking file, they had better use the implementation we spent a 
long time making right.

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

Ok, a little clarification here: I consider kdeinit modules (not 
libraries, despite being called lib*) as part of an application. Some 
applications even use libraries, especially those that have plugins 
(example: kopete and libkopete).

When I had originally heard the proposal of tools back in Málaga, I 
actually thought of Helio and Boiko's presentation from the previous 
aKademy: reusable classes provided in source-code form. This would solve 
all of the problems of linking.

It is also possible to do that with a static library: this is how libtool 
does convenience library linking. I just don't know if it's portable -- 
and I think it isn't. I think --whole-archive is a GNU ld option.

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

Yes, of course.

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

The private header can be accessed from kio. In fact, it could even be 
installed, if necessary. But people shouldn't use it unless absolutely 

KIO is obviously one such case.

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

Not exactly... Ben and I have some more insight on future Qt development 
than we are allowed to disclose. And we have some power of influence on 
shape its future.

Like I said in another email, Trolltech is willing to do in Qt 4.2 what's 
needed by KDE.

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

No, but the squeezing style should be. Some squeeze the middle, some 
squeeze the ending of the text, etc.

Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech AS
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- 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/20060408/a8a10448/attachment.sig>

More information about the kde-core-devel mailing list