Inspired by #5384, but instead of just using the border width, this PR
reports the actual frame extents for the window, which may also include
the title bar (for floating windows and tiled windows in plain split
containers, but not for tiled windows in stacked/tabbed containers).
The existing `con_border_style_rect()` function should already handle
all configuration options which can affect the decoration sizes (if it
does not, that would also show up in other places); its result just
needs to be converted into the format used by the `_NET_FRAME_EXTENTS`
property.
This PR fixes#4292 probably in the best way possible (the reported
`_NET_FRAME_EXTENTS` values should always match the actual sizes of
window frame elements which are actually drawn into the X11 frame window
into which the client window is reparented). The only really problematic
case is with the stacked/tabbed containers, for which the title bar is
actually drawn into a completely separate window, therefore the title
bar size cannot be reported in `_NET_FRAME_EXTENTS` (actually I tried to
calculate the size of those decorations and add it to the top decoration
size, but that did not change the behavior of `picom`).
<details><summary>Large screenshots here (3840×2160)</summary>
Example of configuration with `hide_edge_borders smart` — a single
window does not have borders, so only the top frame size is non-zero:
but multiple windows have borders:
Changing border width works too (although with `border normal 8` you can
see that the top border overlaps the title text, because on the i3 side
that border does not really exists, and `picom` just draws it over; also
the pixel sizes reported by `xprop` and `xwininfo` are not identical to
what is specified in i3, because I use 168 dpi on this system, therefore
4 px in the i3 config = 7 dpx):
Handling of tabbed containers is less perfect though. Here is a single
tabbed container with `hide_edge_borders smart`, so it does not really
have a border — note that all frame extents are zero, and the titlebar
is rounded separately (although it could easily be excluded from
rounding, that does not really help much):
Once the border actually appears, you may notice that the top part of
the `picom` border actually gets drawn over the top part of the window,
partially obscuring the top line in this terminal (`picom` does not mind
that the top frame size is reported as 0):
Some examples of floating windows (no major problems there):
Options like `hide_edge_borders both` work too when gaps are removed
(although the resulting behavior with `picom` is probably not very
useful — the rounded border gets drawn only if all of the left, bottom
and right borders are present):
The same with `border pixel 8` (note that windows with only the top
border hidden still get the rounded border treatment by `picom`, but the
border overlaps the top part of the window):
</details>
---------
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
Co-authored-by: Orestis Floros <orestisflo@gmail.com>
This was originally mentioned in #3085 but left for a future PR.
One of the noticeable limitations is that pressing the modifier while
the drag is already initiated, will not swap the containers but instead
cancel the drag. This is because of how `drag_pointer()` is written and
would be quite an involved case to handle it.
This had pretty much identical behaviour to hide_edge_borders which made
it confusing. The `hide_edge_borders smart_no_gaps` implementation has an extra check
which fixes#5406.
If a window occupies the entirety of its workspace vertically and/or horizontally, pass it the _NET_WM_STATE_MAXIMIZED_{HORZ, VERT} atoms. This helps applications like Google Chrome draw the tab bar correctly and handle tab clicks correctly (see https://crbug.com/1495853).
This change is based on work from @yshui in #2380.
Grabing the pointer produces a `GrabFrozen` error in applications that
are run from key bindings. Since we don't need the pointer in such
cases, we can change the call to use ASYNC. This seems to be a
historical leftover.
I've tested locally that these still work:
- bindsym $mod+x ...
- bindsym --release $mod+x ...
- bindsym $mod+button1 ...
- bindsym --release $mod+button1 ...
- bindsym --release $mod+x exec program that grabs the keyboard
now works (see original issue)
Even in the main branch, I actually couldn't get `import` and `xdotool`
to fail with the pointer being frozen, potentially because these
programs wait a bit for the pointer to be unfrozen like i3lock does.
This patch came up in
https://github.com/i3/i3/issues/5735#issuecomment-1781321011
I wonder why the pointer is actually grabbed.
The argument I change in `xcb_grab_key` there, is `pointer_mode`, from
https://www.x.org/releases/X11R7.7/doc/man/man3/xcb_grab_key.3.xhtml:
```
pointer_mode
One of the following values:
XCB_GRAB_MODE_SYNC
The state of the keyboard appears to freeze: No further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released.
XCB_GRAB_MODE_ASYNC
Keyboard event processing continues normally.
```
I traced via `git blame` the usage of `xcb_grab_key` throughout 14 years
of i3 development and it seems that `pointer_mode` was always set to
`XCB_GRAB_MODE_SYNC`, going all the way back to
b664456706.
Fixes#5735
This reverts commit 6b658f88be.
The commit was misguided: the pixel values are already run through logical_px()
when parsing the configuration directive or command, so they should not be run
through another logical_px() pass at rendering time.
This is the last remaining diff from the i3-gaps tree.
related to https://github.com/i3/i3/issues/3724
Tested using the following config with picom:
bar {
i3bar_command i3bar -t
status_command i3status
colors {
# fully transparent text on opaque background:
statusline #ffffff00
background #000000ff
}
}
Fixes#2643
Inner drop region behaves like move to mark.
The outer region is close to the edge (currently 30px from the edge).
This will place the container as a sibling in the given direction within
the parent container. If the move direction goes against the orientation
of the parent container, tree_move() is called.
Contributors:
Co-authored-by: Orestis Floros <orestisflo@gmail.com>
See #3085
- Inner drop region behaves like move to mark
- Handle workspaces
- Fix crash when target closes
- Initiate tiling drag from titlebar
- Hide indicator until container is dragged outside of original position
- Calculate outer_threshold using percentages instead of fixed pixel
values
- Emit 'move' event properly
- Don't focus previously unfocused containers
- Use tree_split() on different orientation
- Fix redundant split containers
- DT_PARENT
- Readability & optimizations
- Limit parent threshold by render_deco_height()
- Tests
- Fullscreen container handling
- Initiate drag from title bar
- Fix issue of EnterNotify events still triggering after drag_callback
is called
- Include decorations for drop target calculation
Co-authored-by: Michael Forster <email@michael-forster.de>
See #2178
- Original implementation of tiling drag + indicator window
> A container can be dragged by the title bar to one of the four sides
> of another container. That container will then be split either
> horizontally or vertically.
Co-authored-by: Tony Crisci <tony@dubstepdish.com>
See #2653
- Original implementation of outer/inner drop region indicator:
> There are two drop regions per direction.
>
> The inner region is closer to the center of the window. Dropping on
> this region will split the target container and put the container
> within the split at the given direction beside the target container.
>
> The outer region is close to the edge (currently 30px from the edge).
> This will place the container as a sibling in the given direction within
> the parent container.
>
> Dropping into the outer region moves the con beside the target. If the
> move direction goes against the orientation of the parent container, the
> con moves out of the row.
- Fix crash: Ignore containers without a managed window (eg i3bar)
