A little review of kdecore & kdeui

[David Faure]

On Saturday 08 April 2006 01:23, Thiago Macieira wrote:
> >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.

kcharsets.cpp:        KFilterDev gzip(dir + "/" + charMapFileName);
but the code is currently commented out for some reason (lack of maintainer
after an incomplete port to qt4?).
Anyway the idea was: to be able to read gzipped files there.

And anyway, a possible idea is to leave kio to what it was about in the first
place (network transparency) and move most other things in kio to kdecore and
kdeui. Or moving all of it into kdecore/kdeui in order to reduce the number of
libs that kde apps link to (which kde app doesn't have a file dialog or network
transparency? Almost none, so the separation doesn't make sense, especially
when it comes with a runtime performance price).

But this thread is about kdecore + kdeui, let's come back to kio later :)

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

Exactly. So KLockFile should remain public.

> >> >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. 
Sure, but as far as ld is concerned, they are libs.

> 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.
Yes, I like the idea (for classes that only 2 or 3 apps use).

> 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.
Ah. I thought there was some -fPIC problem or something.

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

Yes. But I see also a tendency of doing more than the strict minimum :)
We can handle complex completion in KDE, I don't see a need for it to be in Qt
(given that I fear for the loss of flexibility). But I see that it can't hurt to at
least consider it.

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

No, this shouldn't be style dependent, but data dependent.
A listview is usually squeezed on the right, but a URL is better squeezed
in the middle so that you can still see the protocol and the filename.

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