For the past weekend I was preparing an external USB HD to work on testing things on Haiku without touching my default install at home, and to carry it along, so I can do stuff from anywhere. While I had some issues in order to achieve this, they are out of the scope of this post and will talk about them in another one. In here, I’ll talk about three “issues” that I found when testing the new “Haiku install”. Nonetheless, I do understand that these happen due to “my particular” setup.
1- Screen size: At home, the display is a 3440x1440 px. At work is a 1680x1050px. As I tested at home on the ‘big’ screen, when at work, WebPositive launched outside of the display boundaries. Had to remove the “session” file in WebPositive’s settings to get WebPositive back on screen.
Wouldn’t it be the optimal behaviour for the apps to appear inside the screen?
2- Background scaling: related to 1. A background image has options to be placed manually, centered on the screen and scaled to fit. I would add a “shrink to fit” option there that scales the background vertically and horizontally to fill the screen. Scale to fit scales the image vertically thus not showing the whole image as parts of the image extend beyond the boundaries of the display. A shrink to fit option available would allow the image, though distorted, fill the screen.
3- Workspaces applet: related to 1. As I have the workspaces applet on all the time, extending at the bottom of the screen from left border to the right border, when changing the display, the applet keeps its original size, thus extending way beyond the display boundaries. It would be nice that the applet would scale to fit the display width (in my case) or height.
I have to agree here. Haiku does not handle going from a high resolution to a lower one very well. Found that out when I moved the VCS from a 4K tv to a 1080 monitor.
This is something that should be entered as a bug, also, I think.
What might be handy here, is a “Snap back all windows” option when you right click on the app in the Deskbar. Have it move all window belonging to that app back within the bounds of the desktop area.
In that case optimal behavior here is for the applications or app_server to only “fix” the location if the display size changed since last boot. I don’t know if anything tracks the last display size but that could always be added.
To be really clever maybe the locations of windows could be associated with each unique screen (by name any/or resolution), such that when you change main screens the windows move to where they were last time on that screen. Though there may be weird corner cases but overall it sounds decent. I would have to check out how other systems behave on this though I assume they behave badly.
Things like this would also set the groundwork for multiple monitor support and making sure windows show up again on the same screen they were closed on.
So it’s app_server’s duty. Good to know. Agree here.
Agree here too.
In the meantime, I’ll think I will have to stuck to deleting the WebPositive session each time I move to the work pc, keep the workspaces smaller than the smaller display, and keep a shrinked down background to apply when moving to the work pc.
Looking forward to this improvement. and the video out too, so can use Haiku for keynotes.
Currently it isn’t, and it’s up to each application to use BWindow::MoveOnScreen as appropriate when they create a window based on saved positions in a settings file. app_server just does what the application asked, and if for whatever reason an application wants to open a window outside of the visible area, it is allowed. app_server also has no idea that the window position is from a previous session, or something that the app just decided, so I’m not sure how it could guess that.
I’m puzzled. What I’ve seen is that Tracker and WebPositive render the windows outside the display boundaries, if last time those windows where in such position on a bigger resolution display (I presume this because I can’t see those windows on the smaller resolution display), while Otter (Qt) launches by the Deskbar.
I should test this with other apps too, in order to veriffy that native apps behave like Tracker and WebPositive, while Qt apps still render within the boundaries.
Nonetheless, while I understand your reasoning, doesn’t it seem like an odd behavior?
It is code in each application saving their window position and restoring it, not something that the OS is doing. Several applications implement it. All the applications that do this need to be fixed to take this case into account.
It depends what you mean by “odd behavior”. The applications do exactly what the code was written to do. But the developers who wrote the code did not think of this particular case, “what if the screen changed size since last time?”. So we need to add this check, and do the right thing, of course.
What I was saying is that I think it should be done in these applications that save their window position. It is not app_server job, because app_server cannot know why an application is asking to open a window somewhere outside the screen. Maybe it’s this case where the window position is saved from a previous session. But maybe it’s something else. Maybe the application wants to create an offscreen window and then scroll it in on the screen with a nice animation? Why not? So by trying to fix this in app_server, we could create other problems in other cases. Whereas if we fix it in the affected applications, we have more information available to do the right thing.
Maybe app_server should handle this? I imagine it would be really frustrating for developers to be have to implement code for handling window positions where the issue stems from non-application sources?
I don’t know any other operating system that expects the application to handle this (only know about macOS to be fair).
I think @PulkoMandy is being pragmatic. The short term fix is to make these apps which save their window positions do a sanity check of their position against the current screen size. That will fix the issue at hand.
But longer term it might be nice for app_server to handle this. It would likely be something post R1, and could be related to both session management (restoring open windows for ALL apps after a restart, like macOS has) and also multiple screen support. That was my thinking in my previous post, where I was thinking in ideal terms but maybe not very pragmatically for the moment.
But for now, the most expedient and straightforward way to fix this is in the current application code.
The application saves its window position in a file
When starting up again, the application reads the setting file
It finds a window position there
It asks app_server to recreate the window with that same position
app_server complies
As you can see, the problem is entirely the application’s fault in this case. And app_server can do nothing about it because it doesn’t know if the app just used a saved window position and did not notice that the screen size changed, or if the app is intentionally creating a window off screen for another reason.
It’s not app_server doing anything by itself here.
Also, the fix is very simple: applications just need to call MoveOnScreen on their windows if they create them this way. It is one line of code. The application is the one who decide on the window placement and so this code should be on application side. app_server is just doing what it is asked to do.
The case of changing the display resolution while the app is running is different. There we may want to do it in app_server. But this is not what was complained about in this thread.
With my ignorance beforehand, I have to agree with @PulkoMandy, as well as with @leavengood and @Diver. What they say makes sense to me.
What I do, not being a dev, the app I’m working on just asks the screen which is its size and then places the window in the center relative to said size. So, instead of placing windows in absolute positions (H, V)=(Xpx, Ypx), place them in relative positions (H, V) = (X%, Y%), thus if the display size changes, whatever the size would be, the window will appear in the translated position.
In a multi-monitor scenario it would also work in an Extended Desktop mode. Disconnecting other displays will end up limiting the render size to only one, and the window would appear in the translated position, connecting the monitors again, will put the window back in its ‘original’ position on the proper display.
Devs, does this make sense?
I’d like to have the multimonitor setup working so could use Haiku for keynotes, with extended desktop, and use a pen display for art.
The background Image is the size of the smaller display. Placed at Center, so it will appear centered on the bigger display (setting the background color of the virtual workspaces to the color of the background image).
Moved the workspaces applet to the top, beside the Deskbar, so they never go out of bounds.
Remember, remember to move all windows to the top left of the bigger display before shutting down the box, so they will appear within the smaller display boundaries upon launch.
For now it seems to “hack” the issue.
Besides, I redid the HD. Before had 3 partitions, EFI, System and Data. Looks like this was not the best setup for an USB external drive. Now just have two, EFI and System. I was experienced a weird issue on one of the boxes, BIOS didn’t see the external drive as bootable, now it does and shows up in the Boot Menu of the BIOS.
I have this problem on Windows and Linux too. Both have elaborate ways to bring a window back to screen, and I have to google them every time. The initial window positioning, however, seems to be up to the application on those systems too.
and the video out too, so can use Haiku for keynotes.
“The twilight zone”.
