A little review of kdecore & kdeui

[Thiago Macieira]

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

I've seen that. I'll see if the feature can be added.

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

This is actually my own code. And while QtNetwork and KNetwork follow a 
similar design concept -- since they were conceived together 3 years ago 
when I discussed with the Trolltech developer how we could approach the 
situation -- they differ completely in a basic concept. So the two 
libraries are completely incompatible with each other, because they can't 
agree on how a remote address is supposed to be represented.

QtNetwork uses a QHostAddress and an int and they're looked up separately. 
KNetwork uses a pair of QStrings and they always come together (a node 
name has no meaning without the service name). I still prefer my own 
solution, obviously :-) It's also more academic because people are used 
to "port numbers" and none of the KNetwork socket classes let you specify 
a port number.

That said, however, QtNetwork has a lot more developer time going into it 
that I can provide to KNetwork in my spare time. And given the weird, 
corner cases that I've come across here at Trolltech (mostly on 
WIndows-related brokenness) that QtNetwork can handle, I fear that for 
the overall stability we should maybe switch.

I don't know that yet.

In any event, the question of whether we should have a libkdenetwork core 
library is still a valid one -- even more valid if we switch to 
QtNetwork. Right now, there is no QtNetwork dependency anywhere. And, 
besides, I still plan on adding a few more classes there: completing SSL 
support, basic network interface enumeration, enhance the proxying 
mechanism, if possible integrate with KProtocolManager.

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

What does that do? Why do we need a clipboard synchroniser? What's missing 
from QClipboard?

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

>But I thought it wasn't possible to link a static lib into a shared lib?

It isn't.

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

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

If it's X11-specific, it shouldn't be a public class.

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

Sorry, I had written the kdecore.txt file before the discussion.

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 realise we can't get rid of file descriptors completely, but they should 
not be exposed as part of the API, ever.

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

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

KUrlLabel has the option to emit signals when URLs are clicked. This is 
one way.

The other is to use the desktop integration API that has just come out 
today, from the Portland project.

And, as I said, this is something that in our (Ben's and mine) opinion 
should be in Qt. If we can do it, it's another story completely.

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

Wouldn't you love if QLineEdit had text completion as powerful as KDE's? 
We would too.

If the text completion that QLineEdit provides, if and when that happens, 
isn't suitable for KDE, then we still use KLineEdit.

In any event, you raise some interesting points about the shortcuts. I 
don't understand about the text completion modes: do we need all 5 of 
them? And configurable in the RMB popup menu?

I'm asking if we couldn't compromise in off-loading the maintenance work 
to Trolltech at the expense of losing some of the advanced and 
not-often-used functionality. (if it is a common functionality, then we 
need it, of course)

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

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

>> KUrlLabel
>
>Replaced with...?

The same thing that replaces KActiveLabel.

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

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

Well, if Qt has a text completion framework, it has to have the drop-down 
box too, right? :-)

In any event, this should not be a public class.

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

I undertand, but why? And can they be made to derive from QAction, at 
least? Cursory glance reveals they share much of the same functionality 
and API (even some of the properties!).

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

Ooops, that was KCrash.

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

We came to the same conclusion when going through the list of classes. I 
don't know if it's worth splitting the libraries for cleanliness' sake, 
but we definitely need split directories.

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

Is that for the Paste button? I.e., enable the button only if there is 
something in the clipboard? If so, this is a private class.

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

I thought this could be merged with KStdAction + widgets. Maybe I was 
wrong. But remember we did a cursory look into all classes, by looking at 
the header files and lxr.kde.org for some of the unusual classes (my 
personal favourite are the KXYSelector and KArrowButton).

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

Is KCModule used for anything outside kcontrol?

Is KCModule required to embed a kcontrol config page into an application's 
config page (like kicker or kdesktop)?

-- 
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/20060406/2617619c/attachment.sig>