Announcement
Collapse
No announcement yet.
KDE Developers Discuss Merging Libraries With Qt
Collapse
X
-
That won't happen. Both environments have different kinds of desing phisolophies and one is written in GTK and the other in Qt. People don't just magically learn new toolkits, voluntary developers develope what they want to develope that's why there always will be atleast two different large scale desktop environments and bunch of small ones.
For example KDE doesn't want to hide settings, Gnome has opposite idea and hides everything they can. KDE tends to do more powerful apps and Gnome keeps it simple. They have incompatible HIGs and developemt platforms. To sum it up, you can't just abandon one.
Leave a comment:
-
KDE has serious usability issues and GNOME is so simple its frustrating to use sometimes. People need to pick one and concentrate development.
Leave a comment:
-
Originally posted by allquixotic View PostAnd for (b), you end up with something like :- a KDE API uses one or more KDE daemons, such as knotify, or kded, or nepomuk.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by markg85 View Postyou made me lolMeeGo is for mobile stuff and KDE certainly isn't (to heavy to run on a phone at the moment)
"Compete" as in possible alternatives.
Leave a comment:
-
Originally posted by RobbieAB View PostWhy 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.
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.
Leave a comment:
-
Originally posted by JantarMantar View PostI 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.
Right oke, that suggestion is just stupid. MeeGo is for mobile stuff and KDE certainly isn't (to heavy to run on a phone at the moment). Besides that Qt and MeeGo are the same company : Nokia and KDE is community based. There is no single person that can say: "we merge with MeeGo".
What nokia "can" do is fork KDE and merge that into MeeGo but that;s seriously stupid to even consider for Nokia.
@someone else. please keep in mind that if kdelibs is sliced in Qt KDE modules that nokia still has absolutely 0 control over it and that the modules follow it's own release schedule. It's a module after all! And i see the module part as the most beneficial and likely to happen.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
Leave a comment: