Linked by Thom Holwerda on Thu 13th Dec 2007 18:27 UTC, submitted by SEJeff
GTK+ "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."
Order by: Score:
What?
by Xaero_Vincent on Thu 13th Dec 2007 19:01 UTC
Xaero_Vincent
Member since:
2006-08-18

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.

Reply Score: 0

RE: What?
by lawina on Thu 13th Dec 2007 19:04 UTC in reply to "What?"
lawina Member since:
2006-01-20

Its news since it can be done with the GTk engine.

Reply Score: 4

RE[2]: What?
by Xaero_Vincent on Thu 13th Dec 2007 19:24 UTC in reply to "RE: What?"
Xaero_Vincent Member since:
2006-08-18

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.

Reply Score: 2

RE[3]: What?
by SlackerJack on Thu 13th Dec 2007 19:42 UTC in reply to "RE[2]: What?"
SlackerJack Member since:
2005-11-12

The window title bar is metacity and compiz replaces metacity to do the effects, again it's different.

Reply Score: 4

RE: What?
by SlackerJack on Thu 13th Dec 2007 19:12 UTC in reply to "What?"
SlackerJack Member since:
2005-11-12

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

Reply Score: 8

RE: What?
by jebb on Thu 13th Dec 2007 19:21 UTC in reply to "What?"
jebb Member since:
2006-07-06

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.

Reply Score: 6

RE[2]: What?
by joolz on Thu 13th Dec 2007 19:28 UTC in reply to "RE: What?"
joolz Member since:
2007-01-16

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.

Reply Score: 1

RE[2]: What?
by WereCatf on Thu 13th Dec 2007 19:38 UTC in reply to "RE: What?"
WereCatf Member since:
2006-02-15

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.

Reply Score: 3

RE[2]: What?
by jadeshade on Sat 15th Dec 2007 22:58 UTC in reply to "RE: What?"
jadeshade Member since:
2007-07-10

you can if you use gnome-terminal, but that's what he meant by a hack.

Reply Score: 1

The real lacks of GTK..
by Ford Prefect on Thu 13th Dec 2007 19:22 UTC
Ford Prefect
Member since:
2006-01-16

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

Reply Score: 2

RE: The real lacks of GTK..
by SomeGuy on Thu 13th Dec 2007 19:49 UTC in reply to "The real lacks of GTK.."
SomeGuy Member since:
2006-03-20

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

Reply Score: 7

RE[2]: The real lacks of GTK..
by jelway on Sat 15th Dec 2007 18:17 UTC in reply to "RE: The real lacks of GTK.."
jelway Member since:
2006-05-14

You sound like a GTK troll!

Reply Score: 1

RE: The real lacks of GTK..
by tristan on Thu 13th Dec 2007 23:42 UTC in reply to "The real lacks of GTK.."
tristan Member since:
2006-02-01

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.


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.

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.


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

Reply Score: 2

RE[2]: The real lacks of GTK..
by Ford Prefect on Fri 14th Dec 2007 10:03 UTC in reply to "RE: The real lacks of GTK.."
Ford Prefect Member since:
2006-01-16

I'm sorry for providing wrong facts in my comment. Thanks for your clarification!

Reply Score: 5

And QT?
by werfu on Thu 13th Dec 2007 19:32 UTC
werfu
Member since:
2005-09-15

I want that for QT too.... ;)

Reply Score: 1

RE: And QT?
by Carewolf on Thu 13th Dec 2007 19:34 UTC in reply to "And QT?"
Carewolf Member since:
2005-09-08

Qt has been doing this for years.

Reply Score: 8

RE[2]: And QT?
by NxStY on Thu 13th Dec 2007 20:57 UTC in reply to "RE: And QT?"
NxStY Member since:
2005-11-12

They have? Where can I get a KDE/QT theme that does this?

Reply Score: 1

RE[3]: And QT?
by andrewg on Thu 13th Dec 2007 21:03 UTC in reply to "RE[2]: And QT?"
andrewg Member since:
2005-07-06

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

Reply Score: 4

RE[4]: And QT?
by SlackerJack on Thu 13th Dec 2007 21:22 UTC in reply to "RE[3]: And QT?"
SlackerJack Member since:
2005-11-12

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?

Reply Score: 6

RE[5]: And QT?
by andrewg on Thu 13th Dec 2007 21:38 UTC in reply to "RE[4]: And QT?"
andrewg Member since:
2005-07-06

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.

Reply Score: 4

RE[5]: And QT?
by kanwar.plaha on Thu 13th Dec 2007 21:56 UTC in reply to "RE[4]: And QT?"
kanwar.plaha Member since:
2006-02-20

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.

Reply Score: 1

RE[6]: And QT?
by jaylaa on Thu 13th Dec 2007 23:38 UTC in reply to "RE[5]: And QT?"
jaylaa Member since:
2006-01-17

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.

Reply Score: 3

RE[7]: And QT?
by Havin_it on Fri 14th Dec 2007 01:22 UTC in reply to "RE[6]: And QT?"
Havin_it Member since:
2006-03-10

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.

Reply Score: 2

v RE[7]: And QT?
by segedunum on Fri 14th Dec 2007 02:02 UTC in reply to "RE[6]: And QT?"
RE[5]: And QT?
by leos on Thu 13th Dec 2007 22:24 UTC in reply to "RE[4]: And QT?"
leos Member since:
2005-09-21

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?


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.

Reply Score: 2

RE[6]: And QT?
by SlackerJack on Fri 14th Dec 2007 00:47 UTC in reply to "RE[5]: And QT?"
SlackerJack Member since:
2005-11-12

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.

Reply Score: 2

RE[4]: And QT?
by NxStY on Thu 13th Dec 2007 21:23 UTC in reply to "RE[3]: And QT?"
NxStY Member since:
2005-11-12

Ah. Guess we'll have to wait for KDE4 then.

Reply Score: 1

v RE[3]: And QT?
by kanwar.plaha on Thu 13th Dec 2007 21:54 UTC in reply to "RE[2]: And QT?"
RE[4]: And QT?
by tristan on Thu 13th Dec 2007 23:31 UTC in reply to "RE[3]: And QT?"
tristan Member since:
2006-02-01

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?

Reply Score: 4

v RE[5]: And QT?
by segedunum on Fri 14th Dec 2007 02:25 UTC in reply to "RE[4]: And QT?"
RE[6]: And QT?
by SlackerJack on Fri 14th Dec 2007 02:54 UTC in reply to "RE[5]: And QT?"
SlackerJack Member since:
2005-11-12

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

Reply Score: 2

RE[7]: And QT?
by segedunum on Fri 14th Dec 2007 15:27 UTC in reply to "RE[6]: And QT?"
segedunum Member since:
2005-07-06

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

Reply Score: 0

RE[5]: And QT?
by slougi on Fri 14th Dec 2007 09:27 UTC in reply to "RE[4]: And QT?"
slougi Member since:
2006-08-16

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.

Reply Score: 1

v GTK uses the CPU
by casuto on Thu 13th Dec 2007 19:34 UTC
RE: GTK uses the CPU
by WereCatf on Thu 13th Dec 2007 19:44 UTC in reply to "GTK uses the CPU"
WereCatf Member since:
2006-02-15

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.

Reply Score: 7

RE: GTK uses the CPU
by dylansmrjones on Fri 14th Dec 2007 19:34 UTC in reply to "GTK uses the CPU"
dylansmrjones Member since:
2005-10-02

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

Reply Score: 1

RE[2]: GTK uses the CPU
by WereCatf on Fri 14th Dec 2007 22:08 UTC in reply to "RE: GTK uses the CPU"
WereCatf Member since:
2006-02-15

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.

Reply Score: 2

RE[3]: GTK uses the CPU
by dylansmrjones on Sat 15th Dec 2007 14:10 UTC in reply to "RE[2]: GTK uses the CPU"
dylansmrjones Member since:
2005-10-02

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

Reply Score: 2

v Fast???
by Invincible Cow on Thu 13th Dec 2007 19:46 UTC
RE: Fast???
by WereCatf on Thu 13th Dec 2007 19:51 UTC in reply to "Fast???"
WereCatf Member since:
2006-02-15

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.

