3

The idea is to be able to zoom in/out a window and leave it at this state on the desktop.

A simple example is having a browser window playing a video. The video can't be resized itself and resizing the browser window will also not resize the video but crop the visible space in the window. Instead, an enabled desktop effect would zoom this specific browser window out whilst reclaiming desktop real estate and showing permanently a smaller version of the window playing its content. Other windows at the same time remain at their respective real size.

Something similar could also be done for zooming in whilst claiming desktop space.

I just came across this while searching for a similar issue, but in the opposite direction. I just downloaded "Maelstrom", which plays very well, except for the fact that the window/zoom is tiny and very hard to see. You can't fullscreen or maximise it, so a "zoom in" managed by the window manager would be excellent.

Simply scaling a window is technically trivial and should even be possible with a scripted effect.

The major issue with this idea is that there's no input redirection on X11, ie. the compositor has no impact on esp. the mouse interaction.
What you see doesn't match what is there what means that even if you blew up a window to the doubled size, the actual window is still in (eg.) the upper left quarter and you had to map the mouse input there.

That's probably not an issue for something like a video or asteroids clone, but is in general.


Luckily this limitation does not exist on Wayland

Is there a solution by now?

The issue is more and more important since there are so many high resolution displays out and some applications don't listen to the global font-setting for font DPI in KDE see: http://askubuntu.com/questions/419729/h ... dow-in-kde

See my last comment - there won't be a solution on X11, ever.

While scaling the visuals is trivial, mapping the mouse input is rather impossible (ie. you do not click where you think you click) - global zooming does this with ugly tricks that do conceptually not work with individual scale factors.

The proper solution to your problem is to fix AWT/Swing ie. whatever java application(s) / toolkits that are not DPI aware.

I'd like having such a feature and I don't think it cannot be hacked more or less elegantly (having the expertise...)

If input works well with global zoom you only have to set the global zoom to match that one of the zoomed window when you want input in it. Obviously, if you want the desktop and the rest of the windows to keep their visible size, you'd have to apply the inverse zoom to them. But even then, this is now a problem of getting the right relative sizes and positions of the windows and not one of reengineering X so it should be more approachable.

Many days ago Mandriva creates project, which allows to crop window. It was called Mettisse.