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

Comments

Unification in the *nix world

[W32.Klez.A]

While this may seem like a minor thing to some people, every bit of interoperability and unification helps. Naysay as much as you want regarding Microsoft, but the reason why they have the market share is because of the unification present (at least in appearance ;-). If OSS projects (and non-OSS friends of them) can't come together, they should at least work together.

Re:Unification in the *nix world

[Christopher Whitt]

What interoperability ?

I think you mistook the OP comment on interoperability between apps written for different window managers to mean cross-platform portability.

The OP didn't claim windows was interoperable in a cross-platform sense. They were pointing out that on Windows, all apps have the same look and feel.

To achieve that result on Linux, across several common UI toolkits and window managers requires interoperability between apps written for the various toolkits.

Re:Unification in the *nix world

[Xabraxas]

Naysay as much as you want regarding Microsoft, but the reason why they have the market share is because of the unification present

Nope. That is not even close to the reason why they have the marketshare that they have. First of all Mac has a very good unified theme but they have next to nothing in marketshare. If that's not enough to blow a hole in your argument then my next statement will. Third party apps for Windows often use themes that are not anywhere close to the Windows theme. Take Winamp for example.

Windows has their marketshare because of apps, vendor lock in, propietary formats, and a whole bunch of other things that have nothing to do with a unified look and feel.

With that said, I do think this is a step in the right direction. Hopefully one day KDE and Gnome will have unified libraries and a unified interface. I only hope for this so the community doesn't lose one desktop completely in favor of another.

Re:Unification in the *nix world

[B'Trey]

You seem to be under the impression that choice is always a good thing. It isn't.

It doesn't really matter which side of the road you drive on. But it damned well would matter if it changed every time you crossed from one city to another.

The fact is that most users don't WANT to choose which windows manager they use. They want to be able to sit down at a machine and have it look and act in the same way they're used to it acting, whether it's their home machine, the machine on their desktop at work or the one at the corner Internet cafe. For power users and geeks, all this choice is a wonderful thing. For average users, it's a pain in the ass.

If we want Linux to move to the desktop (and that's a genuine "if" - it certainly isn't a given that that's necessarily the best future for Linux) but IF we want to move Linux to the desktop, it needs to be standardized. You can leave all the choices there, just as there's actually quite a bit of customization you can do to Windows if you get under the hood, but there needs to be a standard Linux "look and feel" that is a uniform default across distributions.

Re:Unification in the *nix world

[gujo-odori]

It's even simpler than that. MS has their market share because IBM gave it to them by choosing them as the OS vendor for the IBM PC. All of the lock-in via proprietary formats and engineered lack of interoperability and highly predatory and monopolistic practices came after that. If IBM had chosen CPM as their OS or had written one from scratch, MS today would still be just an application vendor among many. A large one, probably, but still just an application vendor.

The finbe print . . .

[randyest]

Seems like a start in the right direction, but don't expect something ready to roll (as I did until I checked the site):

Currently the code is very buggy and incomplete - a few widgets do not yet use the QT drawing code. However it is still perfectly usable. This theme is slightly slower than that of most native GTK themes, but the difference is hardly noticed on a fast machine.

Known bugs: * Menus do not have borders
* The background colour doesn't change when text is highlighted
* Colours are incorrect when using certain styles (eg. Keramik)
* Buttons, and other widgets, may be the wrong size
* Scrollbars sometimes misbehave


This is a 0.x release - do don't expect it to work perfectly :)

Just a style

[gilesjuk]

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.

Re:Just a style

[Shisha]

No one is really talking about unifying the API. That's the bit that developers are most mentally attached to. As we all know GTK vs. QT is rather different in the style of writing code, different mindset even, so it wouldn't work for either side to unify the API. With unified API we'll have loads of unhappy QT _and_ GTK developers!

OTOH this (unifying themes, i.e. one theme working for both QT & GTK) is the first step in the right direction, of making the two indistiunguishable to the user. Next would be _perfect_ cut & paste, including HTML pages, pictures, vector graphics etc. AFAIK freedesktop.org has come a long way working on cut & paste (drag & drop) and apparently all it needs now is more polish.

Final stage would be using kparts in GTK apps and bonobo components in KDE. There are cautious steps in that direction. And then there is OpenOffice (check out cukoo) of course and Mozilla and GNUStep... long way to go till everything is perfect. Then it will be the job of distributors like Mandrake & Xandros to give us the perfect desktop linux. Or our job, for those who like to tweak and fiddle with things. I'm looking forward to all this! (and I hope I'll be seeing less and less GNOME (KDE) sucks!!! style flamewars everywhere. Hey, I don't care whether I'm using Rhythmbox (where the file open dialog is still a joke) or Juk (which uses arts for the sound backend and arts sucks _and_ is a joke), I'll settle for either of the two as soon as it'll be perfect :-))!

That some guy is...

[Anonymous Coward]

David Sansome... at least name the person who put in the effort to make this happen.

Re:Bluecurve

[pe1rxq]

