x.org can do some pretty cool things these days. everyone knows all about compositing window managers, like kwin 4 and compiz, to name two.
but the fun isn't relegated to the window managers! you can set an argb (alpha, red, green, blue) visual for your application and play with translucency, shaped windows and what not to produce some rather nice visual effects.
plasma has a history of pushing the boundaries of the technologies it uses. this happens because the plasma team looks around, sees what is possible and we imagine what that could be .... and then we write the code to make it happen.
unfortunately in the case of making it happen with argb visuals, it seems that nobody other than window managers are using these things. how do i know? because none of the toolkits actually frigging work properly with them.
Qt has visible painting bugs in scrollable widgets when there is an argb visual.
Gtk+ apps crash when the system tray icon is placed in an app using an argb visual since it apparently can't deal with having the background set with XSetWindowBackgroundPixmap on an XEmbed client window in that particular case. unfortunately, to make the icons work at all properly in an argb window we need to do exactly that.
(i, or someone like me, needs to file a bug against gtk about this. i only tracked this down last night and confirmed the cause, which is why i haven't yet.)
but plasma only really shines with argb visuals: translucent panels, a see-through dashboard, etc.
so now i'm conflicted.
do i release plasma in all its shining glory and show the toolkits to be buggy when it comes to handling argb visuals?
or do i retreat, like probably every other serious app that may have gone before me, and make plasma look less hot (excuse the pun ;) but work properly?
i'm leaning towards "show up the toolkits" for two reasons: a) i really don't like the idea of hobbling our app because of other people's bugs, b) if nobody uses argb visuals, i fear that the toolkit projects will never prioritize the necessary fixes.
it's fun being at the edge of the technology, but they do call it the "bleeding" edge for a reason. well, that's sort of ignoring the fact that we've had argb support in x.org for a while now.
but the fun isn't relegated to the window managers! you can set an argb (alpha, red, green, blue) visual for your application and play with translucency, shaped windows and what not to produce some rather nice visual effects.
plasma has a history of pushing the boundaries of the technologies it uses. this happens because the plasma team looks around, sees what is possible and we imagine what that could be .... and then we write the code to make it happen.
unfortunately in the case of making it happen with argb visuals, it seems that nobody other than window managers are using these things. how do i know? because none of the toolkits actually frigging work properly with them.
Qt has visible painting bugs in scrollable widgets when there is an argb visual.
Gtk+ apps crash when the system tray icon is placed in an app using an argb visual since it apparently can't deal with having the background set with XSetWindowBackgroundPixmap on an XEmbed client window in that particular case. unfortunately, to make the icons work at all properly in an argb window we need to do exactly that.
(i, or someone like me, needs to file a bug against gtk about this. i only tracked this down last night and confirmed the cause, which is why i haven't yet.)
but plasma only really shines with argb visuals: translucent panels, a see-through dashboard, etc.
so now i'm conflicted.
do i release plasma in all its shining glory and show the toolkits to be buggy when it comes to handling argb visuals?
or do i retreat, like probably every other serious app that may have gone before me, and make plasma look less hot (excuse the pun ;) but work properly?
i'm leaning towards "show up the toolkits" for two reasons: a) i really don't like the idea of hobbling our app because of other people's bugs, b) if nobody uses argb visuals, i fear that the toolkit projects will never prioritize the necessary fixes.
it's fun being at the edge of the technology, but they do call it the "bleeding" edge for a reason. well, that's sort of ignoring the fact that we've had argb support in x.org for a while now.
30 comments:
How are things looking for the ARGB-issue being fixed in Qt? Will it be fixed for 4.4?
Well if your asking I'd go with bleeding edge good looking - it will help the other stuff get fixed; more of a long term invest,
can we have translucent panels in plasma right now?
Isn't the point of KDE 4.0 to create an infrastructure for the next generation of apps? If Plasma compromises here, the apps will have to avoid ARGB visuals as well.
It would be good though to file those bugs as soon as possible and include a test case that demonstrates the problem. The easier it is for the toolkit people to reproduce it, the sooner they will have a fix for it.
@anonymous mark 1: "How are things looking for the ARGB-issue being fixed in Qt? Will it be fixed for 4.4?"
don't know yet. i have to ping some trolls to find out.
@frylock: that's my hope indeed.
@anonymous mark 2: "can we have translucent panels in plasma right now?"
yes. in fact the default panel has translucent borders. it rocks =)
@maarten: yes, that's exactly why i'm leaning towards leaving it as is even if exposes the toolkit bugs. =)
definitely file bug reports against the tool kits, KDE should have enough mass to give it some priority, and to be able to use these techniques broadly would be a tremendous advantage to the desktop in general.
@Aaron J. Seigo: "yes. in fact the default panel has translucent borders. it rocks =)"
yeah i've seen that, is very nice indeed ;)
it would be also nice if we can set the options to make the black part of the panel translucent and also the option to add gradients with translucency, etc, while the icons and the other plasmoids in the plasma containenement stay non-translucent, and also make some part of krunner and/or other plasmoids to be translucent like in david's krunner mockup.
kde4/plasma already rocks, plasma is very sexy... and i'm rebuilding my kde4 right now :-)
thanks and keep up the excellent work, you rock :)
I'd say go for it.
It's not like it is going to make or break the look of plasma for 4.0.. people are going to be so distracted with its other shortcomings they probably won't notice any bugs!
i second dave's idea
"Gtk+ apps crash when the system tray icon is placed in an app using an argb visual"
Sorry, but I think that makes it a no go. Interoperability is a too important issue to sacrifice it for hotness. I myself use a lot of GTK apps under KDE, and having them crash because of some looks is a show stopper for Plasma for me.
@anonymous: "the black part of the panel translucent and also the option to add gradients with translucency,"
you already can. just change the svg and voila ... this is the beauty of svg theming + argb visuals.
@dan: "people are going to be so distracted with its other shortcomings they probably won't notice any bugs"
heh. nice backhanded compliment.
@cassens: so how do we get argb visuals fixed in toolkits if there is no pressure put on them? this is a long standing issue given how long we've had argb visuals in x.org.
I agree that there needs to be pressure put on the toolkits, but what if GTK doesn't get fixed for a long time? GTK development isn't exactly fast, and if it takes 6+ months to get fixed that's a lot of misery for users. There should probably be at least an option to turn off the ARGB visuals for people that need working GTK apps now.
I would say go for it. KDE4 is going to expose bugs everywhere as all the foundational libraries get stressed in different ways.
Derek
@Leo S: "There should probably be at least an option to turn off the ARGB visuals for people that need working GTK apps now."
if you disable composite in X then you wont have ARGB visuals and you can run all the GTK+ apps you want without any problem.
i'm with Derek, for what it's worth :) (i was about to write a similar argument, but... hey, someone else with more clout than myself did it before, so yay! ;) )
i'm with Derek too :)
1. Expose the bugs.
2. File a bug report.
3. Make sure it's noticed by commenting and voting on the bug and blogging, mailing, stalking dev's on IRC.
4. Someone will prepare a patch.
5. distros will apply and ship the patch if they want KDE4.
--------------
6. As a backup, option to disable ARGB in the system tray.
I thing coolness is a priority because you can sit in front of your workstation with a cool beer and say: "Who's the coolest, me or you? You, indeed!" ;)
Seriously I prefer to push the boundaries far, so ARGB visuals are an important feature to have (even in GTK+).
I bet on a "it's not our fault, it's yours" answer from GTK folks -grin-
I would definitely go with ARGB visuals, that's what i fell is KDE4 about - advancements
Maybe the Kstars team can improve the "red light" night mode with the help of argb...
I was going to say that AWN has the status icons in a ARGB window, but it seems that it doesn't do the translucent background on it.
Though to be honest, there is a lot of stuff using GTK that uses ARGB visuals and it all works fine. You were just unlucky your problem is a very obscure cornercase. I'm sure if you file a bug it'll be fixed quickly
I'll weigh in with, if possible, making use of ARGB a configurable option, enabled by default.
Then people will get it and see the new hotness, which is good. And the bugs will be exposed, putting pressure on the TK writers to fix those bugs. But if the problems exposed in old-and-busted toolkits prove too much for them, they can turn ARGB off until the bugs get fixed.
(Won't this need to be an option, or something that can get turned off anyway? I'm thinking low-bandwidth connections, old X servers, etc...)
I vote for ARGB visuals if the bring discernible sex appeal. How many GNOME 2 tray icons does a typical KDE user have? In my case it's precisely zero... And while this is bad from a statistical POV, the other KDE users I know are pretty much the same. I think the vast bulk of KDE users probably use 3 - 4 killer GTK apps then try to keep the rest of their 'KDE Stack' pure. (And those generally aren't tray apps.)
Also, Plasma should be about bringing hotness to KDE 4, NOT bringing hotness to KDE 4 and hacking around Gnome bugs.
Go for it! Because we like bling-bling and eye candy. And we will like Plasma if it has those.
When non-Linux users say "Wow! Linux looks sooo hot!", they're usually looking at a video showing Beryl/Compiz/Compiz Fusion in action. I use neither, it's quite unstable on my system and I find KWin superior in other areas - but would you 'brag' about KWin if you show your Linux desktop to a friend? Probably not. You show them Compiz Fusion, even if there are some bugs.
Could anyone make a good and simple tutorial on how to make argb window with qt?
@aaron
I buy your point that exposing bugs pressures toolkit devs to fix them. And yes, I understand it is a long standing issue. I personally just don't care a lot about hot visual effects on my desktop. Judging from the comments I'm almost alone on that on (oh, hans, when I show off KDE then I just demonstrate the power of kio - now that rocks:).
So I would just be happy to have the option to disable that hotness (without disabling composite completely) to not crash the 2 or 3 non-KDE apps that are sometimes sitting in my tray until the respective toolkit is fixed.
For the question falls the category "What doesn't it have that feature already?"
When I think Plasma, I take alpha channel for granted.
can't you detect if the client application supports ARGB ? if the apps does not support it, could not you default to some settings so the app would run anyway, although those apps will be ugly for a while, until they fix their bug.
Post a Comment