Submitted by “GNOME theme engine designer Andrea Cimitan has implemented support for transparent widgets in the Murrine GTK theme engine, bringing Vista-like translucent glass effects to the GNOME desktop. Cimitan used RGBA colormaps to implement the feature and says that, with only 10 or 20 extra lines of code, translucency can easily be added to other theme engines that support RGBA. Cimitan says that the addition of translucency effects proves that critics of GTK are wrong. “[I]n the last week I’ve seen a lot of people claiming about ‘lacks’ of Gtk+ capabilities,” wrote Cimitan in a blog entry. “Some of them still think that Gtk+ doesn’t have RGBA support… Or it will require nasty hacks. This is absolutely false.”
How can this be news?
Someone managed to make their theme engine mimic Vista glass?
Hardly impressive, especially since its been done a million times now with Compiz Fusion or other GTK/Metacity themes.
Its news since it can be done with the GTk engine.
I’ve already used GTK engines that provided at least transparent window titlebars. So I assumed this was already supported in general.
Perhaps that sort of transparency was simply from transparency in the image used for the title bar.
The window title bar is metacity and compiz replaces metacity to do the effects, again it’s different.
compiz has nothing to do with GTK, it’s a window manager, it’s GTK that does the transparency in this case and alot of people want it for pure eyecandy sake.
Many people said for years it couldn’t be done or would take a rewrite or something to that effect, they were wrong.
Edited 2007-12-13 19:23
Well it’s different from simply controlling the transparency of a whole window: now transparency can be on various elements of a GTK app. See for example the terminals in the second screenshot: the background is translucent, but the text isn’t. I certainly can’t do that on my compiz here.
It can be done, and is being done. Most modern terminals support real transparent background in a compositing environment. I’ve had it for years.
Well, gnome-terminal atleast does support real translucent background if you are running a compositing manager such as Compiz-fusion. But you’re right, this is not about window translucency, it’s about the translucency being applied to single widgets such as buttons, images, scrollbars or whatever the author of the theme wants.
you can if you use gnome-terminal, but that’s what he meant by a hack.
..are not on this front. I always believed GTK’s rendering is very flexible, just because it supports different rendering engines since ages.
There are other inflexibilities. For example, there is only one Widget font size. So if you want to have some smaller text, you cannot specify “small” but only hardcode the font (size), which is evil. Perhaps you could do other tricks, like finding out the default font size and do some 80% of it. Still evil, hackish and nobody does that.
See some screenshots of OSX and you get an idea about the huge benefits of different font sizes. Simply not possible with GTK in a clean way.
Wrong. Just set the pango markup.
Here’s an example in python:
import gtk
win = gtk.Window()
lbl = gtk.Label()
lbl.set_markup(“Hello to <small>small</small> and <big>big</big> textn” +
“You can even bold if you want” )
win.add(lbl)
win.show_all()
gtk.main()
Edited 2007-12-13 19:50
You sound like a GTK troll!
This is simply not true. There are seven different “size” values ranging from xx-small to xx-large, which are all defined relative to the user’s chosen desktop font size.
Entirely possible in GTK, and no more difficult than (for example) specifying the use of bold text. I don’t know why it isn’t used more by application developers, but it’s not because the toolkit doesn’t support it.
Edited 2007-12-13 23:43
I’m sorry for providing wrong facts in my comment. Thanks for your clarification!
I want that for QT too….
Qt has been doing this for years.
They have? Where can I get a KDE/QT theme that does this?
Plasma is going to use it in places. See Aaron Seigo’s blog for details. Apparently GTK has some kind of bug in their implementation.
His blog is http://aseigo.blogspot.com/
The relevant posts are:
http://aseigo.blogspot.com/2007/12/argb-visuals.html
http://aseigo.blogspot.com/2007/12/argb-updates.html
http://aseigo.blogspot.com/2007/12/busy-day-doing-apparently-nothin…
Not answering the question is it, someone said Qt has been doing this for years, where are the themes that can do this in KDE3?
Sorry I meant to edit my post but got distracted. I have not known of transparency in the widget set in QT3 or KDE3. I have only seen “fake” transparency in the panel before.
So my answer was more of what I know and by omission stating that I don’t think KDE has had it for 2 years.
You don’t need a theme. Its built-in with KDElibs/Kdebase (one of them at least). It can be enabled for *any* theme at all.
Try and get a livecd of any KDE distribution and try it out — Kubuntu/PCLinuxOS/Mandriva etc etc.
You don’t need a theme. Its built-in with KDElibs/Kdebase (one of them at least). It can be enabled for *any* theme at all.
Well, I have never came across something where I could change the transparency level of different components. But I’d like to see it.
I have kcontrol open right now and am ready to try it. So I wish people would stop saying “KDE could do this for years” and start showing us how to do it. Or stop making the claim.
If you have the Composite extension enabled in Xorg, you should have some options available under Control Centre -> Desktop -> Window Behaviour -> Translucency. I’ve had this since KDE 3.5.5 or thereabouts I believe, though I don’t know if it is something that has to be compiled-in specially or not.
If you have the Composite extension enabled in Xorg, you should have some options available under Control Centre -> Desktop -> Window Behaviour -> Translucency. I’ve had this since KDE 3.5.5 or thereabouts I believe, though I don’t know if it is something that has to be compiled-in specially or not.
Thanks!
I have kcontrol open right now and am ready to try it. So I wish people would stop saying “KDE could do this for years” and start showing us how to do it. Or stop making the claim.
Well, you can’t go into the Gnome control panel today and enable transparent effects in GTK themes. This announcement will not give you that. However, support for this stuff has been in Qt from the ground up for a couple of years (three years even) ever since Qt4 came into existence, and screenshots of KDE 4 and Qt using it are a penny a dozen. Transparent widgets and all – all done through the paint engine in one place incidentally. Screenshots are one thing, working is something else.
The trouble with this and GTK is that it isn’t really news, although it probably looks like it to most of the uninitiated:
1. This is not done through Cairo in one central point (from what he writes anyway). What we have are two drawing engines, and GDK is fundamentally incompatible with Cairo – unless themes themselves make use of it, and even then, you’ll have to do some copying and pasting. GTK themes can only paint into GDK rendering contexts and not Cairo ones, and if you want to, the hacks should make you shudder. We’re into copying pixmaps.
2. He talks about people thinking that GTK doesn’t have RGBA support, which I find bizarre – or it’s a slip of the keyboard ;-). This is rather inefficient, both memory and performance-wise. gdk-pixbuf handles both RGB and RGBA, but what people are interested in is ARGB – which most X servers use I believe. GTK and GDK just don’t do ARGB. This does require nasty hacks, and how this is ‘fast’, I have no idea.
3. In the depths of my mind on some forum somewhere, I can remember some hack being done like this for GTK themes not long ago. Whether it is done in the same way, I don’t know. The GTK theme engine, I think, generally draws a grey background pixmap and then renders the widget on top. One approach was to overdraw this pixmap with a background rgba (setting the default colourmap for widgets to rgba), and a future idea was to actually make the background pixmap transparent. You need compositing here, and I think composite checking went into GTK circa 2.8.
4. I can see a lot of application specific issues with this, particularly with GTK using applications like Firefox. Firefox does weird stuff to put it mildly.
5. This is all just crack painting next to a toolkit that actually does this for you from the ground up. Next to Quartx and WPF, this is an embarrassment trying to hold this up as some sort of equivalent. When KDE 4 gets rolling and starts using Qt 4 more fully, hopefully we will see this on Linux desktops. Hacked widget transparency in every theme is a joke next to these toolkits, and once you scratch away the screenshot, the cracks show.
EDIT: You need application support as well!
6. To do this kind of think in GTK requires a developer well versed in programming this. To do this on Vista, OS X and KDE 4 all you need to be is a Flash thingy designer really. KDE 4 needs a piece of designer software though, but Plasma scripting makes it reasonably possible and just about reachable for most.
7. Referring to point 5 and 6, it is impossible to do this within the current context of GTK 2.x. It requires GTK 3, and it can’t be API or ABI compatible.
8. Until we see some code for this in GTK and Gnome, it means pretty much nothing. It’s just a sad show-off, that doesn’t mean all that much, just to keep the ‘bling’ crowd interested.
Edited 2007-12-14 02:17
2. He talks about people thinking that GTK doesn’t have RGBA support, which I find bizarre – or it’s a slip of the keyboard ;-). This is rather inefficient, both memory and performance-wise. gdk-pixbuf handles both RGB and RGBA, but what people are interested in is ARGB – which most X servers use I believe. GTK and GDK just don’t do ARGB. This does require nasty hacks, and how this is ‘fast’, I have no idea.
Hmm, this caught my eye..Why would RGBA be any more inefficient than ARGB or use more memory? It can’t be just simply because it’s just the same thing..It uses exactly the same amount of memory and all. And yes, X server does support both RGBA and ARGB.. -.- If you really wanna delve into performance-efficiency of both pixel formats then lets just say that since almost all image file formats are RGBA it’s of course faster to just render everything else too in RGBA. And nasty hacks? Converting ARGB <-> RGBA is just a matter of shifting a few bits (the amount if bits depends but on a 32-bit display depth it’d be 8 bits per component) . That’s all that is required.
Hmm, this caught my eye..Why would RGBA be any more inefficient than ARGB or use more memory?
Well, within GDK we’re talking here, the problem is that they are stored in true colour. Even if you only have two colours going on, gdk-pixbuf seems to use 24 bits for each each pixel regardless. I haven’t looked at anything like this, or anything remotely graphical for ages, but that’s the way it was the last I looked.
If you really wanna delve into performance-efficiency of both pixel formats then lets just say that since almost all image file formats are RGBA it’s of course faster to just render everything else too in RGBA.
No. You do have to convert to ARGB because of X servers, mostly because graphics cards use it. The Mac is very much ARGB oriented. Cairo and X matches hardware in their use of ARGB (confusingly sometimes).
Converting ARGB – RGBA is just a matter of shifting a few bits (the amount if bits depends but on a 32-bit display depth it’d be 8 bits per component) . That’s all that is required.
You also have to do conversion, more importantly, because of Cairo. Blitting pixmaps means that you have to convert from pre-multiplied to non pre-multiplied alphas. Hmmmmm, not good. Remember that a desktop might typically load thousands of these images, so no, it isn’t a one time cost. That’s where the problem is.
I just wish they’d found a better way to integrate Cairo into GTK in a somewhat more transparent way.
No. You do have to convert to ARGB because of X servers, mostly because graphics cards use it.
Ever been doing OpenGL programming? I have never come across a 3D enabled card which would not let me upload textures in several formats. Including both ARGB and RGBA. I actually checked it just to make sure that I know what I am talking about. I tested with an ancient ATi Rage 2+ (or something like that, it had only 4mb RAM anyways) and it too allowed me to upload textures in both formats.
About Cairo…Well, I have never done any Cairo programming but I would find it realllllly stupid if it indeed didn’t support RGBA too. Actually, it should support any arbitrary format the same way OpenGL does: you just define how many bits every component uses and in which order they are presented.
The Qt4 series can do this. That has nothing to do with KDE3 themes. Plasma in KDE4 uses it right now. It just isn’t very interesting for a theme to use though since there is no logical place to put transparency for all apps. Some apps can code this in if it helps their specific app in a specific place, but this is not a useful general tool.
Whats KDE4/Qt4 even got to do with this, and yet still that person gets modded up for saying something thats not even proven or shown to do the same thing.
Ah. Guess we’ll have to wait for KDE4 then.
Ha ha that’s the beauty with QT/KDE .. you don’t need to slap on a theme to do it. So, in KDE, this can be done for *any* theme. And the amount of transparency can be done selectively for each window.
Of course with the “corporate” Linux biggies behind everything GNOME/GTK+/Mono/Microsoft, this is being touted as the next best thing.
And yes, QT/KDE has had it at least for 2-3 years, if not more.
I don’t really see how this has got anything to do with Qt, but still….
I’ll call you. Post a link to a screenshot from 2-3 years ago of KDE3 doing toolkit level transparency (and note that this is not the same thing has window manager level transparency, which is quite different). A transparent button in the middle of an opaque window, or vice-versa, would suffice.
Either do that, or leave the discussion to grown-ups who actually know what they’re talking about, okay?
I’ll call you. Post a link to a screenshot from 2-3 years ago of KDE3 doing toolkit level transparency
Well, if you believe hacking every theme to enable RGBA transparent pixmaps and adding support in applications is toolkit level transparency then I’ll have what you’re having. If this was done at the toolkit level then you’d enable a checkbox, not have to add any code anywhere else and relax and enjoy. I guarantee you, that is not the case here.
Qt 4 has done this at the toolkit level for around three years. This article is about a hack where we don’t know how it’s being done, the code is not likely to be released and it’s not likely to be in any Gnome theme or anywhere near GTK any time soon.
All he’s doing is showing it can be done, much like you can travel on land at the speed of sound but real cars dont use it do they?
Honestly, I dont know what you people get into such a flap about and what a surprise Qt gets thrown into a GTK discussion.
Edited 2007-12-14 02:57
All he’s doing is showing it can be done, much like you can travel on land at the speed of sound but real cars dont use it do they?
The trouble is, other people and systems are doing this now – and that’s Apple and Microsoft. Qt has had what it needs for a while, but no desktop out there is yet taking advantage of it. It’s a question of how we manage this eye candy on free desktops, how we can make it manageable and reliable and how we can catch up in certain areas.
Honestly, I dont know what you people get into such a flap about and what a surprise Qt gets thrown into a GTK discussion.
People are going to compare it to other stuff. C’est la vie. Eye candy will inevitably be compared to Quartz and WPF, so it’s not just a Qt/GTK comparison troll-fest, and Qt stuff will be compared to what everyone else is doing.
People will ask “Can I check this out tomorrow and have it work, will it have tons of inexplicable bugs, is this truly as good as what other people are doing, or is it just bolted on?”
Edited 2007-12-14 15:31
Here’s one from a year ago:
http://zrusin.blogspot.com/2006/10/argb-windows.html
I wish to point out that this has been possible with Qt4 since 2005. KDE3 does however not support this, but then again the talk was about Qt.
GTK uses the CPU.
Vista uses the GPU.
Why do you think GTK+ uses CPU for alpha? It’s the compositing manager which does handle drawing the stuff on the screen and they do indeed use GPU for that. GTK+ just properly sets the alpha mask and voila, GPU draws it as it should. Learn a little before you start making such stupid claims.
That definitely depends on how you compiled GTK+ and the theme in question and which version of GTK+ you are using not to mention the version of Cairo, Pango and whatnot.
GTK+ on my machine supports 3D hardware acceleration through Cairo.
That however does not mean that GTK+ on your machine is compiled with support for Cairo or that Cairo is compiled with support for hardware acceleration (OpenGL).
GTK+ on my machine supports 3D hardware acceleration through Cairo.
Mmmno. As much as I personally like GTK+ and Cairo I just have to correct you here: GTK+ devs have not seen it necessary to make Cairo use Glitz for rendering. As such, Cairo (when used by GTK+) does use software rendering. Even if Cairo is indeed compiled with Glitz support it still isn’t used unless specified by the application/library utilizing Cairo.
Now what I would find interesting would be a benchmark between normal GTK+ vs. patched GTK+ with Glitz enabled.
True, it requires a composite manager to work. They need cairo compiled with glitz to work, as it is. But without a composite manager it is just waste of good memory and harddisk space.
EDIT: And would a certain person please stop with his consistent down-modding of all my posts? (Not directed at Werecatf) –
Edited 2007-12-15 14:13 UTC
“And yes, it is FAST!”
What a blatant liar. It’s obvious that since GTK by itself is slow, GTK with alpha blending won’t suddenly get faster.
What he means, is that it runs almost ok on his brand new computer.
What a blatant liar. It’s obvious that since GTK by itself is slow, GTK with alpha blending won’t suddenly get faster.
Now I got curious..Where do you get the idea that GTK+ is slow? Cos it can’t be as slow as you claim..Why? Well, it’s used on a lot of handheld devices which just simply can’t sport a high-end CPU. And it’s used on several embedded devices too. So, care to elaborate?
And secondly, when GTK+ uses true alpha-blending it will be a lot faster than doing semi-transparency in software. In theory it could just speed up apps which have been doing alpha-blending for their widgets in software. And in practice it most likely would run just as fast as before.
Opening an invisible window takes twice as much time with GTK as it does under Windows XP (just test). And what makes GTK slow isn’t the simple things like that, but drawing and other stuff.
A real world example can be seen here: http://www.purebasic.fr/english/viewtopic.php?t=29336
GTK is over 120 times slower than when he codes it himself.
Your link mentions a *file I/O* performance issue, not a graphics performance issues. Do you even know what you’re talking about?
1. If it’s already slow in one department, that’s not a good reason to make it slow in another department.
2. Do you really think that a naïvely coded directory examination replacement is 120 times faster than GTKs? No, the thing that makes the slowdown is surely the GTK treeview. Those things are slow, and it’s got to do with how drawing is handled.
“1. If it’s already slow in one department, that’s not a good reason to make it slow in another department.”
That’s still no excuse for associating something with something totally unrelated.
“2. Do you really think that a naïvely coded directory examination replacement is 120 times faster than GTKs? No, the thing that makes the slowdown is surely the GTK treeview. Those things are slow, and it’s got to do with how drawing is handled.”
Uhm no. How do you know that it’s the tree view? Have you profiled the code? Do you have any scientific proof to back up that claim? In the past I have written an application which puts 20000 rows in the GtkTreeView, and the widget is still quite snappy. It took only a second or two, and this was on an old Athlon 1.4 Ghz, before the time that Frederico started optimizing GTK 2.
You’re making grand claims by just assuming things. If you can show the profiling results which indeed point to GtkTreeView as the culprit, by all means, go ahead. But until you have that proof, your statement means nothing. Imagine what happens when a developer decides to take your statement seriously, only to find out, after 40 hours of testing, that the culprit is in the I/O code and not in GtkTreeView. You would have wasted 40 hours of his life!
There are plenty of reasons why the file dialog can be slower than a naively coded directory examination.
– For one, there aren’t many ways to examine a directory: you open it and read all the entries and that’s it, so the “naive” method you mention is really the fastest way (unless you throw in caching of course).
– The GTK file dialog does a whole lot more than just listing all filenames. It has to lookup the MIME type of each file and show up the corresponding icon. It has to check whether an entry is a file or a folder. It has to show the modification time. Etcetera. Especially MIME type lookup and icon lookup can be slow.
And what makes GTK slow isn’t the simple things like that, but drawing and other stuff.
A real world example can be seen here: http://www.purebasic.fr/english/viewtopic.php?t=29336
I’m sorry, I couldn’t help but laugh out loud! xD That’s about GTK+ file operation speeds!
It has nothing to do with graphics performance :3 Sure, GTK+ may not handle tens of thousands of files very efficiently but I imagine they’re atleast trying to fix that sometime. But that is really a bit off-topic since you were complaining about rendering speeds and this article too is about graphics.
Now I got curious..Where do you get the idea that GTK+ is slow? Cos it can’t be as slow as you claim..Why?
I’m afraid anyone who has used GTK and Gnome applications long enough knows this. Redrawing is an obvious shortcoming. You also haven’t been reading many of Frederico Mena-Quintero’s blog entries on tracking down why this might be. Some of the stuff he’s been able to find, and managed to do something about, is pretty amazing work. It’s very complex stuff though, since it isn’t just GTK. A lot has to do with Pango, and various other components and bits of code.
Edited 2007-12-13 23:41
Uhm my old Athlon 1.4 Ghz ran GTK just fine without any slowdowns. Where did you get the idea that GTK will be slow on today’s dual core CPUs?
uhm, please don’t do this. alpha blending might look nice in screenshots but it’s really irrelevant when you start actually using gtk. the text i see in the screenshots are a lot less readable than against a plain background.
it’s nice it is possible, but i’m scared the gtk people will use too much alpha and everything becomes a blurred mess (please note that osx uses actually almost no transparency)
I don’t think that’ll happen so no worries. Atleast if the author of the application is smart he/she will make sure any widgets with text are _not_ transparent and only those widgets which really need transparency will gain that.
but not really usable. Transparent widgets makes text on the widgets harder to read if the background isn’t very clean, and it often isn’t. Just imagine a popup menu that pops up over other widgets.
One way to improve readability would be to blur the background as well. That way you would get a more calm background for the text. I think Vista does this, but I still prefer non transparant widgets. Transparant widgets look good on a screen shot though.
Does GTK+ provide transparency for widgets in X11, OS X and XP/Vista?
Edited 2007-12-13 20:40
Well Pidgin(GTK ported app) in Windows has a option for transparency, so in theory yes.
I’m pretty sure that’s different. That’s using whole window transparency which was introduced in W2k.
Does GTK+ provide transparency for widgets in X11, OS X and XP/Vista?
Recent versions of GTK added an “opacity” property to widgets, to allow them to specify how see-through they are (1.0=solid, 0.0=invisible). This is the same on all platforms.
Whether the opacity request is respected or not is up to the renderer, or “theme engine” in GTK-speak. What we’ve got here is the first X11 theme engine that obeys the opacity requests.
The theme engine for GTK on Windows uses GDI+. I don’t know whether GDI allows individual widgets to set their transparency, but if it does then in principal there’s no reason why the theme engine couldn’t be updated. (More interesting would be an entirely new theme engine based on Windows.Forms… anyone from Novell want to set the cat amongst the pigeons on this one?)
GTK on OS X uses Quartz, which is certainly capable of transparency, but there are some rather higher-priority things they need to get working first I think.
Recent versions of GTK added an “opacity” property to widgets, to allow them to specify how see-through they are (1.0=solid, 0.0=invisible). This is the same on all platforms.
You’re going to have to provide some API documentation here. The opacity property, from what I remember, this is basically just something to palm off on to the composite window manager. What’s being discussed here are effects like widget transparency. That’s altogether different.
(More interesting would be an entirely new theme engine based on Windows.Forms… anyone from Novell want to set the cat amongst the pigeons on this one?)
I doubt it. Windows.Forms is stillborn.
As far as I know, and without trying the theme, I think this does not provide real transparency in the same way compiz does. RGBA transparency can be used, for example, in mouse cursor themes to create shadows and other cool effects, but that’s only because, I think, the mouse pointer is drawn in a special way. If you try to use the same trick in normal widgets, like for example using a window border by displaying a translucent PNG, you end up with fake transparency. What you see through it is the desktop background. If you put another window behind the translucent one, you’ll still see the desktop background. I mention this because that’s what happens in some KDE themes too, and I think RGBA translucency is the technic they use.
Note how in the two screenshots from the first link the windows are carefuly not on top of each other.
Sorry, you’re wrong. As it is stated very clearly in the blog entry you need a compositing manager which draws transparencies. If you aren’t running one you don’t get transparency even if you try to specify your widgets completely transparent. Besides, for example drawing a PNG with alpha mask in a image widget would still not result in the background showing through unless the app copied an image of the background and blended it with the PNG or unless you had a compositing manager running and widget/window masks and params correctly set.
Just believe me, it is real transparency.
Thanks, I stand partly corrected. I missed the sentence “The translucency effects obviously require a compositing window manager, …” when I read the text, but I was not entirely wrong, in the sense that if you don’t use compiz or another compositing window manager you wouldn’t have real transparency. And then it continues “but the theme engine is designed so that the widgets will simply be rendered without transparency when no compositing window manager is present.” In other words, that when you would get fake transparency, transparency isn’t used. But my post was essentially correct in the sense that RGBA by itself does not provide real transparency.
Thanks again for your corrections.
Well you need something to composite the alpha channel on. X doesn’t do this by default and this stuff has to be done in a buffer anyway, unless you want to see windows being composited in front of you as you work. I’m not sure if you know aht RGBA is or not, its not a thin exactly its just a way to describe the alpha channel (hence the A for alpha). RGBA support in gtk+ or any other toolkit, os, etc. always means the final image has to be composited in-order to get true alpha-blending, this can be done 2d through the cpu (though its slow) or through hardware. Compiz uses opengl to do the compositing and thus leverages the power of already built-in support for alpha-blending. The technique whether its OSX or Vista still requires that the windows be buffered and copied off to memory somewhere so that they can be displayed later so regardless of how you look at it a compositing manager is still necessary to do it at reasonable speeds and interactively.
As for how the widgets will be rendered without compositing enabled, my guess is that if there is no compositing manager the engine will only use the color and ignore the alpha entirely, I don’t think they’ll use that wallpaper hack at all. In other words they will use only the RGB components and ignore the A.
You are wrong. RGBA is basically is two components color and alpha. Compiz by default already supports compositing, gtk+ already has support for RGBA but it hasn’t been used extensively until now, but it has been used before for example gnome-terminal uses rgba so that when you use a composting manager it actually use the alpha component as a way to define transparency, this is true transparency you will see eveything under it not just the wallpaper which is a hack that was used before/
In the past transparency was done that wa but this transparency is done by the x-server specifically x.org.
The problem of GTK is that it’s over-engineered. Conceptually, everything is ok. Every behaviors of the toolkit is well thought. However, the end result is much less exciting. A simple resizing operation causes a zillion fonction calls. Most GTK theme engines are unacceptably slow (the fact that they are almost all based on Cairo now is one of the causes for this). In a corporate environnement, I think people can live with that. For the rest of the world, I think it’s not something you want. I have 2 computers here, one running XP and one running Gusty, and I see a huge difference between both setup even when doing the same exact task. For example, SWT/Windows is so much faster than SWT/GTK. Using Eclipse on Windows is so much more enjoyable than using it on Linux. Honestly, having Gnome, Evolution, Firefox, Eclipse and OOo running at the same time isn’t something pretty even on a high-end computer. I know we can’t blame GTK for everything but it doesn’t help.
I thought the same thing about Vista and .Net, but hey
I think cairo would be sped up considerably if they used the opengl backend to accelerate it liek they planned. If you use gtk on X I think it uses xlib for the rednering backend, but there is no reason why most of this couldn’t be offloaded to the compositing manager at some point if it isn;t already being done.
Yeah, well for quite a while it’s been the case that SWT is best on Windows and slower on Linux and Mac. That is something probably best left to the SWT people to fix. How about comparing something *other* than Eclipse?
Actually using Cairo speeds up the themes…
Actually using Cairo speeds up the themes…
Not in my experience, and I doubt benchmarks (gtkperf?) show otherwise. I remember how much slower GTK+ suddenly became after the Cairo switch in 2.6. It was slow in the 2.0-2.4 versions, too, but since 2.6, it’s been really slow.
Actually using Cairo speeds up the themes…
I cannot see how, since all the GDK routines are generally faster and more mature than their Cairo equivalents. Cairo hasn’t caught up here. GDK is just more mature and faster at bilinear filtering, and stuff like transformations and alike.
I’ve also seen Cairo’s software fallbacks turn out to be terrible really. They’re certainly not as good as GDK performance-wise, which is probably why people are talking about doing what they can through GDK now.
There’s not really a whole lot of incentive for themes to move wholesale to Cairo, which takes new code, time and effort and may well turn out to not be worth it performance-wise.
100% agreed. GTK+ is painfully slow. Yes, it is a modern toolkit with many modern features, but the performance suffers. It is quite OK for simple apps, but as long as the window layout gets more complicated, with tabs, lists, progress bars, spin buttons etc., it gets quite CPU-hungry. Especially the Cairo integration in 2.6 made it really slow. General (re)drawing performance is poor (and has always been poor in GTK+ 2.x) this can be seen in many graphics apps), switching between tabs in dialogs is visibly slow (I can see the individual widgets being drawn to the tab), resizing has always been slow, scrolling in large lists is slow, context menus are slow (more CPU intensive than in other toolkits) etc.
Yes, using these big apps on Linux (as opposed to MS Windows) is painful exactly because the GUI runs like molasses.
I think it’s GOOD that an engine supports transparency. BUT on the other hand this doesn’t mean everything has to use this feature until our eyes are bleeding.
This is an unholy trend among UIs. Apple does something, MS is doing it again – to my taste with even more bad taste than apple. Then it finally hits Linux.
Those transparency is bringing NOTHING if it is used for the sake of the effect. I know VERY FEW problems which need transparency. Transparent Menus aren’t one of them. This is IMHO simply bullshit, “You can see what’s going on underneath” … Bullcrap. Some
Design an UI, makes it clear, easy on the eyes, don’t overuse flashy effects. Don’t overuse white (because it’s the brightest “color” available on the screen). Make it in the way that the document you’re working on is sticking out. UI is just a tool.
Transparency can make sense for drag’n’drop situations e.g.
I can only hope the UI-Designers are coming back to EFFECTIVE UI-Design again instad of showing off their technology. It’s just annoying and unprofessional.
Thanks.
Then in that case, you’ll be fine sticking with KDE 3 and it’s badly-rendered shutdown dragon. Some of us, however, appreciate these gestures towards the realm of decent design.
So I guess it doesn’t count that KDE integrated compositing support for kwin a long while back? Or is it because KDE could only support compositing effects like shadows and transparency, while transparent widgets somehow magically become more effective for UI design?
Who’s kidding who, it’s bling, nothing more. Just because it’s GTK doesn’t make it more or less UI effective than KDE/Qt. It’s a tool to be used or abused as the devs see fit.
Besides, if you enjoy it, just be grateful for the KDE4 screenshots floating around the interweb, because that’s likely what inspired those ten lines of code to be added to enable it in the first place…
Actually, I rather feel that the Murrine author has never taken any design tips from the KDE guys (thankfully), the word Murrine actually means a form of glass-work, so the idea of creating translucent windows will have beem much more influenced by the Aero glass effect than KDE.
Who’s kidding who, it’s bling, nothing more.
Any form of design above basic functional implementation could be called bling, yet people APPRECIATE this stuff, and (surprisingly, for people like you, I’m sure) hardware and software with good graphical design makes people more productive, and helps them produce better quality products.
Actually I find transparency to be quite a useful feature (if for example you were waiting for something to complete in a shell). It all depends on how you use your desktop. Windows users don’t get the concept of virtual desktops but that doesn’t mean that they aren’t useful. Just because you don’t think transparency is useful doesn’t mean that the rest of feel the same way. Speak for yourself and leave the rest of us to decide for ourselves. BTW – Apple does NOT invent everything – they just like to claim that they do.
Why is it that any type of desktop compositing is always referenced as “Vista-like”. Translucency has been around for a long, long time….way before Vista, and way before OS X. In fact, I distinctly remember a patch for Windows 98 that would allow for translucent window borders and such.
“Microsoft” and “visual innovations” go together like oil and water.
Becuase we are living in the Real World ™. Technologies get named after the people who make them successfull.
If I say:
Hey, I’m listening to my iPod while travelling up an escalator, on my way to buy a hoover.
a lot more people will understand me than if I say:
Hey, I’m listening to my PMP, while travelling up a motorized staircase, on my way to buy a vacuum cleaner.
If you start talking about patched-windows-95-style transparency, noone will understand you.
If you talk about windows-2000-style transparency, then the geeks will think of whole-window transparency, and fading-in/out windows.
Only Aero-like transparency will create the instant recognition in people’s minds that will allow them to correctly identify what you are talking about.
It’s not a vacuum cleaner. It’s a dustsucker!
So the word “Vista” has entered our lexicon as being synonymous with “all things computerized and graphical”? Was there a memo that I missed? Is this Steve Ballmer that I’m responding to?
In fact, I distinctly remember the last time I saw rendered water on a PS3, the sentence “Wow, look at that great Vista!” or “Check out that Aero!” was never uttered by anyone in the room.
You’re right about things like “Xerox”-ing, and people still referring to PCs as “IBM”s; but I dare you to find ONE single thing that Vista has done, that makes the public use the term ubiquitously, as in calling every “PMP” an iPod.
As opposed to “open source” and “visual innovations”?
The Screenshots are pretty but transparency should not be so overdone. The color mapping used here would not be able to blur the background picture… Now, showing text below your text unblurred is going to be very confusing.
I don’t see what’s the obsession with transparency anyway.
…if you meant me, i don’t think transparency is NOT useful. It does has it uses. Your example is one of them, dragndrop big items is another. Transparent Menus is NOT one of them… Well, it depends and then the completely subjective factor of “taste” comes into play.
So, transparency is just another tool UI-designers can use. I just hope they give the user the last control over transparency.
I never claimed Apple invented it. (if you meant me) … Apple also copies stuff, which is OK to me.
Everybody is “borrowing” stuff from other sources, in the end all that matters is the end-user experience, the freedom of choice (preferences, no force-feeding!) and the resulting work.
Have a nice day.