This commit delegates the calculation for menu position into wlroots
utilities for xdg_positioner.
Notable functional changes are:
- Slide the menu to fit in the output when it's opened out of the output
(e.g. top-left window menu is opened when the window is overflowing to
the left), rather than not updating the menu at all.
- The horizontal alignment of menus is now determined based on the size of
each (sub)menu alone rather than the total width of entire menu tree.
This means submenus can now overlap with is parents, but this is no
longer a problem since we recently added support for menu borders.
- Fixed that pipemenus always follow the alignment of its parent even when
it overflows from the output.
Arrow signs are specific to submenu items, so they would be more natural
to be handled in menu.c rather than accepting "arrow" in
font_buffer_create().
Also I allowed non-positive numbers for max_width in font_buffer_create(),
in which case the natural font width is used as the buffer width.
- Don't store font/background buffers in menuitem struct since we no
longer dynamically update buffers of existing menuitems.
- Factor out the duplicated codes for creating menu item scenes for each
unselected/selected states.
I missed that `scaled_font_buffer_update()` has `max_width` argument and
the subsequent calls to `scaled_font_buffer_set_max_width()` caused
unnecessary re-renderings.
This fixes use-after-free when there's only 1 desktop and
menu_hide_submenu() is called to delete "Workspaces" submenu in
client-menu before menu scenes are initialized.
As menu_create() and item_create() no longer initialize scenes after
76515316, menu->scene_tree and item->tree should be null-checked.
The deleted lines were dead code that didn't make any sense (even if it
were not dead, it should have recreated the parent of the hidden menu
rather than the hidden menu itself).
Commit 7651531 introduced a regression: `menu_update_scene()` which
re-creates a menu scene was called for all the menus when a pipemenu is
created, so the menus (parent of the pipemenu) were always moved to (0,0)
and hidden, and the pipemenu was incorrectly positioned.
This commit fixes it by calling `menu_update_scene()` only for the
pipemenu when it's created.
This commit separates the process of creating scene-trees of the menu
items into `{item,separator,title}_create_scene()`. This will make it
easier to draw richer menu designs like borders, paddings and rounded
corners.
Before this commit, we assumed `ShowMenu` action is not bound to any
buttons other than window menu button and always place the client-menu
under the window-menu button when atCursor="no". Also, it was going to be
difficult to distinguish whether the action is executed from the window
menu button or the window icon, which will be added soon.
This commit fixes it to open the menu under the actually-clicked button by
passing `cursor_context` to `actions_run()`, with some refactoring:
- `seat->pressed.resize_edges` is removed and it's calculated from the
cursor position and `seat->pressed.type` just before running Resize
action. This slightly changes the existing logic to determine the
resizing edges with Alt-Right + Drag mousebinding, but
`seat->pressed.type` is still stored on button press so it doesn't bring
back the issue #543.
- `seat->pressed.toplevel` is removed and `get_toplevel()` in
`update_pressed_surface()` may be called more often, but its overhead
will be negligible.
Shows all workspaces that current view can be sent to.
Works best when added to Client menu.
<menu id="client-send-to-menu" label="Send to..." />
Menu uses ">" and "<" to highlight the current workspace
...defined by `<separator label="">`.
Also add the theme option `menu.title.bg.color: #589bda`
The following will be added in separate commits
- menu.title.bg.border.color: #7cb6ec
- menu.title.text.color: #ffffff
- menu.title.text.justify: center
...such as the one in the example below:
<?xml version="1.0" encoding="UTF-8"?>
<openbox_menu>
<menu id="root-menu" label="obmenu-generator" execute="obmenu-generator"/>
</openbox_menu>
We should consider supporting this construct in future.
Reported-by: cry0xen via IRC
Add a BUF_INIT macro, which makes it easier to initialize a struct buf
to an empty string (without a heap allocation).
Add buf_move() to move the contents of one struct buf to another (the
source is reset to BUF_INIT, analogous to C++ move-assignment).
Use buf_reset() instead of directly calling `free(s->buf)` since the
internal buf may not always be allocated by malloc() now.
After a roundabout discussion[1] with wlroots devs, it's become apparent
that subpixel text rendering (a.k.a. "ClearType") does not work properly
when rendering over a transparent background, as labwc currently does.
Basically it comes down to the fact that the color of semi-transparent
pixels (which is adjusted redder or bluer to compensate for RGB subpixel
alignment) depends somewhat on background color. When rendering over
transparency, the text engine doesn't know the intended background color
and can't adjust the pixel colors correctly.
With Pango/Cairo, the end result can range from grayscale rendering (no
subpixel rendering at all) to wrong/oversaturated colors (for example,
bright pink pixels when rendering white text on blue background).
This change solves the issue by first filling the text buffer with an
opaque background color before rendering the text over it. Currently,
this is easy since the background is always a solid color. It may be a
little more complex (but doable) if we implement gradients in future.
Note that GTK 4 (and to some degree, recent versions of Microsoft
Windows) avoid this issue by disabling subpixel rendering altogether. I
would much prefer that labwc NOT do this -- it results in noticeably
blurrier text on non-retina LCD screens, which are still common.
[1] https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3822
