Am Sonntag 31 Oktober 2010, 13:45:48 schrieb Matt Williams: > On 31 October 2010 12:37, Modestas Vainius wrote: > > Hello, > > > > On sekmadienis 31 Spalis 2010 14:04:28 Matt Williams wrote: > >> On 31 October 2010 11:53, John Tapsell wrote: > >> > On 31 October 2010 11:33, Mark Kretschmann wrote: > >> >> Hey all, > >> >> > >> >> after reading the whole thread that started with Chani's mail ("why > >> >> kdelibs?"), I think the noise level has become a bit too much there. > >> >> Cornelius had proposed this rather daring idea: > >> >> > >> >> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2 > >> > > >> > Sounds great. This should probably be done by picking a specific > >> > technology in KDE, and adapting it and merging it to work in Qt. > >> > > >> > A wonderful place to start would be kioslaves imho. This is something > >> > which has a real advantage, is relatively self-contained, and would > >> > provide a big advantage. Possibly it needs to be merged more with the > >> > Qt API though. > >> > >> So, if we decided that we wanted to merge KIO slaves into Qt, what > >> would the steps we go through be? If we're going to be doing this with > >> a number of classes we need to have a process which ensures that the > >> code is Qute enough, KDE still compiles against it (with minimal/no > >> code changes) etc. > > > > With my packager hat on: > > > > But what happens when you (KDE) decide that you really need a new feature > > of kioslaves for the next release. But the next Qt release is not due in > > 7 months or you (again) have trouble merging changes back to Qt with > > patience running out? Sure, developers compiling from source can patch > > Qt, install differently configured builds to different prefixes > > with/without specific features etc. But what are poor packagers supposed > > to do? Phonon situation all over again? It was *really* bad and my mind > > is still recovering from that experience. I really doubt I'm ever going > > to trust such merges to Qt again. > > > > In my opinion, KDE should keep libraries small, *modular* and develop > > them in- house. Try not to attach binaries and esp. daemons to the > > libraries. Maybe strip KDE branding from library names to gain wider > > acceptance. Only this way you as a project will be in control of release > > schedules and feature sets. > > Basically, what you're suggesting is to move as much (well, within > reason of course) of kdelibs 'upstream' into kdesupport. I think I > agree that this could be the way to go (at least for the short/medium > term). > > It doesn't solve our BIC/SIC problem (unless as I asked before: does > moving the real code out into kdesupport and keeping wrapper classes > in kdelibs solve either of those?) so we'd still need to make this a > KDE5 thing. Or would we just have to make it libkdecore.so.6 bump > while keeping KDE Platform/SC at version 4? It would be breaking our > BC promise but maybe we could get away with it? :) I am not sure but I don't see why this should cause problems, as long as the versions in kdesupport are in a different namespace or use a different naming. And as all (sic?) the clases in kdelibs use d-ptrs this should in my uneducated opinion just work. Still having wrappers for everything would be a lot of work. Who would maintain something like that? I mean imagine fowarding one signal was forgotten, what mess this could cause, even if a lot of unitests were written I doubt this would work flawless. So wrapper clases might appear like a nice intermediate step, but imo they would add more burden than help.