Slashdot Mirror


Unifying GTK & QT Theme Engines

An anonymous reader writes "Some guy on kde-look recently released code that makes gtk apps use the current qt theme. Seems this would be a major development for unifying the 2 environments. From the URL: This GTK theme engine uses the currently selected QT style to do it's drawing. Basically, it makes your GTK apps look like QT ones. "

13 of 405 comments (clear)

  1. Just a style by gilesjuk · · Score: 4, Interesting

    It's actually just a style that makes them both look more consistant. Unifying the API is the hardest job and I don't really want to see a unified API as it would be a bit of a mongrel. To me I think the best way forward is for either QT or KDE to die and the developers of the losing project to join the winning side.

    Merging QT and KDE would be like merging Linux and one of the BSDs.

    1. Re:Just a style by arvindn · · Score: 2, Interesting
      If you want a unified API, look no farther than wxwindows.

      It has backends for qt, gtk, ms-windows etc. Trouble with it is that it adds an extra layer of complexity for the programmer and dependency for the end user.

  2. Unifying to look like what? by Gilesx · · Score: 3, Interesting

    The only true way to unify the two DEs is to get both camps to agree on a common widget set.

    I, like many other Gnome users, chose the Gnome DE because of it's professional appearance - something which I feel KDE doesn't even come close to. There is no way I'd want to replace my Gnome widgets with KDE widgets, and I'd bet the farm that KDE people would feel the same way about the reverse.

    There are many half hearted, rush desktop unification jobs at the moment. Unfortunately the only way that we're ever going to see true unification is if everyone agrees to work on it simultaneously at a deeper level than just aesthetics.

    How can you unify two groups of people that aren't even on the same page?

    --
    Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
  3. Licensing? by IamTheRealMike · · Score: 3, Interesting
    This is interesting for sure, but what are the licensing implications of this? Can anybody tell me?

    GTK is LGPLd. That means it can be used by proprietary software (and in fact, sometimes is). If I use this theme engine does that mean I can no longer run proprietary software that uses GTK because I'd be linking it with GPLd code?

    Perhaps the same concept should be applied but in reverse - a Qt theme engine to use GTK. There seems to be more experience going this way too, for instance XUL is already GTK themable and it works nicely.

    1. Re:Licensing? by Ianoo · · Score: 3, Interesting

      No I don't think this works at all. In the absence of repugnant EULA agreements from certain companies like Microsoft I can modify and combine software however I want on my own machine to suit my own needs. The GPL doesn't say you must make the source code available if you modify, it says you must make the source code available if you distribute. I can (and do) modify GPL and LGPL software to suit my needs on my own machine without any intention of ever redistributing these modifications, mostly because they're silly and complete messes (for example I've hacked various bits of GNOME's panel system to suit my own needs, such as removing the "Actions" menu from the Foobar).

      Hence if I take commercial GTK applications and GPL'd GTK applications and commercial QT applications and GPL'd QT applications and install them on my own machine, I can install whatever the heck I like to change and/or modify their behaviours at runtime. This themeing engine doesn't have licensing issues at all.

  4. Okay, now... by Janek+Kozicki · · Score: 3, Interesting

    I want Mozilla and OpenOffice to use a widget set of my choice (no matter which one I choose - qt, gtk, gtk2 ....)

    btw, it reminds me of wxWindows - a set of tools that allow you to compile your programs under different OSes using native widget sets of your choice. All widget sets are supported, but the widget set is chosen during compile time.

    --
    #
    #\ @ ? Colonize Mars
    #
  5. Re:ummmmm... by plj · · Score: 4, Interesting

    "making GTK2 apps use QT" != "Unifying"
    "making GTK2 apps use QT" == "How to migrate off GTK2


    Don't be ridiculous. There are many applications that are built completely around GTK(2). I, for one, usually prefer KDE over Gnome, but I've always found it much harder to live completely without GTK apps that completely without QT apps.

    Both are great toolkits with their own pros and cons - just use the right one for the right job.

    Personally, though, the feature I'd most like to see in GTK would be the chance to move the menubars of all apps to the top of the screen like on Mac OS, just as I can do with QT apps.

    --
    “Wait for Hurd if you want something real” –Linus
  6. Also worth checking out... by Anonymous Coward · · Score: 2, Interesting

    Is SodiPodi, the famous vector image editor. It is a GTK program that uses the KDE file and print dialogs.

  7. Re:Widget Mania by Sleepy · · Score: 5, Interesting

    >Call me crazy, but I'm glad we've got a choice of desktop environments.

    Except for a few "journalists" and controversial posters, I would bet that most people agree.

    >Not to knock the KDE folks, but I happen to prefer GNOME. If desktops were to somehow "unify," and that meant all we had left was KDE, I'd be more than a bit peeved.

    KDE will never be the dominant desktop. No offense to anyone pro-KDE. By the time this all works out, we'll have a KDE and GNOME that is so different from today's that we will not remember what the API wars were about.

    Wrappers, unification API's, and freedesktop.org are bringing the two sides together where it makes sense. It makes sense in a LOT of places that aren't talking yet, but I say in time it will work out.

    I'd LOVE to see KDE and GNOME use "common API's" for file dialogs. Why the hell NOT? An application should just say "file_dialog_common()" and then the user/desktop/distro settings determine WHO draws it. It doesn't matter. Desktop-specific features are EXTENSIONS. Granted, a lot of people thought GTK 2.2 and 2.4 file dialog was sub-optimal. Hopefully in the future with GTK 2.6, there will be some interest in at least standardizing the function calls, if not the actual code itself.

    People won't shut up about which API "rules" until much of what the API's provide has been turned into a commodity, as in this example. The revolution will not be televised. ;-)

  8. Re:Thank Goodness by IamTheRealMike · · Score: 2, Interesting
    That feature has been discussed a few times by the Gnome team I think, but the general consensus is that nobody cares enough to actually implement it. You can change the colours in GTK, but there is no UI for it because the theme picking stuff is already complex enough without loads of stuff for "color themes" as well.

    Personally I don't find it to be an issue, but whatever floats your boat....

  9. I've heard for years... by halivar · · Score: 2, Interesting

    I have heard for years (How many? Almost ten? Might be wrong) that KDE was going to come to a "dead end" because of (inster one: non-GPL, strict-GPL-non-commercial, closed development, pact with the devil, etc.), and that Gnome would eventually dominate due to its keeping with the "true spirit" of the FOSS movement.

    I'm still waiting.

  10. Re:KDE vs Gnome, battle of philosophy by Findus+Krispy · · Score: 4, Interesting

    I find it always funny that KDE supporters list re-use of existing libraries as a big minus point in Gnome, as if it is a bad point to re-use and adopt none-Gnoome supporting libraries,


    Actually both communities are correct in their approach -- both are refreshingly pragmatic.

    If you have a toolkit available to you as good as Qt, which makes re-use *very* simple, then you may very well realise that it would be easier to re-write existing functionality for that framework, rather than having to create a new framework yourself.

    On the other hand, if you had no such library in the first place, you would see that it would be easier to re-use the myriad of existing software, and develop/grow a library that explicitly enables that.

    Both approaches are equally valid given the differing starting positions of their projects.


    I find the KDE community extremely vicious against everything not KDE, ...


    No, niether the KDE or Gnome communities are vicious, it's just the fringe lunatics that pretend to represent these communities that talks all this crap. And they mostly do it here on Slashdot.

    If you do some development, or just subscribe to the lists, you'll see exactly what I mean. Lot's of nice people just having fun developing quality code. Hurrah for Gnome and KDE!
  11. Unification by be-fan · · Score: 2, Interesting

    Its interesting how people ar deriding this sort of "look-based" unification. The truth is that "look-based" unification has worked just fine for Microsoft. I use a mostly KDE desktop, and only once in a while do I have to start a GTK app. The same thing is probably true for GNOME people --- they only have to start a non-GNOME app on occasion. If you use MS Office, you're automatically using at least two toolkits on a Windows desktop. Windows has many toolkits that major apps use on a regular basis. Its nearly impossible to run a normal Windows desktop without regularly encountering at least a few.

    Now, why do Windows users think their desktop is so unified, when in practice, *NIX desktops are really more unified? Because Windows toolkits look kinda the same! Windows's "unified look and feel" is based entirely on unification of themes, rather than on any real technical unification.

    --
    A deep unwavering belief is a sure sign you're missing something...