On Wed, 1 May 2024 09:35:30 +0200 (CEST) Jan Engelhardt <jeng...@inai.de> said:
> > On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote: > >> > >> Although gambas provides a Settings.Write(window_name) / > >> Settings.Read(window_name) that saves/restores the window placement and > >> size. It's bearable Wayland does not handle this. > > > >YOU should never be handling this. It's like saying "I'm used to having to > >hand-crank my car's motor for it to start... why can't I keep doing that?". > > In keeping with the car analogy: one *can* handcrank the motor, one just > needs a vehicle that implements *that*, so like youtu.be/4SZExEgLT_0 or, > indeed, running gambas on an X11 interface (xorg-server, Xnest, > Xwayland...) > > >If all you do is the above, you've barely scratched the surface of > >"remembering my window". Things you don't handle above: > > > >1. Stacking remembering (relative to other things you may know nothing about > >like someoene else's windows) > > I do not think anybody seriously uses overlaps, because searching > in stacks (Alt-Tab or whatever method) is kinda inefficient. People > either go big screen, workspaces/virtual desktops, or (say) temporarily > exiting/suspending an editor to run the compiler. In the case mentioned here these "desktop gadgets" once you resize/scale the screen if you then scale the sizes/coords and deal with minimum surface sizes you may end up with overlaps between multiple process gadget windows (Each gadget is 1 window for 1 client/app) and the compositor can solve this by guessing they are aligned in a row and "line the up again". Apps can't do this - they don't know the other windows even exist. This also can happen with regular windows. I actually often tile my windows by hand (it's easy in E due to window resistance making it a doddle). If i e.g. switched from 3840x1440 to a 2560x144 monitor - I'd not rescale but I'd have to re-position and re-size as I had not adjusted scaling but adjusted screen aspect ratio. Each terminal of the set of 15 I have is a different window and process. Admittedly E doesn't quite realize it is a perfect grid. It's policy on such screen resizes is to remember window positions based on nearest screen anchor (top-left, top-middle, top-right, left-middle, center, right-middle, bottom-left, bottom-middle, bottom-right). This handles going up in size nicely. Down leaves some manual fiddling still but may lead to overlaps. Something I probably can fix for sure. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com
