|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|
|Stephen Kelly||Oct 31, 2010 11:03 am|
|Juan Carlos Torres||Oct 31, 2010 11:38 am|
|Alexander Neundorf||Oct 31, 2010 1:33 pm|
|Cornelius Schumacher||Oct 31, 2010 1:35 pm|
|Chani||Oct 31, 2010 1:56 pm|
|Chani||Oct 31, 2010 2:08 pm|
|Albert Astals Cid||Oct 31, 2010 4:14 pm|
|Thiago Macieira||Oct 31, 2010 4:47 pm|
|Andreas Pakulat||Nov 1, 2010 12:38 am|
|Diederik van der Boor||Nov 1, 2010 1:26 pm|
|David Faure||Nov 2, 2010 5:33 am|
|14 later messages|
|Subject:||Re: why kdelibs?|
|From:||Stephen Kelly (stev...@gmail.com)|
|Date:||Oct 29, 2010 7:44:12 pm|
Replying to John and Kevin here.
John Layt wrote:
Some excellent points, and it makes clear the sort of areas we need to be working on. Currently choosing to use kdelibs or any other KDE library just as an extra Qt module usually means more pain, not less, which really should be our selling point.
Do we have a wiki page were 'what can be fixed now' and 'what needs fixing in KDE5' has been/can be written down? Perhaps a version of http://techbase.kde.org/Projects/Mobile/PlatformModifications but with a little more detail?
I have wanted to write this down in words for some time, so here it is:
While a lot of the dependency fixing would break BC and so can't be done in the KDE4 SC, I suspect a lot of 3rd parties would actually ship their own copy of of what they use anyway, rather than using shared libraries? In which case we can do compile time switches for them to just get what they need without all the other stuff? Of course there would be a lot of work providing the alternative paths, but it would be in preparation for KDE5 and thus less work to do then?
I would say make the split stuff available in KDE4 as KDE5Support. Then we declare KDE5 when the apps are ported and remove the KDE4 stuff. It's an option at least.
For example, KLocale needs KConfig on KDE platform to load the format settings, but a Qt program would not want those settings so a QLocale backend could be used instead and thus remove the need for KConfig. In fact, KLocale is a problem as if you don't have kdebase/runtime/l10n installed you get the C locale, and even if you do have the files there's no guarantee they will be the same as what QLocale will return for the rest of your app, or what your Win/Mac/MeeGo/Gnome system settings are. I'm working on that.
Cool. KLocale is an area I know very little about, but I want to change that. Actually one of the reasons I'm interested in splitting kdelibs is so that I can think about using it in Grantlee.
For those libraries like KIMAP and the itemview stuff that don't really need kdecore/kdelibs stuff at all perhaps kdesupport is the right place for them? Perhaps the 'K' name is also an issue, if they don't need K stuff, then just call them QSomething or a funky non-K name? From a promo point of view, we could then advertise libraries as being 'By KDE', 'Using the KDE Platform', and 'For the KDE Desktop'.
I counter-proposed merging kdesupport into kdelibs. I think in some cases, libraries went into kdesupport because they were functional, rather than platformy, so their authors didn't see any sense in adding the platformy dependency and baggage. That happened in the case of Grantlee and others too I'm sure. If something like Tier 1 existed when I started that, I would have put it there.
Having those things in a group we call kdelibs makes the release, promo and i18n machinery available to them as well as actually being part of the KDE community produce.
The other issue is platform portability, stick with Qt and you know it works on every platform with no extra effort, even if the tools fall short in some areas. Use kdelibs and you will have problems on Win and Mac trying to decide how to package and distribute. Work is ongoing on Win to make it happen, but Mac appears to have stalled somewhat?
It seems many packaging and distribution problems either fall away, because the author controls both, not a distro and not the user, or fall away because they exist and must be solved anyway if Gregory-the-Qt-developer or ACME Qt-using software vendor is creating software.
Of course, once the splitting work is done, and it's easily portable, then eternal vigilance is needed to make sure it stays that way, which probably means more stringent rules around kdelibs.
Right. But if split well, it might always be obvious where things belong.
Kevin Ottens wrote:
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).
To some extent I think this is already happening with kdesupport and the number random git repos growing.
As Jaime notes though it might be possible to build the libraries together if CMake'd from kdelibs/ and also make it possible to cd kjob && cmake. I'm not certain it's possible or sensible. Just another option.
Kevin Ottens wrote:
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?
KConfig: More powerful settings management than QSettings.
Why not improve QSettings to have it on par with KConfig?
These kinds of things would of course be better, but would require API removals and replacements in Qt. Those kinds of things can only be done by someone with a maintainer hat.
Even running at full steam, I don't think open governance will lead to anyone outside of Nokia to maintain anything in QtCore or QtGui. I think the decision to make Qt depend on gettext etc would need to come from within Nokia. I've discussed this to various extents with some trolls too.
Some of the stuff is getting in to Qt, but the copyright of the submitted classes needs to be clear. Whoever puts KIdentityProxyModel into Qt for example must have the authority to let Nokia redistribute it under other licenses. Many of the older libraries don't have such clear ownership.
Albert Astals Cid wrote:
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.
If we can find out what those useful things are we can move them to the platform level where they are still useful, right? Or make kio depend on the libraries that provide those useful things.
But you're right. Splitting like this will make keeping the same features harder (but not impossible) and would be a lot of work. More interdependence between libraries is easier, but makes independent reuse much harder. We just have to find out if it's worth it.
I think the interdependence of the libraries to each other and the platform is icky though. That's the main reason I make noises towards splits.
All the best,