Don't tell it other people in the Internet but this is already constantly happening.
Originally Posted by TemplarGR
Many parts of old GNOME-libs where included into Gtk+ to get rid of the many external libraries GNOME was constantly blamed for. For example the library "GNOME-PrintUI" was merged into Gtk+ at version 2.20. Many other parts are also now included in Gtk+ and are not GNOME-specific any longer.
But back to topic :
I don't understand why this idea such a problem for some people? There was always a constant flow of KDE-developments into Qt. I don't exactly know when but i think that the printing-part of Qt was once developed for KDE and then merged into Qt (Maybe version 2.2 or 3.0?).
Merging parts of KDE into Qt was never a real problem back in the past.
What next, merge KDE with MeeGo too?
I might be naive, but didn't Qt's current expansion came because of MeeGo's needs? I haven't tried MeeGo, but isn't it a DE based on pure QT, (or will be pretty soon)? The way MeeGo is progressing, they might be aiming for desktop pretty soon. They already compete with KDE on netbook. So would merging MeeGo and KDE be the next logical step? Not that I believe KDE and MeeGo merging will be necessarily a good thing for Linux; but if there can be a talk of merging KDE and GNOME (albeit it was a long time ago), I think KDE and MeeGo merge should be a relatively easier.
Not too fast
I think the process does not necessarily need to be so sudden, I think we can start with small things and progressively slim down kdelibs until they disappear (or leave them very slim).
Like this guy said (http://lists.kde.org/?l=kde-core-dev...3163506010&w=2) kdelibs can be divided in 4 parts:
1. Small improvements to the Qt Libraries
This are things that were done when qt wasn't truly open (It has started trying to be AFAIK), and are small changes, like adding a little option to that widget making that a bit nicer, And most of these changes could be merged into qt (if kde contributors accept qt license and nokia accept them)
2. Additional Functionality
This kind of things are also like "1", if nokia wants them and contributors don't have any problem with qt license, then they could be merged.
3. KDE Classes that do not require the complete KDE Environment
This things are kde specific and should stay in kdelibs(things like kde styling classes)
4. KDE Classes that require the complete KDE Environment
Same thing as "3"
This way kde will progressively get closer to qt. So making a kde app and port it to qt and vice-versa will be easy
Also to keep BC compatibility: Kdelib classes that go upstream ("1" and "2" I guess) should become wrappers of qt classes, but should be flagged as deprecated, and in kde 5 they should be dropped.
Also if nokia doesn't want any of kdelibs we can't do nothing about it, but they may want part of it, and getting that bit would already be an advantage.
Why the assumption that KDE needs Qt to support such a merger... They can always take the same approach LibreOffice did and simply fork Qt if they feel the benefits of such a merger are worth it.
Nope, that's not possible and not the intention to begin with.
Originally Posted by RobbieAB
The intention is to be more tight with upstream and clear duplication between kdelibs and Qt. It certainly is not the intention to fork Qt... That is simply out of the question and besides, KDE has by far enough people to keep a fork up to date thus another reason it's impossible.
There's constant developement on Plasma Mobile and Tablet version also there are early versions of KOffice and KDE PIM Mobile. As far as I know there are also many other KDE projects going mobile at the moment, like Amarok and probably KDE Games. I don't know what's their schedule, but I doubt it will take too long before they are truly going mobile. Considering that first MeeGo phones will probably be relased in April 2010, they do "compete" in same sector. So only platform that KDE doesn't support which MeeGo does is IVI in near future.
Originally Posted by markg85
"Compete" as in possible alternatives.
The portability of Qt to new platforms, and the ease with which one can build all of Qt with all the bells and whistles, is a function of the complexity of Qt and how many dependencies it has. If KDE is to become part of the "full" Qt experience, then we have yet another slew of third-party dependencies that KDE depends on but Qt4 currently does not. This is effectively de-modularizing something that is currently very modular.
The problem is, by making KDE part of Qt, you essentially say to Qt developers, "hey, it's fine to use KDE APIs in your ordinary Qt apps!" So what happens then? People who do not typically use a KDE desktop, but do run ordinary Qt apps (the way they are designed today), would have two choices: (a) Compile Qt without KDE support, which would break (either at build-time or runtime, depending on whether they do dynamic linking) any apps that tangentially decide to pull in a "Qt-KDE" API or two for convenience. Or (b) build the entire KDE as an added dependency.
And for (b), you end up with something like :- a KDE API uses one or more KDE daemons, such as knotify, or kded, or nepomuk. To properly support the API, it has to start the daemon. So you're running your GNOME desktop happily along, and next thing you know, half of KDE's daemons have started in the background! But since you aren't running a proper KDE session, you get weird errors, like things assuming they can talk to kwin/plasma when in fact kwin/plasma aren't running, and so on and so forth.
My view is that, as it stands, the entirety of Qt is a nice, DE-independent programming framework that has a lot of high and low-level utility functions, but does not actually tie you down to a specific desktop. You can run Qt apps without popping up all kinds of DE-specific daemons, settings managers, communications tunnels, indexing services, and so on. They run well on GNOME, LXDE, XFCE and any other custom DE you could come up with. This seems like a proper way to layer the software, keeping the DE-specific stuff (i.e. KDE) separate.
There is a reason the desktop is modular and layered. You don't merge GTK into the X server, right? You don't merge PulseAudio into ALSA, right? You don't merge init into the kernel, right?
This is indeed a radical change, but I don't see any evidence for believing that, on a technical level, it would be a good move. It would bring KDE one step closer to trying to take over the entire desktop market by sheer technical requirement (since anyone who wants to support a Qt installation that can run an arbitrary Qt app would have to install KDE), but it wouldn't make KDE the software perform any better, have less bugs, or new features.
And, it would open up the possibility for Qt-KDE to be licensed under the proprietary license that Nokia sells. So you could see desktops in a few years based on a proprietary KDE, with closed-source modifications! This is a really troublesome thought.
Isn't it obvious that if this is ever going to happen they won't leave those as depencies? It's not about integrating the whole KDE DE but KDElibs, not even all the KDE pilars if any. Even the KDElibs would be scattered around the modularized Qt piece by piece where they belong and maybe some of them would be in seperate module like Qt Desktop or whatever, some overlapping libs would be removed from both projects and so on- I mean it has to be done that way.
Originally Posted by allquixotic
Tags for this Thread