Hi all,

I'm at the moment using my limited laptop's screen and having quite many windows open. Since i don't want to use shif+tab all the time I have some chat windows and stuff "keeping above others". These windows have opacity 50%/75% so i can see the work i'm really doing.

But, even I can see my whole "kdevelop/firefox/konsole/eclipse" behind my "opacity windows" I am not able to click the buttons and links behind the opacity windows. It's like "you can watch but not toutch" feeling from more normal life

It's super boring to move a window to be able to click a link even you can see the link already.

What do you think? Would it be nice for you that there would be a option like "When having a shortcut key cobination you can click throught the windows with opacity"?

What do you think? Did I make any sence? Does this idea make any sence? For me it does. Let me know your oppinion.

PS. Does this possibility already exists? Did I just search with wrong keywords?

Although I haven't read about it yet, Windows 7's "peek" feature comes to mind. It would be pretty cool if you could
1. Make the active window 100 % transparent (similar to the Windows screenshot I linked to) with a keyboard shortcut
2. Interact with the windows beneath the transparent "active" window as if it didn't exist
3. Press shortcut again to return to the active window (now back to normal)

This idea is similar to yours but also works if your active window isn't transparent. The bad thing with my approach is that it only works for "clicking through" one window, but I think it would be less confusing that way.

Actually, now when i think of it, I'm not sure if it would be better to use a "key shortcut" to be able to "click through opacity windows" on links/buttons behind the "opacity windows" or to keep opposite as default and use "key shortcut" to be able to control a "opacity window" with mouse and not the window behind...

Both possibilities would be cool actually At least the way my brain works

I like this kind of thinking... better multi-tasking is certainly a feature the desktop can and should help with and simple task switching doesn't cut it now. I'd love to see some innovation here! And OSS can innovate faster than big organisations

As for how it could be made workable... that's hard. IMHO transparency (in the simple sense) is not actually the right device to use here. Why? Because contrast becomes an issue for readability. If the overlay has lots of contrast in its UI elements (white background and grey widgets) then you don't get to "see through" both properly. Also any colour in the semi-transparent object can really interfere with your viewing of the active window underneath it.

You need to retain more opacity for active elements (like text) and less for elements for background elements. And you need to loose colour saturation in the transparent front window also to allow you to keep using the background app with minimum pain. The "application" needs to become a ghost if you like - leaving a visible trace of its information in the overlay.

Get this idea into software before MS tries to patent it!

KWin also lets you move a window to the bottom by middle-clicking on the title bar, or clicking anywhere in the window while holding down the alt key and middle clicking.

In case it's not enabled by default (I use a rather heavily customized KWin), you can enable it through System Settings > Window Behavior > Titlebar Actions > Middle button > "Toggle Raise and Lower" (or Lower), and in the Window Actions tab, set "Modifier key and middle button" to "Toggle Raise and Lower".

Not the ideal solution, but a decent temporary one.

jrick wrote:Not the ideal solution, but a decent temporary one.

Yes, this is the one I'm using sometimes now. But I still need to "pop back" the window I hide. And most of the time I forget that of course when browsing something ... interesting [hr]

andre_orwell wrote:You need to retain more opacity for active elements (like text) and less for elements for background elements. And you need to loose colour saturation in the transparent front window also to allow you to keep using the background app with minimum pain. The "application" needs to become a ghost if you like - leaving a visible trace of its information in the overlay.

Yes. I have this issue often and i sometimes end up having very crazy colors on my konsole/other programs But it's usable and that's what i like

I'm sure there must be a way this can be done nicely . Hey guys and gals! More options!

I've had that idea of "ghost windows" before, usually when copying something out of a scanned document.

Usually, when I'd doing that, I make the active window semitransparent and then put the window that I want to copy underneath. It's not a really good solution because it all the window elements are transparent and it gets a bit confusing.

If it was possible to make a "ghost" window that you could see but click therough, that would really be cool.

The only problem with ( being able to implement ) this is that KWin ( or whichever application provides this ) would have to intercept all click events, then send them directly to the application in question ( I do not even know if that can be done... ).
If it could be done, I would imagine the overhead could be pretty bad ( especially as the screen gets larger... )

bcooksley wrote:The only problem with ( being able to implement ) this is that KWin ( or whichever application provides this ) would have to intercept all click events, then send them directly to the application in question ( I do not even know if that can be done... ).
If it could be done, I would imagine the overhead could be pretty bad ( especially as the screen gets larger... )

Couldn't it be done using Composite? I there is a KWin plugin (forgot what it's called - I'll look it up later) that shows repaints and some other information on top of whatever is displayed, but does not actually steal mouseclicks. The "ghost" window cold do that too - it doesn't have to be a real window - just an up-to-date image of it.

bcooksley wrote:The only problem with ( being able to implement ) this is that KWin ( or whichever application provides this ) would have to intercept all click events, then send them directly to the application in question ( I do not even know if that can be done... ).
If it could be done, I would imagine the overhead could be pretty bad ( especially as the screen gets larger... )

I don't think "my" idea has this problem, as the transparent window acts as a minimized window - the really difference is that it leaves a "ghost" window behind, and you can easily restore it.

Implementing it as Alec suggested would probably be the way to go, which of course means no "intercepting layer". I have never used the plugin you are mentioning, however for some unknown reason I always thought it would add something on top of everything that would prevent me from using anything underneath it, but if it just is seamlessly added on top then that would be fine.

I agree.. I don't see the need for this to be implemented as a window with transparency. It just needs to be a up-to-date view of an application's window overlayed.

I admit though that this provides less options for getting the look of the overlay right. In my thinking, widget appearance needs to change (button backgrounds become completely transparent for example). Desaturation can be done as part of the overlay op however as its a simple image manipulation.

bcooksley wrote:The only problem with ( being able to implement ) this is that KWin ( or whichever application provides this ) would have to intercept all click events, then send them directly to the application in question ( I do not even know if that can be done... ).
If it could be done, I would imagine the overhead could be pretty bad ( especially as the screen gets larger... )

I'm not sure if this needs input redirection or not, if it does then it's impossible to add to KWin for another few years (Or however long it takes for X to get input redirection support, apparently its been pushed back to X12!). If it doesn't then it will be possible to add sooner, if someone can add this to bugs.kde.org it would be great (I lose forum theads).

Input redirection is also not very expensive to perform.

Have you tried the «Thumbnail aside» kwin plugin effect. I think that fulfills what you described.

The description for that plugin says "Display window thumbnails on the edge of the screen" which sounds pretty different at first pass. How would you install it to check?...

found

This is similar... certainly provides an overlay that has the desired "click through" behaviour. [hr]
Hmmm... This really seems to slow down my machine (which is fairly new but admittedly low end). If I am using rhythmbox with this effect on I get lots of drop outs in music playback. Is this likely to be a build issue? I find the same thing with present windows. What needs to be optimised here?

Ignoring the slowdown issue there are a few things that make this effect different to the one being discussed in this thread so it would be good to get an idea about how best to proceed:

1. The existing plugin generates a thumbnail; proposal is for a full sized window
2. Existing plugin doesn't make any attempt to "ghost" the overlay to maximise readability of fg and bg.

Playing with gimp... how do I attach an image of a "mock-up" showing what I mean by ghosting?...