I like the new common/edge.h. I don't like how inconsistently we use it.
Current situation:
- enum wlr_edges and wlr_direction are designed to be used as bitset,
and are defined compatibly
- enum lab_edge is *also* designed to be used as bitset, but
incompatible with the others (LEFT/RIGHT come before UP/DOWN)
- we use an inconsistent mix of all three *AND* uint32_t (usually with
the WLR_EDGE constants rather than the LAB_EDGE constants), and
convert between them on an ad-hoc basis, sometimes implicitly
Let's clean this up:
- reorder enum lab_edge to be compatible with the two wlr enums
(check this by static_assert)
- use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges)
- add constants for the remaining possible combinations of the 4 edges
- use lab_edge for all internal edge/direction fields, consistently
- add lab_edge_is_cardinal() as a sanity check before casting to
enum wlr_direction, and then eliminate all of direction.c/h
Instead of "enum wlr_edges direction", we now have
"enum lab_edge direction" which is not that much better. At least we
are now clear that we're overloading one enum with two meanings.
This is a common practice in C projects, which simply enforces that
each header must compile cleanly without implicit dependencies on
other headers (see also the previous commit).
Only Vertical and SplitVertical gradients are supported,
and only for window.*.title.bg.
Not supported at this time:
- horizontal or diagonal gradients
- gradients for window.*.label.bg, buttons, or menus
- any type of border (raised, sunken, etc.)
This allows users to make the icon in window switcher bigger (or smaller)
than the font size, which enables more Openbox-like appearance.
Example configuration:
osd.window-switcher.item.icon.size: 50
This commit also makes the icon smaller than the font size if the width
allocated with <windowSwitcher><fields><field width=""> is smaller than
that.
Eliminate corner extents and instead use cursor position to map SSD
borders and extents to corner contexts, with a size configurable by the
<resize><cornerRange> parameter. This simplifies extent handling,
eliminates bugs in the detection of corner context, and allows users to
expand corner targets if they wish.
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
as well as 'openbox-3', for example: /usr/share/themes/foo/labwc/themerc
Give 'labwc' higher precedence than 'openbox-3' if both exist.
For several reasons not all themes designed for labwc render well on
Openbox:
1. Labwc support some features like SVG/PNG icons and #rrggbbaa color
definitions which Openbox does not.
2. Openbox generally defaults to black/white colors and will not render
themes accurate without certain options specified in themerc. For
example, in Openbox the following will just render as black:
window.active.title.bg.color: #589bda
...because Openbox defaults the texture to "Gradient Vertical" and
therefore either needs:
window.active.title.bg.colorTo: #3c7cb7
...or remove 'Gradient' from the bg definition and just use something
like:
window.active.title.bg: Flat Border
Whilst none of this is a problem when using labwc, it causes problems for
setups with both Openbox and labwc because themes designed for labwc only
will now show up in obconf, lxappearance, etc causing confusion for users.
lab_img.theme member was referenced by "modifier" functions when drawing a
hover effect on button buffers or rounding the button buffer for corner
buttons, but this can be prone to use-after-free and was not very clean
because theme and lab_img were referencing each other.
Instead, let's just reference rc.theme in the modifier functions and
remove theme from lab_img.
...from WLR_ERROR to WLR_INFO to avoid 'false' logging when Openbox themes
contain the padding.height settings. Whilst this option is not supported,
the visual appearance is very close to that of Openbox with common themes.
The background to this is that Labwc theme specification has diverged
slightly from that of Openbox with respect to titlebar padding to support
more contemporary looks whilst avoiding breaking changes. For full details
see commit: e16e78e7a4
Suggested-by: @Consolatis
- fix that icons for normal/hovered/rounded buttons are not placed
exactly the same position
- fix blurry window button icons in scaled outputs
This commit introduces lab_img and scaled_img_buffer and uses them for
rendering icons in the window titlebar. Now the process of rendering
button icons are split into 2 phases: loading with lab_img_load() and
creating scene-nodes for them with scaled_img_buffer_create(). This
might incur some additional overhead since we no longer preload icon
textures, but the rendering of icon only happens for the first window
as backing buffers are shared and the overhead won't be noticeable.
This commit also simplifies the process of centering icon buffer in the
button, by creating icon buffers in a fixed geometry via
lab_img_render().
It was a cruft from my experiment of adding borders around titles.
It even caused an integer overflow because theme->menu_border_width can be
INT_MIN when menu_header_height is calculated.
This makes the colors of titlebar and window borders different, but will
let menu.border.color (which will be supported soon) inherit
window.active.border.color just like Openbox does, without making the menu
borders around a selected menu item invisible.
For example, variables:
`theme->window_inactive_border_color`
`theme->window_active_border_color`
are converted to:
`theme->window[THEME_INACTIVE].border_color`
`theme->window[THEME_ACTIVE].border_color`
The iterator value of `wl_list_for_each` should never be referenced
outside the loop because it points to invalid memory location when the
list is empty.
The rounded mask buffer to be applied to the corner button buffer should
be resized and shifted when there's a vertical gap between the button
and the window border.
...to replace padding.{width,height} to minimize breaking changes with the
visual appearance of the titlebar.
With the diverging labwc specification for the titlebar (listed below)
we have to choose between (a) not supporting the padding.{width,height}
option which exist in many extant Openbox themes to keep titlebar height
(almost) the same; or (b) making the allocated button areas much smaller
and not keeping the default hover going all the way to the edges. All in
all it just seems a lot simpler and cleaner to break this link to the
openbox spec.
Examples of previous change driving the requirement for this change:
- SVG and PNG support which often results in large icons with hover
effects.
- Theme option window.button.{height,width}
- Larger default areas for icons (26x26)
In way of an example, Numix theme sets a padding.height of 6 which would
have resulted in a titlebar 12px taller without this change.
...because now that window.button.height determines the height of button
hover effect the visible appearance of the titlebar will change unless
we reduce the padding to zero.
Backward compatibility notice: If a users theme sets padding.height to a
value greater than zero, the titlebar will be taller compared with
openbox. This can be fixed by either reducing window.button.height or
overriding padding.height
This theme setting does not exist in Openbox spec and has just been an
additional 'knob' to tweak the height which is otherwise derived from the
sizes of the objects within it plus padding.
window.button.{height,width} determine the space allocated for buttons.
Buttons can be smaller than this size and will then just be center aligned
within the allocated space. However, buttons will be clamped at this size
to prevent them from going outside of the allocated space.
- Add a new function to get the maximum scale of all usable outputs
- Pass the maximum output scale through to img_svg_load(), which
ultimately calls cairo_surface_set_device_scale() before rendering
Add buffer_adopt_cairo_surface(), which allows wrapping an existing
cairo image surface in a struct lab_data_buffer. This is useful when
loading PNGs since most will be loaded as ARGB32 already.
Fix a memory leak in the non-ARGB32 PNG case, where we do still need to
paint to a new image surface -- we were leaking the original surface.
Eliminate an unnecessary temporary image surface in SVG loading and just
render the SVG to the image surface held by the lab_data_buffer.
I also cleaned up and clarified the buffer API a bit:
- Add a pointer to the held cairo_surface_t (so we can still access it
if there is no cairo_t).
- Remove the free_on_destroy bool (it was always true).
- Rename unscaled_width/height to logical_width/height and add an
explanatory comment. It was unclear what "unscaled" meant.
- Rename buffer_create_wrap() to buffer_create_from_data().
This is laying groundwork for some more icon fixes I am working on
(making sure icons are loaded and rendered at the correct scale).
- The builtin hover effect is now unrounded when the window is tiled.
- All the corner button icons including ones provided by the user are
now rounded when the window is not tiled.
- Fixed the bug that the window menu button as a fallback of the window
icon is not correctly rounded.
The hover icon buffer on which the hover overlay is draw can be larger
than the button size when a large non-hover icon is provided by user. In
this case, we should scale up all the coorinates that are used to draw
the hover overlay. Before this commit, corner radius and padding.width
are not scaled correctly.
This commit fixes it by scaling the cairo context with cairo_scale()
when drawing the hover overlay.
The default `titleLayout` is updated to `icon:iconify,max,close` which
replaces the window menu button with the window icon.
When the icon file is not found or could not be loaded, the window menu
icon as before is shown.
The icon theme can be selected with `<theme><icon>`.
This commit adds libsfdo as an optional dependency. `-Dicon=disabled` can
be passsed to `meson setup` command in order to disable window icon, in
which case the window icon is always replaced with a window menu button.
