why kdelibs?

[Albert Astals Cid]

A Divendres, 29 d'octubre de 2010, Kevin Ottens va escriure:
> Hello,
> 
> Took this mail as a reply as Stephen wrote most of what I had in mind
> already. Thanks you dear Steve for this prompt use of your
> KMindReadingProxyModel. :-)
> 
> On Friday 29 October 2010 07:08:35 Stephen Kelly wrote:
> > Chani wrote:
> > > When I was at DevDays, I noticed that while people were very
> > > enthusiastic about Qt, I was getting a sort of "qt is all you need"
> > > vibe at times - a fine sentiment for promoting qt, but then, what
> > > about kdelibs?
> > > 
> > > And then I realized: what *about* kdelibs? I had no idea how to tell
> > > anyone why they should use the kde platform, what advantages it would
> > > bring. Hell, at this point I'm not even sure what's *in* kdelibs, or
> > > what the KDE Platform is.
> > > 
> > > After a quick skim of community.kde.org, I'm just as lost.
> > > 
> > > So I ask you: Why kdelibs? Why the KDE Platform? I *know* that we have
> > > all kinds of awesome in there, but what is it and why should people use
> > > it?
> > 
> > I didn't get a "Qt is all you need" vibe at DevDays, but the Qt
> > developers there are completely unaware that the kde libraries are
> > available and usable.
> 
> Well, and even if they claimed such a thing it's definitely a fallacy which
> would need to be pointed out...
> 
> > Most still think that KDE is a monolithic desktop environment, and
> > set of applications. Nothing independently useful or usable.
> 
> ... and to be debunked. If such a fallacy still spreads that's mostly
> because of this false perception.
> 
> > So awareness is one issue, and one which I'm trying to address. Another
> > is interdependence in kde libraries, and what I think of as
> > upside-down-ness in parts of the stack and modules. kdelibs is mixture
> > of two things: a set of libraries, and a platform.
> 
> +1 with all of that and the rest of your writing on the matter. From the
> work I'm doing now I reached the conclusion, we definitely have a form of
> schizophrenia in kde*libs which we'll need to solve at some point. Solving
> it will actually make our libraries an order of magnitude more desirable
> to third parties.
> 
> It's definitely something close to impossible to properly solve in a BC way
> at that point unfortunately. I'd love everyone to remember that thread and
> that particular mail once we start tinkering about a KDE Whatever 5.
> 
> > KJob is in the libraries conceptually, as is
> > KIMAP, whereas KStandardAction, which someone mentioned, KStandardDirs,
> > KSyCoCa, KGlobal etc are platformy because 1) They provide benefit to
> > well integrated KDE applications, and 2) They provide no benefit to Qt
> > developers who are not creating 'KDE integrated' applications. Qt
> > developers often have control over distribution of their own
> > dependencies and can be more specific in code about data directories etc
> > than KDE applications.
> 
> Note though that there's likely two things to keep in mind:
> 
> a) We have to be careful to not split our libraries too much, if they
> become too small and too numerous we'll very likely pay it in
> application/workspace startup time on some platforms (definitely need to
> be carefully benchmarked and so on, there's a trade-off to find).
> 
> b) Some of those "platformy" features you point out, we'll have to evaluate
> which one could/should be in Qt itself API wise (the KDE Platform then
> providing backends for it). For instance, nowadays what's the point API
> wise between KIcon("foo") vs QIcon::fromTheme("foo")? They both got very
> close lately... KStandardAction that you mention, why is it not handled by
> Qt directly? Just like it already does with QKeySequence::StandardKey.
> 
> If the open governance model for Qt ever comes true, there's opportunity
> for us to rollback some of this platformy features in Qt (API wise). I'm
> sure the pure-Qt MS Windows developers out there would love to have
> standard actions which play well in this platform, up to us to make it
> play well in our workspaces as well.
> 
> > Because of interdependence though, a developer who wants to use KIMAP
> > must also use KStandardDirs, KComponentData, KGlobal and everything else
> > they come with. It should be possible to use a an IMAP library without
> > depending on the entire 'integration platform', so I think of kdelibs as
> > upside-down.
> > 
> > Even if communication about the separate KDE Development Platform had
> > reached the Qt developers at DevDays, I don't know if they would care,
> > because they would want libraries, not a 'platform' with all the buy-in
> > baggage that entails.
> > 
> > The result for the Joe the plumbers^W^W^W Gregory Schlomoffs of this
> > world is privately managed ifdefs and hacked target_link_libraries
> > lines.
> > 
> > http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-developme
> > nt - platform
> > 
> > Thinking of the kde libraries in terms of how people like Gregory and
> > other software vendors which create and deploy (and self-manage the
> > deployment, paths, dependencies etc) could see and use them could be a
> > good way to make kdelibs more modular and independently and make the
> > 'platform integration pieces' appear much higher in the stack.
> > 
> > Anyway, making a list of (mostly-)independent libraries which are
> 
> > potentially interesting to a Qt developer is easy:
> At the light of my points above, assuming open governance of Qt running at
> 
> full steam:
> > KLocale: More powerful i18n than QObject::tr and friends. Based on
> > gettext.
> 
> Why not push its features in Qt itself?

Because getting them to accept things is a pain.

Because it requires you to give a license to Nokia so they do whatever they 
want with the code.

> 
> > All of those could be useful to 'Qt applications', and they only depend
> > on Qt for the most part, or other libraries in the list (KIMAP depends
> > on KMIME and KJob, but Qt has no equivalents for those). Conceptually
> > there's no reason for them to depend on 'the platform'.
> 
> And most of the time its Qt job to abstract "the platform". I know Thiago
> is already in this mood, and I approached him on that matter already, but
> I think he's right that at some point the KDE Platform should be just
> another platform supported by Qt.
> 
> I'd love to see a time where we'll provide a KDE Platform neatly abstracted
> away by Qt, and a KDE Libraries Collection which are add-on modules to Qt.
> Most of what is in kdesupport these days qualify: QCA, etc., it's time
> kdelibs gets cleaned up to reach a similar state.

You can not create Qt add-ons and still be as good as we are right now, since 
what you suggest would mean that kio would not be able to use the useful 
things kdecore and kdeui provide.

Albert