[racket-users] Re: window on-move / move inconsistency: is this a bug?
Yes, when I put on my pragmatic thinking hat, I certainly agree with you. But it also makes me think about whether I should create a utility library which does a more abstracted window placement and restoring. That library would care more about logical "human" positioning and for example snap to screens and possibly use platform specific code like you suggested. Currently such a library seems to be nice to have, but not that urgent to me. On the other hand when I play devil's advocate I think racket/gui is a cross-platform gui library and should have a highlevel api where these platform specific quirks don't leak through. I am unsure what is most reasonable and the better approach, I guess changing the move behavior might be difficult because of backwards compatibility, so the utility library might be the way to go. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/49c69439-2590-4429-ae58-b7edd18b6898%40googlegroups.com.
[racket-users] Re: window on-move / move inconsistency: is this a bug?
On Monday, December 2, 2019 at 12:58:39 AM UTC+8, Simon Schlee wrote: > > created an issue for this: > https://github.com/racket/gui/issues/149 > Based on you description, it seems that the window manager you use on Linux will adjust the window position to make room for the border, but this seems to be specific to the window manager itself. It is not necessarily a bug that `on-move` is called multiple times and not always in response to calling the `frame%/move` method (for example, it will be called when the windows is dragged with the mouse). This does not seem like a Racket GUI problem to me: I think that if you wrote a GTK application in C, the behavior would be the same. Also the windows platform is not without its quirks in this regard: if you use `frame%/move` to move the window to 0,0, you'll notice that the top menu bar is lined up with the top of the screen, but there is an 8 pixel gap on the left. This is because, while only a 1 pixel border is drawn around the window, there are an extra 8 pixels of invisible border, so the user can find the resize handle for the window. Visually, moving a window to 0,0 will not move it to the top-left corner of the screen. On Windows, there are API calls you can access using FFI, which allow calculating the window border to adjust for it. I suspect there are similar APIs on Linux for GTK. Alex. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/721a6840-e164-4b30-b4e7-707c3af37cde%40googlegroups.com.
[racket-users] Re: window on-move / move inconsistency: is this a bug?
created an issue for this: https://github.com/racket/gui/issues/149 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6cfb6e25-81fb-40f3-8da0-973c4bfc45f4%40googlegroups.com.
