A little review of kdecore & kdeui

[Thiago Macieira]

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

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

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>