Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 53

Thread: KDE Developers Discuss Merging Libraries With Qt

  1. #31
    Join Date
    Oct 2008
    Posts
    66

    Default

    Quote Originally Posted by TemplarGR View Post
    Imagine if the GNOME guys talked about merging
    Don't tell it other people in the Internet but this is already constantly happening.

    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.

  2. #32

    Default 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.

  3. #33
    Join Date
    Apr 2008
    Posts
    4

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Which company needs to both modify the Qt source code AND distribute those changes while keeping them secret?
    [snip]
    If anyone suggests closing KDElibs and making them proprietary, there will be a war of epic proporsions. I can't imagine ANY KDE contributor going along with that.
    KDELibs becoming proprietary/closed source isn't ever going to happen, that's for sure

    Apparently Nokia does make some money out of the commercial licenses or at least being in control is important enough for them, or they would have dropped those licensing requirements already. From what I've read it doesn't seem likely (at all) that they're going to change anything about that.

  4. #34
    Join Date
    Oct 2010
    Posts
    23

    Default 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.

  5. #35
    Join Date
    Apr 2008
    Posts
    325

    Default

    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.

  6. #36
    Join Date
    Oct 2007
    Posts
    297

    Default

    Quote Originally Posted by JantarMantar View Post
    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.
    you made me lol

    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.

  7. #37
    Join Date
    Oct 2007
    Posts
    297

    Default

    Quote Originally Posted by RobbieAB View Post
    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.
    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.

  8. #38
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by markg85 View Post
    you made me lolMeeGo is for mobile stuff and KDE certainly isn't (to heavy to run on a phone at the moment)
    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.

    "Compete" as in possible alternatives.

  9. #39
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  10. #40
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by allquixotic View Post
    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.
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •