From raster at rasterman.com Sun Jun 1 09:08:56 2025 From: raster at rasterman.com (Carsten Haitzler) Date: Sun, 1 Jun 2025 10:08:56 +0100 Subject: Move a window In-Reply-To: References: <0BV4XS.IMRIIINRR4AU2@att.net> <20250531181433.e156d5007fe0fc150e32e07d@rasterman.com> Message-ID: <20250601100856.d3b092021c2405dda2b4e0fa@rasterman.com> On Sat, 31 May 2025 14:49:23 -0400 Steven J Abner said: > On Sat, May 31 2025 at 05:14:33 PM +0000, Carsten Haitzler > wrote: > > well you never said what you WANTED to achieve > > In my original post: > And on the 3 tested this 'grab' won't work. It has confines placed on > it from moving past edges or 'STRUT's where cursor gets separated from > drag point (mouse location). no confines there at all in your code for the grab nor any logic to even limit the position of the window. if you want to have a window behave like it does when a wm moves it - use the netwm moveresize reqeust stuff. the wm will then handle it. wm's will do much more than you can/will - like will enforce resistance, snapping, may switch virtual desktops when you drag to a all or some screen edges and more. you have no idea of all the policies the wm may apply/enforce when doing this (many are private to the wm and there is no way for you to know), so you are best off leaving this to the wm whenever possible. another example - while moving a window you can use a keybinding to switch desktops - the wm knows to keep the window that is moving where it is and switch desktop moving all the other windows but this one - then release mouse and presto - window moved to a new desktop. you won't ever manage any of this doing moves yourself. i can write a pretty long list of all the behaviour stuff that breaks doing what you are doing. you can have a very primitive fallback when the wm doesn't support this and your code has it and it does work (but no confining/limits like you say). this is a fallback for older wm's that may not support the netwm moveresize, but then you wont see any strut property info either as most likely because the wm won't advertise this because it's likely old (or it just doesn't have any such ui content). > So I trying to move a window within the confines of the display or > displays, not 10, 20 or xx number of pixels from the edge. To get well you code has no such logic to do this. you'd have to figure out your client window location relative to root. you'd also have to account for xinerama or xrandr screen locations. for example enlightenment will make every visible screen (be it implemented by xrandr or xinerama) a separate screen and each can switch desktops separately (switching desktop on 1 screen using keybindings, edge resistance, pager etc. will not change the other screens and what desktops they show). you need to handle screen setups with different resolutions where some areas of the root window are inaccessible because it's out of bounds of any screen you need to possibly look at netwm desktop geometry an workarea too if provided. enlightenment doesn't expose any strut or workarea info because it's shelves can use partial areas and the rest is free for use. this is dynamic and can change at any moment as well, so there is little value in exposing info that is at best a coarse approximation of what is there. (e's shelves can be a smaller box centered at the bottom or stuffed into a corner ... and you can have as many of these along and screen edge as you like - thus multiple regions across each screen edge of differing locations and sizes - the netwm standards are too limited). you also need to work out the frame extents of your window - you can walk back up the window tree and guess or use netwm properties for this too that tell you the size of frames beyond your client window and account for thee as the user visible border is beyond your window. > window manager to understand the values passed to them or use them. To > get the window to follow the pointer. Problem is creating an > application and not knowing all tool kits and languages to move a > window. It's kinda like using Alt+button, Super+button, or > other-combos+button on different flavors to move a window other than > the titlebar. I was forced to use this because one said it supported > _NET_WM_MOVERESIZE but clearly didn't. Which lead to starting with the > basics, Xorg bare, and twm. you should have reported a bug to that wm. it may also be that the wm supports it and allows a user policy to disable it and not allow it. this is perfectly allowed for wm's to just ignore you or say no based on policy. > Issue a XMoveWindow() or xcb_configure_window() and find out as I > luckily did, that your application had its window stop 10 pixels from > edge with pointer 200 pixels from grab location, yet works 100% of the > time on the 3 distributions tested and designed on. if its a managed window the wm can ALSO enforce things like limiting the position (and size) of a window. users regularly complain of badly behaving apps that go move their own windows partially off screen. or make windows 4x bigger than the screen and the user can't access all the window. some wm's will limit this - enlightenment for example will limit windows INITIAL location tot he visible area - but will allow them to move themselves later... unless the user applies locks. locks allow the wm to lock tyhe app out of moving its own window. i do this to various apps that misbehave. especially my web browser - years of badly behaving web page javascript to go move + resize the window around thinking it knows better had me add this feature. locks also can be remembered across invocations so keep being reapplied. in this case e will just ignore any configure requests that move or resize the window (or both). so some wm's may limit your requested moves to the screen bounds or even a lesser area. some may not. some may limit you in some conditions and not others. they may limit you based on explicit user request to do so. you have no control over this. that's the job of a window manager - to apply limits and controls and policy. > Is there a property I'm not defining to get window managers to > understand what Xorg clearly does? XMoveWindow() or > xcb_configure_window() is clearly defined! You move the window. > And even though they use these, how do I tell them to use these? What > am I missing? no - you're likely running into wm poliocy to just not allow your window to move where it wants to and it's 3enforcing it. enlightenment allows you to move your window where you want after it has been mapped/shown unless i apply locks. it will only apply limits on initial map/show. other wm;'s may always enforce that limit at all times so you can never move (or resize) your window beyond the geometry the wm has decreed as what it allows. > Sorry if original post sounded as complaint or wasn't as succinct as I > thought. > Steve i saw no limits to grabs or any code you implement to limit anything so i ignored that bit. now you've explained more see above. welcome to wm policy. the solution is... use netwm moveresize :) let the wm take care of it. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - raster at rasterman.com