|Chani||Oct 28, 2010 4:11 am|
|Pau Garcia i Quiles||Oct 28, 2010 4:28 am|
|Ivan Cukic||Oct 28, 2010 4:34 am|
|Chani||Oct 28, 2010 4:40 am|
|Ivan Cukic||Oct 28, 2010 4:59 am|
|Thomas Lübking||Oct 28, 2010 5:17 am|
|Milian Wolff||Oct 28, 2010 5:36 am|
|Anders Lund||Oct 28, 2010 5:44 am|
|Thomas Lübking||Oct 28, 2010 5:55 am|
|Milian Wolff||Oct 28, 2010 6:17 am|
|Allan Sandfeld Jensen||Oct 28, 2010 6:27 am|
|Chani||Oct 28, 2010 6:32 am|
|Ivan Cukic||Oct 28, 2010 7:54 am|
|John Layt||Oct 28, 2010 8:47 am|
|Stuart Jarvis||Oct 28, 2010 8:56 am|
|Sven Langkamp||Oct 28, 2010 10:43 am|
|Matt Williams||Oct 28, 2010 11:52 am|
|Pau Garcia i Quiles||Oct 28, 2010 12:08 pm|
|Vivek Prakash||Oct 28, 2010 12:13 pm|
|Milian Wolff||Oct 28, 2010 12:21 pm|
|Pau Garcia i Quiles||Oct 28, 2010 12:53 pm|
|Pau Garcia i Quiles||Oct 28, 2010 12:59 pm|
|Albert Astals Cid||Oct 28, 2010 1:07 pm|
|Albert Astals Cid||Oct 28, 2010 1:16 pm|
|Pau Garcia i Quiles||Oct 28, 2010 1:33 pm|
|Jos Poortvliet||Oct 28, 2010 4:56 pm|
|Stephen Kelly||Oct 28, 2010 10:08 pm|
|Gregory Schlomoff||Oct 28, 2010 10:57 pm|
|Jaime||Oct 29, 2010 2:28 am|
|Keith Rusler||Oct 29, 2010 7:52 am|
|Kevin Ottens||Oct 29, 2010 8:30 am|
|Chusslove Illich||Oct 29, 2010 9:01 am|
|Kevin Ottens||Oct 29, 2010 9:08 am|
|John Layt||Oct 29, 2010 9:17 am|
|John Layt||Oct 29, 2010 9:39 am|
|Robert Knight||Oct 29, 2010 9:41 am|
|Albert Astals Cid||Oct 29, 2010 10:55 am|
|Chani||Oct 29, 2010 12:19 pm|
|Stephen Kelly||Oct 29, 2010 7:44 pm|
|Cornelius Schumacher||Oct 30, 2010 1:31 am|
|Andrea Diamantini||Oct 30, 2010 2:11 am|
|Juan Carlos Torres||Oct 30, 2010 4:04 am|
|Sebastian Trüg||Oct 30, 2010 4:31 am|
|Tom Albers||Oct 30, 2010 7:24 am|
|Richard Dale||Oct 30, 2010 8:01 am|
|Milian Wolff||Oct 30, 2010 9:04 am|
|Alexander Neundorf||Oct 30, 2010 9:11 am|
|Alexander Neundorf||Oct 30, 2010 9:15 am|
|Alexander Neundorf||Oct 30, 2010 9:35 am|
|Alexander Neundorf||Oct 30, 2010 9:48 am|
|Albert Astals Cid||Oct 30, 2010 10:00 am|
|Alexander Neundorf||Oct 30, 2010 10:04 am|
|Parker Coates||Oct 30, 2010 10:44 am|
|Cornelius Schumacher||Oct 30, 2010 10:50 am|
|Cornelius Schumacher||Oct 30, 2010 10:52 am|
|Luciano Montanaro||Oct 30, 2010 10:53 am|
|Mark Kretschmann||Oct 30, 2010 11:22 am|
|Albert Astals Cid||Oct 30, 2010 11:23 am|
|Albert Astals Cid||Oct 30, 2010 11:34 am|
|Stephen Kelly||Oct 30, 2010 1:43 pm|
|Marco Martin||Oct 30, 2010 2:27 pm|
|Marco Martin||Oct 30, 2010 2:30 pm|
|Stephen Kelly||Oct 30, 2010 2:58 pm|
|Thiago Macieira||Oct 30, 2010 5:35 pm|
|Albert Astals Cid||Oct 30, 2010 6:31 pm|
|Henry Miller||Oct 30, 2010 6:32 pm|
|Thiago Macieira||Oct 30, 2010 10:26 pm|
|Oswald Buddenhagen||Oct 31, 2010 1:29 am|
|Alexander Neundorf||Oct 31, 2010 2:11 am|
|Marco Martin||Oct 31, 2010 2:23 am|
|Cornelius Schumacher||Oct 31, 2010 3:20 am|
|Torsten Rahn||Oct 31, 2010 7:21 am|
|Boudewijn Rempt||Oct 31, 2010 7:58 am|
|Mark Kretschmann||Oct 31, 2010 8:18 am|
|Thiago Macieira||Oct 31, 2010 8:39 am|
|Sven Langkamp||Oct 31, 2010 8:43 am|
|Boudewijn Rempt||Oct 31, 2010 8:54 am|
|Thiago Macieira||Oct 31, 2010 9:03 am|
|25 later messages|
|Subject:||Re: why kdelibs?|
|From:||Gregory Schlomoff (greg...@gmail.com)|
|Date:||Oct 28, 2010 10:57:15 pm|
On Fri, Oct 29, 2010 at 12:08 PM, Stephen Kelly <stev...@gmail.com> 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. Most still think that KDE is a monolithic desktop environment, and set of applications. Nothing independently useful or usable.
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. 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.
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.
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:
KLocale: More powerful i18n than QObject::tr and friends. Based on gettext. KConfig: More powerful settings management than QSettings. KJob: Asynchronous APIs for executing tasks. Includes progress reporting. Kross: Cross-language script interpretation Threadweaver: Threading APIs to suit practical needs of applications. KDEUI/ItemViews: Add-ons to the Qt itemviews API. KMime : Qt based library for handling emails KIMAP : Qt based library for asynchronous IMAP communication
I've only included things which I have some familiarity with. The list could be made longer of course.
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'.
The fact that they can't be used independently out of the box makes communicating about them difficult. "If you're using Qt ItemViews for serious business, you want to use the stuff in kdeui/itemviews, but it depends on klocale, kconfig, kfile etc etc at shipping time, none of which are used." Actually kconfig is used in one place, but that's removable.
Hopefully there's some coherence in all that. I had intended this email to be much shorter.
All the best,
Hehehe, I was planning to jump into this thread and share a few ideas, but now that Stephen drew me in, I almost have to :)
So, my story is: I'm not a KDE user, but I'm a Qt application developper, and I found *very* useful things in kdelibs. KIMAP is now a central part of our app, we are using KJobs everywhere we can, and we are contibuting back with KSmtp, a job-based SMTP library (more on that in a future announcement).
But, as kdelibs / kdepimlibs are now, I see 2 main problems:
1. Out of the box, the build process is monolithic and involves building a ton of things with a huge amount of dependencies. I haven't counted, but there are probably 5-10 million SLOC to build.
2. Many modules assume that they can find settings / configuration in certain places, or they are providing their own dialog / UI elements to report errors and information, and this is a very bad thing when you're not using the dektop environment side of KDE.
Point #2 is the more problematic, because it simply makes it impossible (instead of just hard) to use some libraries.
In order for a library to be usable by Qt developpers, it must take all it's input from the program using the library, and it must return all it's output to the program. There must be no side-effects, no dialogs, no reading of configuration files, etc... And this is not the case today, because several libraries assume that they are going to be used in the full KDE desktop environment.
So, my feeling is that right now KDE is a closed ecosystem : it provides you with everything you need to make KDE apps on the KDE desktop. This is great, but it's easy to understand why it's not very appealing to Qt-only developers.
What can we do ?
1. Identify, as Stephen did, independent libraries that are useful to Qt developers 2. Split kdelibs into a part that comprises only those libraries, and a part that answers the problems specific to the desktop environment 3. Maybe have a clear branding, with different names
Thanks for this highly interesting discussion,