fyne
fyne copied to clipboard
fyne-io
Reposition Window programmatically
Is your feature request related to a problem? Please describe:
I have a window, which needs repositioning according to some other application. I already know the screen position, widt,h and height of the other application and can hence place my new window besides it.
Is it possible to construct a solution with the existing API?
Looking through the code, the only positioning of the window is done with CenterOnScreen. Hence one is not able to reposition the window programmatically.
Describe the solution you'd like to see:
I guess this feature could be handled by adding another API method "Move" that uses almost the same logic as CenterOnScreen, but repositions the window according to input parameter x and y.
Thanks for this, I guess I can understand what you are trying to do. I am a little nervous about how this could be mis-used as internally the coordinates are scalable and so don't correspond to pixel positions. I'm mostly just frustrated because some of my apps continue to position themselves on a screen that does not exist becuase last time I had an external monitor plugged in.
How can we ensure that such an API does exaclt what users expect as well as what developers want?
There is a concern amongst the team that this function enables potentially user-unhelpful behaviours and encourages multi-window (I.e. palette) window apps which are discouraged in favour of laying out items in a larger window.
While I do understand your concern, I still believe this is a very useful and valid feature.
In the end, how the application is layed out is up to the application developer, not the framework. That being said, one could easily write comments that encourages specific use of the method.
That's a tough point actually - many systems would say it's up to the OS/Window Manager. In macOS an the main APIs moved to require specific pemissions to move or resize windows, so it's not quite so trivial.
Potentially it we could be limited it to only being called before Show(), also make sure that the requests are within visible bounds, and ignore any requests after that to avoid usability issues.
One other thing to note - what coordinate system would you use? When calling Resize() it is not using pixels - so a Window that has Resize() with 200, 200 that is placed at 0, 0 will not have bottom right 200, 200. There will be the windowmanager specific borders added and then also the monitor scale is a factor. Mostly likely on a modern monitor it is more likely bottom right 432, 408 - how do you factor that into a Move() API?
That's a tough point actually - many systems would say it's up to the OS/Window Manager. In macOS an the main APIs moved to require specific pemissions to move or resize windows, so it's not quite so trivial.
Potentially it we could be limited it to only being called before Show(), also make sure that the requests are within visible bounds, and ignore any requests after that to avoid usability issues.
One other thing to note - what coordinate system would you use? When calling Resize() it is not using pixels - so a Window that has Resize() with 200, 200 that is placed at 0, 0 will not have bottom right 200, 200. There will be the windowmanager specific borders added and then also the monitor scale is a factor. Mostly likely on a modern monitor it is more likely bottom right 432, 408 - how do you factor that into a Move() API?
Many application in Windows OS restore to previous state (position and size). With Fyne this is possible except for the position part which a bit of a shame. If this does not work for all vendor it's ok because I guess Window.Resize is not implemented for Android. Also : content size, canvas size are not exactly the same size used by Resize... Fullscreen does not refer to maximized state... We, as desktop developers, really need a proper Window API.
There is a previous discussion about remembering window state (#554) which makes sense, if that is what Window.Move() would be used for then we can happily implement it behind the scenes using a more semantic API.
We will be adding support for Wayland (the replacement display tech for Linux/Unix) and it has no support for positioning windows either, so this feature cannot even be guaranteed to work on Desktop going forward :(
Could work:
- Windows
Depending on settings:
- macOS
- Unix X11
No support:
- Android
- iOS
- Unix Wayland
Not sure how to handle such a feature when it works on just a subset of platforms.
Not sure how to handle such a feature when it works on just a subset of platforms.
I think not fully cross-platform functionalities should throw or return an error but must not panic.
I would put Unix X11 in the depending on settings. Some Windows Manager may decide very strongly where a windows should be and not let the application do what they want.
It isn’t supported on some platforms and we don’t want to mislead developers by exposing an API that may not work. – andy.xyz Jan 10 at 19:21
on mobile:
func (w *window) SetFullScreen(bool) {
// no-op
}
This is quite a similar case. There is an API SetFullScreen() which has been fully implemented only on selected platforms.
In my opinion, blocking a certain feature on all platforms just because one of the platforms does not support it is not a good approach. I prefer to get an API that works on some platforms and a "not supported" error message when I use this API on a platform that does not support it. Of course with warnings in the documentation.
This is quite a similar case. There is an API SetFullScreen() which has been fully implemented only on selected platforms.
Unfortunately not similar enough. There is a general understanding that mobile apps run fullscreen and the drivers split cleanly between desktop and mobile (at least in naming). However this ticket (as documented above) refers to a feature that is not possible on some platforms outside this divide. You also need to consider that the simple "position" attribute is not in our coordinate space. The different operating systems have different ways to refer to positions on a screen, and we also have to consider how multiple screens are handled or declared.
Add to all of this that moving windows without user action (like dragging window border) is a pretty frustrating anti-pattern anyhow. If you disagree with this then please do provide the use-case so we can try to find a way to enable it without tripping up on all the hazards along the way!
I must admit that I am very glad that Linux (and somewhat *BSD) is moving to Wayland, which deliberately doesn't support this. Windows doing their own position handling is a terrible design decision in my opinion. It never quite fits in with my other windows and they behave strangely on multi-monitor setups because the developer forgot to, or could not, handle some necessary case. What use case is there for moving a window from within the application itself?
If I can add my two cents on this topic.
One of the main purpose of in-app window handlers management is about design systems and application design integrity.
I know that not many of us (developers) really care about design and do prioritize function over it, however, their are really good examples of well done applications using such path like Steam, Battle.net etc.
As I’m currently building a rather large professional application using fyne, our internal design team indeed emphasized about that specific topic recently.
So far we only use the splashscreen window as a loading screen for the app letting the user know that something is happening while some parts of the app are loading (Checking and eventually managing local settings database for instance or required updates etc), we created a custom theme that is approaching one for one with our internal design system and the app design mockups, however, we do have a lot of users additionally to the design team that gives us feedback about the « Windows themed border ».
I know that such point can seems trivial for many developers, but for customers, it matter.
If everything was just about function, we would have ended with only one type and color of t-shirt/trousers/etc.
My vote goes with the comment that stated that the framework should let developers choose to use the function and just return a « NotImplemented/NotSupported » error on OSes that enforce such behaviors.
PS: Microsoft themselves are doing it with Office365 desktop clients.
Is this a comment about moving windows or requesting custom window borders?
In my opinion the latter can be incredibly painful like the Electron windows that cannot function until the content is fully loaded, and so many custom widgets in the bar you can't always figure out (or manage!) to drag them around. And of course inconsistent placement of standard components.
As you say MS do this, and Apple do for some apps to - but they have the unique ability to coordinate with evolving platform changes internally - whereas we are focused on platform portability and consistency.
Anyhow, it seems like this ticket is going off topic.
The use case explicitly is a multi window layout and remembering where those windows were on multiple monitors. Sure this is not necessary on mobile, because they operate completely differently, but if you want to actually be useful for real development on windows (and some linux that don't do tiling wm), you basically either support this, or just look really bad by comparison.
This is mostly for the ancillary commenters not the devs, but sure linux has window managers that manage position for you, but windows explicitly expects programs to do this, and pretending this isn't the case is just not helpful and near arguing in bad faith. If you want to go argue your design purity case go take it to Microsoft, but in the mean time, its better to implement to current system design, not the one you wish existed.
The use case explicitly is a multi window layout and remembering where those windows were on multiple monitors.
From that brief summary it sounds like a better solution is #554 instead of instead chasing a partial implementation that works on some OS and may go against user expectations.
If there truly is a use-case here then please expand on it - "multi-window layout" isn't particularly clear and the general concept has been fading from use steadily (see GIMP, Visual Studio and others that have moved all "palettes" into the single window).
I have an app that is is expected to be mostly run on windows, that uses multiple windows which need to be properly positioned and able to remember their positions on multiple monitors. Is your expectation that I just am forced to use a different api / graphics suite or python which has lots of good options that all support this because you don't like the approach since it can't be done on all platforms? Genuine question here.
User expectations are that apps work like this on windows. Like would you expect to have to rearrange chome windows every session? Would you even use chrome if it didn't when there are other options available that work correctly?
I'm not following. The "Remember window positions" feature request has been linked and we intend to implement this. But "arbitrarily position windows" is a different request - I cannot tell from your comments which you are asking for.
Would it be fair to assume that this issue is the reason that you stated the project is "MobileOnly" with the sentiment "unless it's a mobile thing, don't expect them to support it" @ikiris? https://www.reddit.com/r/golang/s/TOMyQeOtjQ
- I deleted my reddit account during the blackout
- I don't know how clearer to make it that both features are basic expected functionality in a windows application, but I am only commenting on this bug, since it can be used to implement the latter anyway.
My apologies - someone is using the same avatar as you with an almost identical username! Ah I see, you want both. OK. Can you be more specific about the details for /how/ the specific positioning of windows should be used? (i.e. relative to window, relative to screen, absolute in some other coordinate space).
It might seem pedantic but they could all have very different implementations, complexity or even feasibility. As you may or may not have realised everything about window placement relates to a complex coordinate system that is not exposed in any way through our APIs.
Ok that's creepy. Will look into that as I also frequent large streamer communities and rant there a bit, thank you for explaining.
Personally, I think the simplest solution I could use would be lay out multiple windows the first time they're used relative to the master window, and ideally place the master window either relative position (like upper left corner or something) in main monitor or current focus one, whichever y'all consider better as I see justifications for both. After that I only need to be able to recall location for a window if the monitor space it was in is still valid (and I'm totally fine if this is a behind the scenes flag or something and not an active position choice). I'm not sure what the other requesters wanted or what the best general solution would be otherwise. I would use a single pane window as suggested prior, but I do need the windows to be separable across multiple monitors and not tied to a single window geometry, so unless there is some dock / undock draggable functionality I'm missing, this seems like my best solution.
TLDR: I just care that I can lay out first time use more than anything for design / presentation purposes, and keep positions after that. Nothing annoys me more than discord being basically the only app I use that absolutely refuses to stay on the correct monitor.