Reply Score: 9

v RE[2]: Fast???
by Invincible Cow on Thu 13th Dec 2007 20:03 UTC in reply to "RE: Fast???"
RE[3]: Fast???
by FooBarWidget on Thu 13th Dec 2007 20:35 UTC in reply to "RE[2]: Fast???"
FooBarWidget Member since:
2005-11-11

Your link mentions a *file I/O* performance issue, not a graphics performance issues. Do you even know what you're talking about?

Reply Score: 5

RE[4]: Fast???
by Invincible Cow on Sun 16th Dec 2007 10:44 UTC in reply to "RE[3]: Fast???"
Invincible Cow Member since:
2006-06-24

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.

Reply Score: 1

RE[5]: Fast???
by FooBarWidget on Sun 16th Dec 2007 12:47 UTC in reply to "RE[4]: Fast???"
FooBarWidget Member since:
2005-11-11

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

Reply Score: 3

RE[3]: Fast???
by WereCatf on Thu 13th Dec 2007 20:48 UTC in reply to "RE[2]: Fast???"
WereCatf Member since:
2006-02-15

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.

Reply Score: 4

RE[2]: Fast???
by segedunum on Thu 13th Dec 2007 23:40 UTC in reply to "RE: Fast???"
segedunum Member since:
2005-07-06

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

Reply Score: 4

RE[2]: Fast???
by FooBarWidget on Thu 13th Dec 2007 19:55 UTC in reply to "Fast???"
FooBarWidget Member since:
2005-11-11

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?

Reply Score: 4

readability
by renhoek on Thu 13th Dec 2007 19:50 UTC
renhoek
Member since:
2007-04-29

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)

Reply Score: 1

RE: readability
by WereCatf on Thu 13th Dec 2007 19:56 UTC in reply to "readability"
WereCatf Member since:
2006-02-15

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.

Reply Score: 2

Cool...
by unoengborg on Thu 13th Dec 2007 20:06 UTC
unoengborg
Member since:
2005-07-06

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.

Reply Score: 3

Is this cross platform?
by andrewg on Thu 13th Dec 2007 20:36 UTC
andrewg
Member since:
2005-07-06

Does GTK+ provide transparency for widgets in X11, OS X and XP/Vista?

Edited 2007-12-13 20:40

Reply Score: 2

RE: Is this cross platform?
by SlackerJack on Thu 13th Dec 2007 20:50 UTC in reply to "Is this cross platform?"
SlackerJack Member since:
2005-11-12

Well Pidgin(GTK ported app) in Windows has a option for transparency, so in theory yes.

Reply Score: 3

RE[2]: Is this cross platform?
by leos on Thu 13th Dec 2007 22:16 UTC in reply to "RE: Is this cross platform?"
leos Member since:
2005-09-21

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.

Reply Score: 2

RE: Is this cross platform?
by tristan on Fri 14th Dec 2007 00:05 UTC in reply to "Is this cross platform?"
tristan Member since:
2006-02-01

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.

Reply Score: 3

v RE[2]: Is this cross platform?
by segedunum on Fri 14th Dec 2007 02:31 UTC in reply to "RE: Is this cross platform?"
v It's not real transparency
by rg03 on Thu 13th Dec 2007 20:58 UTC
RE: It's not real transparency
by WereCatf on Thu 13th Dec 2007 21:03 UTC in reply to "It's not real transparency"
WereCatf Member since:
2006-02-15

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.

Reply Score: 3

RE[2]: It's not real transparency
by rg03 on Thu 13th Dec 2007 21:23 UTC in reply to "RE: It's not real transparency"
rg03 Member since:
2007-12-13

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.

Reply Score: 2

apoclypse Member since:
2007-02-17

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.

Reply Score: 3

RE: It's not real transparency
by apoclypse on Thu 13th Dec 2007 21:04 UTC in reply to "It's not real transparency"
apoclypse Member since:
2007-02-17

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/

Reply Score: 2

RE: It's not real transparency
by andrewg on Thu 13th Dec 2007 21:09 UTC in reply to "It's not real transparency"
andrewg Member since:
2005-07-06

