[DONE] RFT: bl-aerosnap

nobody · 2016-09-03 10:58:03

xaos52 wrote:

@Unia,
Conc the crash with negative offsets:
The error occurs when the library converts the x coordinate to an unsigned int, realizes that it loses information, and crashes.
This may be intended behaviour, to protect the user from the window-manager placing a window in a position where it may not be reachable in any way by the user.
Just an 'educated guess', really.
EDIT:
See source code for libxcb-ewmh2:
/**
 * _NET_MOVERESIZE_WINDOW
 */

/* x, y, width, height may be equal to -1 */
xcb_void_cookie_t
xcb_ewmh_request_moveresize_window(xcb_ewmh_connection_t *ewmh, int screen_nbr,
                                   xcb_window_t moveresize_window,
                                   xcb_gravity_t gravity,
                                   xcb_ewmh_client_source_type_t source_indication,
                                   xcb_ewmh_moveresize_window_opt_flags_t flags,
                                   uint32_t x, uint32_t y,
                                   uint32_t width, uint32_t height)
x, y, width, height are unsigned ints.

If you convert -1 to unsigned int in C, you get UINT_MAX as it'll just overflow. So the comment in the source you quoted can have two meanings: a) -1 is just a way to place a window of maximum width, maximum height at the largest (x, y) offset possible or b) have some special meaning defined by implementation at some other place. So it shouldn't crash because of UINT_MAX/-x arguments, as that is within the allowed value range however you put it.

Unia · 2016-09-04 11:11:14

ohnonot wrote:

re TEST2:
Unia wrote:
What behavior did you notice? If the window first snapped to the left, then to the right and then back to its original position before being snapped to the left, it works.
i did another pull, but the behavior is exactly the same as yesterday: it says "not snapping to the left", it quickly snaps to the left, then to the right, and does not return to its original position.

Can I get more details of your setup? Xorg version, Python version, Openbox version, basically every component involved. Screenshots or a video/gif would help, too, if possible.

ok, but does it matter if the values leave plenty of space? does it have to be pixel-precise? my titlebar is higher than 10px + borders, it is not possible to have a precise value when changing openbox themes.

What do you mean with leave plenty of space? The values indicate, in order of appearance, the x and y coordinates and the width and height of the window when it is snapped to the left. These values should not leave any space, as the window (when snapped) should occupy the maximum space possible. These values have to be pixel precise. Whatever your titlebar height is, does not matter. Just grep the values using the command I gave, do the math and edit the script accordingly. Here's a rundown of how it would work for my setup:

1. Open a terminal from which the tests will be run;
2. Run `xprop | grep _NET_FRAME_EXTENTS` and select the terminal window. For me, the output is:

 > xprop | grep _NET_FRAME_EXTENTS
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 20, 5

3. Take note of the values, the format being: left border, right border, top border, bottom border.
4. Open the test script, and do the math as I pointed out in my previous post:

FRAME_LEFT = 1
FRAME_RIGHT = 1
FRAME_TOP = 20
FRAME_BOTTOM = 5
USABLE_HEIGHT = 768 - 30 - 0 = 738 (monitor height - horizontal panels' heights - horizontal openbox margins)
USABLE_WIDTH = 1366 - 0 - 0  = 1366 (monitor width - vertical panels' heights - vertical openbox margins)

SNAP_HEIGHT = USABLE_HEIGHT - FRAME_TOP - FRAME_BOTTOM = 738 - 20 - 5 = 713
SNAP_WIDTH = USABLE_WIDTH / 2 - FRAME_LEFT - FRAME_RIGHT = 1366 / 2 - 1 - 1 = 681

Result: 0 0 SNAP_WIDTH SNAP_HEIGHT = 0 0 681 713

Note that these calculations are only important for the test script! You need not redo this when switching themes to ensure the script works as intended!

btw, i don't like the 1px margin so much, is this configurable?

Where do you get a 1px margin from? Note that no values whatsoever are hardcoded in the script!

[ ps, not so important: testing (on arch, and providing dash is installed) is quicker & smoother if you replace the headers in the test scripts from "#!/usr/bin/env sh" to "#!/usr/bin/env dash" ]

Or you just link sh to dash Not everyone will have dash installed!

@xaos52, thanks for looking into the issue, but all this was familiar to me already. I wonder why unsigned ints are enforced, as XLib does allow one to drag windows off-screen into negative coordinates (just try it in Openbox and other window managers, see also XMoveResizeWindow). Your educated guess makes sense to me, it seems as if xcb (and perhaps therefore python-xlib) enforce unsigned integers.

I guess a 'solution' to this would be to restore negative coordinates to zero values, possibly printing a warning to the user when it occurs. Thoughts?

Unia · 2016-09-04 21:32:51

Unia wrote:

I guess a 'solution' to this would be to restore negative coordinates to zero values, possibly printing a warning to the user when it occurs. Thoughts?

This is now implemented.

Bearded_Blunder · 2016-09-06 11:13:53

Is this something I'm going to have to disable the same way I have to visit HKCU/Control Panel/Desktop/WindowArrangementActive and set it to 0 in all my Windows installs? In windows it's one of the most annoying features added, rivals UAC for getting in the way.

damo · 2016-09-06 13:32:01

Bearded_Blunder wrote:

Is this something I'm going to have to disable the same way I have to visit HKCU/Control Panel/Desktop/WindowArrangementActive and set it to 0 in all my Windows installs? In windows it's one of the most annoying features added, rivals UAC for getting in the way.

It is a keybind-driven script for placing windows. If you don't want to use it you don't have to.

#! had cb-aerosnap - did that get in your way?

Bearded_Blunder · 2016-09-06 15:58:55

/me looks relieved
Nope, didn't notice its existence in #!, being keybinds, only time I'd try using it is if my mouse broke.

ohnonot · 2016-09-06 18:06:25

Unia wrote:

Can I get more details of your setup? Xorg version, Python version, Openbox version, basically every component involved. Screenshots or a video/gif would help, too, if possible.
1. Open a terminal from which the tests will be run;
2. Run `xprop | grep _NET_FRAME_EXTENTS` and select the terminal window. For me, the output is:
 > xprop | grep _NET_FRAME_EXTENTS
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 20, 5
3. Take note of the values, the format being: left border, right border, top border, bottom border.
4. Open the test script, and do the math as I pointed out in my previous post:
FRAME_LEFT = 1
FRAME_RIGHT = 1
FRAME_TOP = 20
FRAME_BOTTOM = 5
USABLE_HEIGHT = 768 - 30 - 0 = 738 (monitor height - horizontal panels' heights - horizontal openbox margins)
USABLE_WIDTH = 1366 - 0 - 0  = 1366 (monitor width - vertical panels' heights - vertical openbox margins)

SNAP_HEIGHT = USABLE_HEIGHT - FRAME_TOP - FRAME_BOTTOM = 738 - 20 - 5 = 713
SNAP_WIDTH = USABLE_WIDTH / 2 - FRAME_LEFT - FRAME_RIGHT = 1366 / 2 - 1 - 1 = 681

Result: 0 0 SNAP_WIDTH SNAP_HEIGHT = 0 0 681 713
btw, i don't like the 1px margin so much, is this configurable?
Where do you get a 1px margin from? Note that no values whatsoever are hardcoded in the script!

ok, in order of request:

~ $ pacs xorg-server|grep -m1 installed
extra/xorg-server 1.18.4-1 (xorg) [installed]
~ $ python --version
Python 3.5.2
~ $ openbox --version
Openbox 3.6.1

my screen is 1680x1050, tint2 panel is 30px bottom, and

xprop | grep _NET_FRAME_EXTENTS
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 24, 2

which leads to these values:

if [ "$RIGHT" != "0 0 836 994" ]; then

note: i'm using urxvt, not terminator. urxvt honors resize increments, which might explain some erratic behavior, e.g. the 1px margin on the right side.

Last edited by ohnonot (2021-07-03 09:52:15)

Unia · 2016-09-10 20:38:16

ohnonot wrote:

ok, in order of request:

~ $ pacs xorg-server|grep -m1 installed
extra/xorg-server 1.18.4-1 (xorg) [installed]
~ $ python --version
Python 3.5.2
~ $ openbox --version
Openbox 3.6.1

This is the same for me, so that's not the issue.

ohnonot wrote:

my screen is 1680x1050, tint2 panel is 30px bottom, and
xprop | grep _NET_FRAME_EXTENTS
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 24, 2
which leads to these values:
if [ "$RIGHT" != "0 0 836 994" ]; then

These values are wrong. Your width should be (1680 - 2 - 2) / 2 = 838, not 836.

ohnonot wrote:

note: i'm using urxvt, not terminator. urxvt honors resize increments, which might explain some erratic behavior, e.g. the 1px margin on the right side.

I can't seem to find an option for urxvt to disable this behavior. Could you perhaps test this with a terminal that allows arbitrary sizes, such as termite with size_hints = false in the configuration file?

ohnonot · 2016-09-12 07:01:48

Unia wrote:

These values are wrong. Your width should be (1680 - 2 - 2) / 2 = 838, not 836.

oops! fixed.
:8

I can't seem to find an option for urxvt to disable this behavior. Could you perhaps test this with a terminal that allows arbitrary sizes, such as termite with size_hints = false in the configuration file?

no, urxvt does not have this options.
patches exist, but i will try another terminal.
i tried with roxterm-gtk2 and sakura-gtk2, and the behavior with the bl-script-2 is identical (not returning to original pos, 1 px gap).
i don't know if they honor resize increments or not.
i tried with termite, uncommenting size_hints = false in ~/.config/termite/config, and this is what happens:
it flashes quickly, says "not snapping from the left", stays snapped to the right, does not return to its orig. pos.
but htere is no 1px border!

Unia · 2016-09-13 10:15:25

Strange behavior you describe ohnonot, even more so because it seems you are the only one.

@all,

I'm trying to find some time here and there to work on multimonitor support (university has started again), so it may take a while for this to land.

ohnonot · 2016-09-14 05:47:28

Unia wrote:

ohnonot wrote:
my screen is 1680x1050, tint2 panel is 30px bottom, and
xprop | grep _NET_FRAME_EXTENTS
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 24, 2
which leads to these values:
if [ "$RIGHT" != "0 0 836 994" ]; then
These values are wrong. Your width should be (1680 - 2 - 2) / 2 = 838, not 836.

sorry but i was right; it should be (1680 / 2) - 2 - 2 = 836, not 838.

changing this back, bl-aerosnap-test-2.sh now works with termite, but still not with roxterm-gtk2 and sakura-gtk2.

since, thanks to you, i'm now a user of gtk3 (only joking, of course i'll purge it soon) i also tried the gtk3-based version of roxterm. that works as expected (resize increments are NOT honored; i wonder if that's another of those gtk3 things...).

Unia · 2016-09-14 10:32:18

ohnonot wrote:

sorry but i was right; it should be (1680 / 2) - 2 - 2 = 836, not 838.

Yes, of course. Sorry for causing confusion. Great to hear that it now works! That means that I'll only have to work on multimonitor support from now

I guess that marks the end of this request for testing; I'll make a new thread for people to test multimonitor snapping.

ohnonot · 2016-09-14 16:54:54

does this mean it will also work reliably with urxvt?
or does it mean that you consider that an esoteric case?

bl-aerosnap-test-2.sh is only for testing, and bl-aerosnap itself seems to be working even for those terminal emulators that honor resize increments?

Unia · 2016-09-14 20:16:06

ohnonot wrote:

does this mean it will also work reliably with urxvt?

bl-aerosnap simply tells the window "move here, and resize to this size". If the window does not want to obey these hints, it is not bl-aerosnaps fault. urxvt will still move and resize, but it won't resize pixel-perfect and will therefore probably leave gaps.

ohnonot wrote:

or does it mean that you consider that an esoteric case?

I (or, rather, bl-aerosnap) does not do anything different here. As I said, it is those applications that do not listen to the hints that are to blame for esoteric behavior.

ohnonot wrote:

bl-aerosnap-test-2.sh is only for testing, and bl-aerosnap itself seems to be working even for those terminal emulators that honor resize increments?

The test script only compares values to see if the snapping works as it should, pixel-perfect. If you have no problems with urxvt leaving small gaps here and there, bl-aerosnap works just fine for you. Its behavior does not change because of the test script.

ohnonot · 2016-09-15 05:46:55

Unia wrote:

bl-aerosnap simply tells the window "move here, and resize to this size".

openbox can do that all by itself (*).
the magic of bl-aerosnap is in the ability to restore to original position, and that was what my question is about: do you think urxvt's (and other's) resize increments could break the functionality of restoring window size and position, or is bl-aerosnap ok with that?

============================

(*)
<keybind key="C-W-A-Left">
<action name="UnmaximizeFull"/>
<action name="MaximizeVert"/>
<action name="MoveResizeTo">
<width>50%</width>
</action>
<action name="MoveToEdge">
<direction>west</direction>
</action>
</keybind>

Unia · 2016-09-15 09:33:56

ohnonot wrote:

do you think urxvt's (and other's) resize increments could break the functionality of restoring window size and position, or is bl-aerosnap ok with that?

I don't see how resize increments should interfere with bl-aerosnap's (or any X client's) ability to ask for the window coordinates and size.

johnraff · 2016-10-14 01:09:22

@Unia, if the new bl-aerosnap is ready, would you like to merge it into the deuterium branch of bunsen-utilities? It would be a shame for all your work to be lost in some corner of cyberspace...

PS the same for bl-hotcorners?

Unia · 2016-10-14 07:07:38

It's not yet ready, but I do not have time to continue development right now.

johnraff · 2016-10-14 07:14:27

No problem. "When it's ready."

#21 2016-09-03 10:58:03

Re: [DONE] RFT: bl-aerosnap

#22 2016-09-04 11:11:14

Re: [DONE] RFT: bl-aerosnap

#23 2016-09-04 21:32:51

Re: [DONE] RFT: bl-aerosnap

#24 2016-09-06 11:13:53

Re: [DONE] RFT: bl-aerosnap

#25 2016-09-06 13:32:01

Re: [DONE] RFT: bl-aerosnap

#26 2016-09-06 15:58:55

Re: [DONE] RFT: bl-aerosnap

#27 2016-09-06 18:06:25

Re: [DONE] RFT: bl-aerosnap

#28 2016-09-10 20:38:16

Re: [DONE] RFT: bl-aerosnap

#29 2016-09-12 07:01:48

Re: [DONE] RFT: bl-aerosnap

#30 2016-09-13 10:15:25

Re: [DONE] RFT: bl-aerosnap

#31 2016-09-14 05:47:28

Re: [DONE] RFT: bl-aerosnap

#32 2016-09-14 10:32:18

Re: [DONE] RFT: bl-aerosnap

#33 2016-09-14 16:54:54

Re: [DONE] RFT: bl-aerosnap

#34 2016-09-14 20:16:06

Re: [DONE] RFT: bl-aerosnap

#35 2016-09-15 05:46:55

Re: [DONE] RFT: bl-aerosnap

#36 2016-09-15 09:33:56

Re: [DONE] RFT: bl-aerosnap

#37 2016-10-14 01:09:22

Re: [DONE] RFT: bl-aerosnap

#38 2016-10-14 07:07:38

Re: [DONE] RFT: bl-aerosnap

#39 2016-10-14 07:14:27

Re: [DONE] RFT: bl-aerosnap

Board footer