Reposition windows on resolution change if they lie completely outside of the bounds of the new resolution

[humdinger]

This is hrev29283.

I temporarily changed the screen resolution to 1680x1050, but redraws were too slow (vmware). So, I switched to 800x600. When invoking the "Open" file dialog in DiskProbe, it opened in a position that was invisible with the new lower resolution.

File dialogs should make sure they are visible before they are shown. I also think they should be resized to be completely visible. I've often experienced dialogs where the bottom with the OK button is outside of the screen. Doubly annoying, since windows are only resizable in the lower right corner, which was also outside...

This should also be done when starting applications, though they shouldn't be resized, just make sure they are at least partly visible.

[anevilyak]

Do you have some example apps? BFilePanel always positions itself near the top left corner of the screen at construction time, so this seems to imply the apps are either restoring a saved position without checking its validity, or otherwise explicitly moving the window around, which I don't really see a sane solution for without essentially preventing the user from ever moving the file panel outside of the desktop's bounds. The latter I'd rather avoid since no other window behaves that way, and there might be valid circumstances where I'd want to move the dialog out of the way to look at something else quickly, in which case, i.e. moving it down so only its tab is visible would be a valid use case.

[humdinger]

I think you're right that it's apps restoring saved positions without checking if that position is actually currently visible. For example, open DiskProbe, choose "Probe file..." and move the dialog to the bottom right corner of the screen (assuming you have a sane resolution like 1650x1080). Now close it and change resolution to 800x600. Do the same again and you won't see the dialog, as that's now outside the screen.

Question is, instead of fixing every app to check the visibility of saved coordinates, can we tell the app_server to automagically move windows into visibility when created/shown? Or add a flag for that when creating a window and have file dialogs use it by default?

[anevilyak]

The problem is, you can't actually tell a file panel its position immediately at construction time, you have to move it afterwards, which makes detecting that situation somewhat less obvious. Adding a flag might be possible, though that presents bin compat concerns since BFilePanel's constructor doesn't have a parameter to pass flags at all at the moment. So without an API change this wouldn't really be fixable anywhere other than the apps, and the apps would need to be adapted in the case of an API change anyhow.

[humdinger]

I see. OK... Well. But as the app_server still does all the moving, maybe it'd be OK to never move (or create) things completely outside the visible screen.

(It's not a big problem (at least for me :) ) any longer, as I'm not using vmware anymore and virtually never change screen resolutions. It may still crop up now and then when I share settings between notebook and netbook. Feel free to close the ticket if it's not feasible or compatible with current the API.)

[anevilyak]

The situation of being completely outside is definitely a valid problem case, though that would apply equally to all windows. Reassigning this as an app_server enhancement to cover that.

[axeld]

Unless the window was on screen before the switch, the app_server cannot deliberately move it there afterwards. The original ticket was about saved window positions, and it's not within the app_server's abilities to change that -- it cannot know whether or not the application created the window off screen on purpose. There are even good reasons to do so in Haiku (like having an application that should get all keyboard or mouse events).

IOW the original problem should simply be solved in Tracker. In addition to that, the app_server could move windows around on resolution changes; but this might be a bit annoying, too, if you have games and apps like LaunchBox (or the Deskbar) in the right edge, so it should only do so for permanent changes.

[axeld]

BTW AFAIK libtracker.so is the one responsible for memorizing the panel's position, so it could easily fix this issue.

[anevilyak]

For the resolution switching case, certainly, but not for the case where the app deliberately restores an off screen position AFAIK, BFilePanel doesn't do any persistence of that on its own.

[stippi]

I don't know of any application that actually saves the file panel position. Probably because libtracker has been doing that on a per app bases for a long time. Also, the idea with app_server preventing off-screen locations for creating windows at, it's not possible nor wanted to do this, because some apps actually create a window outside the screen on purpose, then move it to the visible portion. Fixing this in libtracker is the way to go.

[anevilyak]

Replying to stippi:

I don't know of any application that actually saves the file panel position. Probably because libtracker has been doing that on a per app bases for a long time.

Where? I don't see it.

Also, the idea with app_server preventing off-screen locations for creating windows at, it's not possible nor wanted to do this, because some apps actually create a window outside the screen on purpose, then move it to the visible portion. Fixing this in libtracker is the way to go.

I didn't mean in general, I meant specifically the case where a window is visible/accessible, but then a resolution switch results in it being outside of the new visible bounds, ergo the user no longer has a way to manipulate it / move it back. I didn't mean preventing them from ever being moved outside of the desktop bounds, just in that one case, which imho is a valid one and covers more than just file panels.