GNOME Bugzilla – Bug 325373
Add scroll-to-set-transparency support
Last modified: 2006-01-07 22:06:01 UTC
I created a patch which allows you to set a window's opacity level by scrolling with the mousewheel when the pointer is on the titlebar of a window. This is more a proof-of-concept than a real patch that should be included into HEAD as it might not follow some metacity HACKING rules... Obviously it won't work when no composite manager is running. See bug 309152. Some issues: - The NET_WM_WINDOW_OPACITY X property is changed inside meta_core. Is this allowed? - I'm using an XLib function in there, with a "raw" atom. I saw some atom handling code, but didn't really understand it. I guess meta_core_set_xwindow_opacity should be moved to some more appropriate place (meta_ui_frame_set_opacity ?), and use the metacity atom handling code instead what I use now. - The opacity value is stored inside a MetaUIFrame. This means when some external thing like transset or other code changes the opacity level, and the user scrolls on the titlebar, the existing transparency level won't be taken into account. I tried to change this (not storing the level inside the MetaUIFrame, but always doing an XGetWindowProperty call), but this crashed metacity everytime (I'm new to XLib coding). - It might be completely non-HIG. I hope to get some input so I can fix all issues :-)
Created attachment 56586 [details] [review] Initial version Initial version of the patch.
Okay, so in IRC I thought you were making this patch for your own amusement and fun. I hope I didn't mislead you or anything, because the behavior isn't something that would work to include in Metacity (scroll on titlebar to shade is requested far more often and it has been wontfix'ed, and some of the reasons for wontfix'ing it given throughout bug 91338 and also particularly bug 142825 comment 5 also apply here). I get additional loser points for forgetting about bug 167391 and bug 152991 or I could have told you about them before you spent additional time working on this. Sorry about that. I'll try to answer some of your other questions, and point out the parts that I do know about, though (which is admittedly limited since I avoid theme/frame issues and am clueless about composite and such): Some of the points from bug 152991 comment 2 apply to your patch, as well (and also comment about the XGetWindowProperty thing, which the other person did); it'd be worth reading over. - The _NET_WM_WINDOW_OPACITY property should be declared in display.[ch] with the other atoms. - Wouldn't deleting the opacity atom prevent other apps from updating or modifying it? It seems it would e better to just leave it. Also, for purposes of monitoring the value from other apps, it should probably be handled similarly to other properties from window-props.c. - There's a glib CLAMP function so that you don't need to use two separate MIN and MAX commands. - The changing of the opacity property in core.c seems odd as you point out. I'm not really sure where it should go, though, since it turns out to be related to the window's frame xwindow instead of the window's xwindow; something I haven't dealt with before. We could ping Havoc if you're curious. Anyway, I'll go ahead and mark as a duplicate of bug 152991. *** This bug has been marked as a duplicate of 152991 ***