No, bluecurve are still seperate themes that look the same.. You need to make each theme both for gtk and for qt.
This theme engine uses the actual qt theme and thus does not require any duplicate work when creating a theme.

I wonder if the reverse could also be done (a qt engine that uses the gtk engine for its theme) or is gtk more flexible in this regard?

Jeroen

Re:Bluecurve

[Ralph Yarro]

Isn't this what Redhat's Bluecurve does?

No. Bluecurve is one widget style under QT and another under GTK, that have been designed to look the same as one another.

This system is quite different to that, it gets GTK to effectively draw widgets in the same style as the QT theme, regardless of which QT theme you're using.

Widget Mania

[Speare]

This is a good first step. But it's a tiny baby step.

When I can choose a widget theme once, using a central theme selector, such as GNOME's, and it shows up in all versions of Qt, GTK, Gtk2, Tk, Mozilla, and other applications, then I'll take notice.

The proliferation of toolkits does such a disservice to the desktop, even moreso than the proliferation of desktop environments. Why are there so many?

It seems like most OSS developers must go through the same milestones of skill development: a new C++ string class, a new IRC client, a new window manager, a new toolkit, and a new update package manager. Stop rewriting the wheel and improve what's out there in meaningful new ways.

Re:Widget Mania

[Trick]

Call me crazy, but I'm glad we've got a choice of desktop environments. 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. I'm sure there are plenty of other people who'd feel the same if GNOME were to disappear so that KDE could be the one true desktop environment.

If that means that some apps won't be completely integrated with my dekstop, I'm fine with that. I'd rather have the choices I have now than be forced to use a desktop environment I don't like.

Re:Widget Mania

[Sleepy]

>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. ;-)

Re:ummmmm...

[plj]

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

Partly a win, partly a problem

[eschasi]

Stating prejudices up-front: I'm a KDE kind of guy.

There's plusses and minuses to this. On one hand, unified theming is a win, no question. But doing so by adding yet another layer of interface could perpetuate the core differences rather than helping unify them. The world is rife with short-term hacks that are still running; it's one of the big contributors to bloatware.

In addition, it's a one-way change. When the author completes his work, Gnome apps can follow KDE themes, but not vice-versa. That's good for KDE, but not particularly good for Gnome.

It also leads to some subtle UI traps. When I run a Gnome app under KDE, it stands out. In one sense that's bad, as it can be visually jarring. In another sense that's good, as I'm visually alerted to expect some different UI rules. If one can't determine which ruleset to follow by a casual glance at the app, it's going to lead to user confusion.

It's also going to dilute the UI guidelines to both KDE and Gnome. Application writers tend to model their UIs on other apps, not from reading the UI guidelines. An app developer running Gnome apps under KDE look (but not feel!) will assume that either the KDE rules are loose or that he should be developing Gnomish features.

I'm not saying the author shouldn't do this; it's a noble goal and (from the responses on the author's posting) pretty decent code for an alpha/beta release. But we should hope for and work towards better long-term theme engines.

Why do we still fight GNOME x KDE

[Anonymous Coward]

I really don't understand most Slashdot readers. In every news about KDE or Gnome people start fighting on what is better, Qt or Gtk, C or C++, Gnome or KDE, with theory on how SuSE buyout will end KDE, why Qt isn't free, that Linus uses KDE, Trolltech is owned by SCO, etc. People who keeps posting things like this must be new to free software, or just don't understand it at all. The goal is *NOT* to kill Microsoft Windows and every OS and have just GNU/Linux with one desktop installed on all computers. The goal is freedom, is choice. I don't want to be like 10 years ago, when I thought DOS/Windows were the only operationg system available. Also, most free software projects are coded for fun. I can assure you, even if the whole world start using Gnome and KDE is just used by it's own developers, KDE will keep existing! There's no desktop war, so there is not going to be a winner. So, understand the community, and stop flames. We should be discussing how great it is that someone is trying to make GTK apps integrate better to the KDE environment, and hoping a GTK coder will start doing the same. I use KDE and I get really happy when I see a new feature on Gnome, cause probably KDE will have it too soon, Gnome users should feel the same way when KDE gets a new feature. And, while we're still talking about this, please, when a project is posted here, let's not comment on how there was already a project with the same goal and how duplicate effort is lame: if someone think it'll be fun to code another mp3 player, let him do it, *For coders, projects are mostly about fun!*

Re:KDE vs Gnome, battle of philosophy

[Findus Krispy]

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!

Hehe

[davidsansome]

That's quite interesting - I was just uploading version 0.2, when I suddenly noticed kde-look.org slowing down... now I know why :)

Anyway, 0.2 should fix some problems people have been having.

The funniest soon on your desktop...

[bad_sheep]

Yet Another QT Hacker will soon write a similar style for QT to use GTK to draw widgets, the result will be:

GTK: Please QT, draws me a button
QT : Please GTK, draws me a button
GTK: Please QT, draws me a button
QT : Please GTK, draws me a button
GTK: Please QT, draws me a button...

Have to wait before having anything drawn on the screen...