Move a window

[Carsten Haitzler]

On Sat, 31 May 2025 14:49:23 -0400 Steven J Abner <pheonix.sja at att.net> said:

> On Sat, May 31 2025 at 05:14:33 PM +0000, Carsten Haitzler 
> <raster at rasterman.com> 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