In the past transparency was done that wa but this transparency is done by the x-server specifically x.org.

Reply Score: 3

GTK is slow
by rx182 on Thu 13th Dec 2007 22:02 UTC
rx182
Member since:
2005-07-08

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.

Reply Score: 5

RE: GTK is slow
by stestagg on Thu 13th Dec 2007 22:56 UTC in reply to "GTK is slow"
stestagg Member since:
2006-06-03

I thought the same thing about Vista and .Net, but hey ;)

Reply Score: 4

RE: GTK is slow
by apoclypse on Fri 14th Dec 2007 05:12 UTC in reply to "GTK is slow"
apoclypse Member since:
2007-02-17

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.

Reply Score: 2

RE: GTK is slow
by Moochman on Fri 14th Dec 2007 07:30 UTC in reply to "GTK is slow"
Moochman Member since:
2005-07-06

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?

Reply Score: 2

RE: GTK is slow
by dylansmrjones on Fri 14th Dec 2007 19:37 UTC in reply to "GTK is slow"
dylansmrjones Member since:
2005-10-02

Actually using Cairo speeds up the themes...

Reply Score: 1

RE[2]: GTK is slow
by J. M. on Fri 14th Dec 2007 20:47 UTC in reply to "RE: GTK is slow"
J. M. Member since:
2005-07-24

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.

Reply Score: 1

RE[2]: GTK is slow
by segedunum on Fri 14th Dec 2007 21:00 UTC in reply to "RE: GTK is slow"
segedunum Member since:
2005-07-06

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.

Reply Score: 2

RE: GTK is slow
by J. M. on Fri 14th Dec 2007 20:07 UTC in reply to "GTK is slow"
J. M. Member since:
2005-07-24

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.

Reply Score: 0

Errr...
by asr4096 on Thu 13th Dec 2007 22:11 UTC
asr4096
Member since:
2007-09-18

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.

Reply Score: 6

RE: Errr...
by stestagg on Thu 13th Dec 2007 22:57 UTC in reply to "Errr..."
stestagg Member since:
2006-06-03

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.

Reply Score: 3

RE[2]: Errr...
by elsewhere on Fri 14th Dec 2007 05:45 UTC in reply to "RE: Errr..."
elsewhere Member since:
2005-07-13

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

Reply Score: 2

RE[3]: Errr...
by stestagg on Fri 14th Dec 2007 10:50 UTC in reply to "RE[2]: Errr..."
stestagg Member since:
2006-06-03

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.

Reply Score: 2

RE: Errr...
by mzilikazi on Fri 14th Dec 2007 21:20 UTC in reply to "Errr..."
mzilikazi Member since:
2006-02-11

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.

Reply Score: 1

Here's a question...
by Phloptical on Thu 13th Dec 2007 23:14 UTC
Phloptical
Member since:
2006-10-10

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.

Reply Score: 2

RE: Here's a question...
by stestagg on Fri 14th Dec 2007 10:57 UTC in reply to "Here's a question..."
stestagg Member since:
2006-06-03

Becuase we are living in the Real World (tm). 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.

Reply Score: 3

RE[2]: Here's a question...
by dylansmrjones on Fri 14th Dec 2007 19:38 UTC in reply to "RE: Here's a question..."
dylansmrjones Member since:
2005-10-02

It's not a vacuum cleaner. It's a dustsucker! ;)

Reply Score: 1

RE[2]: Here's a question...
by Phloptical on Sat 15th Dec 2007 23:57 UTC in reply to "RE: Here's a question..."
Phloptical Member since:
2006-10-10

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.

Reply Score: 1

RE: Here's a question...
by google_ninja on Fri 14th Dec 2007 19:43 UTC in reply to "Here's a question..."
google_ninja Member since:
2006-02-05

As opposed to "open source" and "visual innovations"?

Reply Score: 2

Carefull with transparency
by Alleister on Fri 14th Dec 2007 16:53 UTC
Alleister
Member since:
2006-05-29

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.

Reply Score: 3

Errr...
by asr4096 on Sun 16th Dec 2007 00:32 UTC
asr4096
Member since:
2007-09-18

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

Reply Score: 1