libhandy issueshttps://source.puri.sm/Librem5/libhandy/-/issues2020-05-20T17:08:27Zhttps://source.puri.sm/Librem5/libhandy/-/issues/275Hdy.Deck: A method to get the previous child2020-05-20T17:08:27ZDaniel ForeHdy.Deck: A method to get the previous childOftentimes I have a deck where I'm navigating using a back button that should have the name of the previous page. For example, I'm in System Settings on the "Mouse & Touchpad" page and there is a back button that should say "Bluetooth" s...Oftentimes I have a deck where I'm navigating using a back button that should have the name of the previous page. For example, I'm in System Settings on the "Mouse & Touchpad" page and there is a back button that should say "Bluetooth" since that's where I just came from.
It would be convenient to be able to easily get the "previous" child in the deck so that I could use its properties for my navigation button. Something like:
`Gtk.Widget Hdy.Deck.get_previous_child ()`https://source.puri.sm/Librem5/libhandy/-/issues/274Hdy.Headerbar doesn't render box-shadow2020-05-20T19:23:42ZDaniel ForeHdy.Headerbar doesn't render box-shadowWith `Hdy.HeaderBar`:
![Screenshot_from_2020-05-20_09.16.15_2x](/uploads/fb76fcc1f9af710df64ac5886e73d678/Screenshot_from_2020-05-20_09.16.15_2x.png)
With `Gtk.HeaderBar`:
![Screenshot_from_2020-05-20_09.18.11_2x](/uploads/15aa7edbfc09f...With `Hdy.HeaderBar`:
![Screenshot_from_2020-05-20_09.16.15_2x](/uploads/fb76fcc1f9af710df64ac5886e73d678/Screenshot_from_2020-05-20_09.16.15_2x.png)
With `Gtk.HeaderBar`:
![Screenshot_from_2020-05-20_09.18.11_2x](/uploads/15aa7edbfc09fce193baa0f722b10d1f/Screenshot_from_2020-05-20_09.18.11_2x.png)https://source.puri.sm/Librem5/libhandy/-/issues/273Unable to override border radius on Hdy.Window2020-05-20T11:12:10ZDaniel ForeUnable to override border radius on Hdy.Window# What problem did you encounter?
When adding support for `Hdy.Window` (`window.unified decoration`) to the elementary stylesheet, I am unable to override the built in 8px border radius
## In what part of libhandy did you experience th...# What problem did you encounter?
When adding support for `Hdy.Window` (`window.unified decoration`) to the elementary stylesheet, I am unable to override the built in 8px border radius
## In what part of libhandy did you experience the problem? Note that multiple boxes may be checked.
HdyWindow
## What is the actual behaviour?
The border radius property is derived from shared.css
## What is the expected behaviour?
The border radius property is derived from the system stylesheet
## How to reproduce?
Use [this branch](https://github.com/elementary/stylesheet/pull/706) of the elementary stylesheet with an app that uses HdyWindow
# Which version did you encounter the bug in?
I compiled myself from commit `b61eefde06040703026f49a0b979588e69f77d3a`https://source.puri.sm/Librem5/libhandy/-/issues/272Allow to have subpages in HdyPreferenceWindow2020-05-18T17:31:43ZAlexander MikhaylenkoAllow to have subpages in HdyPreferenceWindowCurrently Epiphany is using dialogs-over-dialogs for things like password and cookie lists. They should be subpages in the preferences dialog.
Similarly, Games has subpages for controllers in its custom preferences dialog right now.
Bo...Currently Epiphany is using dialogs-over-dialogs for things like password and cookie lists. They should be subpages in the preferences dialog.
Similarly, Games has subpages for controllers in its custom preferences dialog right now.
Both of these things are preventing these apps from using HdyPreferencesWindow.
CC @tobias.bernard @adrien.plazashttps://source.puri.sm/Librem5/libhandy/-/issues/271HdyExpanderRow's last row has glitchy corners2020-05-20T08:15:01ZAlexander MikhaylenkoHdyExpanderRow's last row has glitchy corners![Screenshot_from_2020-05-18_20-31-06](/uploads/2ca17f2ee4c75f9c9de0df5f491e34ba/Screenshot_from_2020-05-18_20-31-06.png)![Screenshot_from_2020-05-18_20-31-06](/uploads/2ca17f2ee4c75f9c9de0df5f491e34ba/Screenshot_from_2020-05-18_20-31-06.png)https://source.puri.sm/Librem5/libhandy/-/issues/270Offer a way to have random widgets in HdyExpanderRow2020-05-20T16:29:57ZAlexander MikhaylenkoOffer a way to have random widgets in HdyExpanderRowEphy uses this in passwords dialogs:
![Screenshot_from_2020-05-18_20-04-26](/uploads/b45d63bc5ed3205173dea2e65e3b8366/Screenshot_from_2020-05-18_20-04-26.png)Ephy uses this in passwords dialogs:
![Screenshot_from_2020-05-18_20-04-26](/uploads/b45d63bc5ed3205173dea2e65e3b8366/Screenshot_from_2020-05-18_20-04-26.png)https://source.puri.sm/Librem5/libhandy/-/issues/269HdyComboRow still shows popover when it has only 1 item2020-05-08T16:16:36ZAlexander MikhaylenkoHdyComboRow still shows popover when it has only 1 item![Screenshot_from_2020-05-08_21-15-33](/uploads/cdb978ebf697c7c8b4a5d7bb8f865614/Screenshot_from_2020-05-08_21-15-33.png)
This looks awkward.
CC @tobias.bernard![Screenshot_from_2020-05-08_21-15-33](/uploads/cdb978ebf697c7c8b4a5d7bb8f865614/Screenshot_from_2020-05-08_21-15-33.png)
This looks awkward.
CC @tobias.bernardhttps://source.puri.sm/Librem5/libhandy/-/issues/268Documentation Request: Example code2020-05-07T19:24:28ZDavid HamnerDocumentation Request: Example codeAdding in example code would make [the docs](https://developer.puri.sm/projects/libhandy/unstable/) much more approachable.
For example, it's not clear that the window contains [pages](https://developer.puri.sm/projects/libhandy/unstabl...Adding in example code would make [the docs](https://developer.puri.sm/projects/libhandy/unstable/) much more approachable.
For example, it's not clear that the window contains [pages](https://developer.puri.sm/projects/libhandy/unstable/HdyPreferencesPage.html), pages contain [groups](https://developer.puri.sm/projects/libhandy/unstable/HdyPreferencesGroup.html), groups contain [rows](https://developer.puri.sm/projects/libhandy/unstable/HdyPreferencesRow.html).
Having simple clear example code in c, rust and python would enable many developers.https://source.puri.sm/Librem5/libhandy/-/issues/267Build failure with glade 3.36.02020-05-15T17:16:03ZRasmus Thomsenoss@cogitri.devBuild failure with glade 3.36.0With glade 3.36.0 building libhandy with glade integration fails with:
```
ninja: job failed: gcc -Iglade/fe02414@@glade-handy@sha -Iglade -I../glade -I. -I.. -Isrc -I../src -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/in...With glade 3.36.0 building libhandy with glade integration fails with:
```
ninja: job failed: gcc -Iglade/fe02414@@glade-handy@sha -Iglade -I../glade -I. -I.. -Isrc -I../src -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi -I/usr/include/uuid -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/libdrm -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -I/usr/include/libgladeui-2.0 -I/usr/include/libxml2 -I/builds/Leo/aports/community/libhandy/src/libhandy-v0.0.13/output -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu11 -DHAVE_CONFIG_H -DHANDY_COMPILATION -Wcast-align -Wdate-time -Wdeclaration-after-statement -Werror=format-security -Werror=format=2 -Wendif-labels -Werror=incompatible-pointer-types -Werror=missing-declarations -Werror=overflow -Werror=return-type -Werror=shift-count-overflow -Werror=shift-overflow=2 -Werror=implicit-fallthrough=3 -Wformat-nonliteral -Wformat-security -Winit-self -Wmaybe-uninitialized -Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wno-missing-field-initializers -Wno-sign-compare -Wno-strict-aliasing -Wno-unused-parameter -Wold-style-definition -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wtype-limits -Wundef -Wunused-function -Os -fomit-frame-pointer -Os -fomit-frame-pointer -fPIC -pthread -MD -MQ 'glade/fe02414@@glade-handy@sha/glade-hdy-swipe-group.c.o' -MF 'glade/fe02414@@glade-handy@sha/glade-hdy-swipe-group.c.o.d' -o 'glade/fe02414@@glade-handy@sha/glade-hdy-swipe-group.c.o' -c ../glade/glade-hdy-swipe-group.c
../glade/glade-hdy-swipe-group.c: In function 'glade_hdy_swipe_group_read_widgets':
../glade/glade-hdy-swipe-group.c:48:46: error: 'GPC_OBJECT_DELIMITER' undeclared (first use in this function)
48 | g_strdup_printf ("%s%s%s", string, GPC_OBJECT_DELIMITER,
| ^~~~~~~~~~~~~~~~~~~~
```https://source.puri.sm/Librem5/libhandy/-/issues/266Ensure properties have docs2020-05-06T23:12:42ZAlexander MikhaylenkoEnsure properties have docsOr `see accessor_func()`.
E.g. `HdyColumn` property docs are just blurbs with `.` at the end, that's both useless (blurb is already used as docs if there's no gtk-doc comment) and confusing.Or `see accessor_func()`.
E.g. `HdyColumn` property docs are just blurbs with `.` at the end, that's both useless (blurb is already used as docs if there's no gtk-doc comment) and confusing.https://source.puri.sm/Librem5/libhandy/-/issues/265Example: Keyboard navigation issues2020-04-30T08:54:43ZMichel Le BihanExample: Keyboard navigation issuesHello,
Besides the carousel that can't be navigated with a keyboard https://source.puri.sm/Librem5/libhandy/issues/209#note_97788, I noticed that _Keyboard_, _Column_, _Avatar_ and _Window_ views can't be navigated. The selector never g...Hello,
Besides the carousel that can't be navigated with a keyboard https://source.puri.sm/Librem5/libhandy/issues/209#note_97788, I noticed that _Keyboard_, _Column_, _Avatar_ and _Window_ views can't be navigated. The selector never goes from the pane to those views even when pressing `ctrl` + `tab`. It works normally in other views.https://source.puri.sm/Librem5/libhandy/-/issues/264Add more example apps2020-04-30T06:59:59ZMichel Le BihanAdd more example appsHello,
I found that there are more apps that are using `libhandy` that the ones listed in the `README`.
```
michel@debian:~$ apt rdepends libhandy-0.0-0
libhandy-0.0-0
Reverse Depends:
Dépend: handy-0.0-examples (= 0.0.13-2)
Dépen...Hello,
I found that there are more apps that are using `libhandy` that the ones listed in the `README`.
```
michel@debian:~$ apt rdepends libhandy-0.0-0
libhandy-0.0-0
Reverse Depends:
Dépend: handy-0.0-examples (= 0.0.13-2)
Dépend: seahorse (>= 0.0.12)
Dépend: libhandy-0.0-dev (= 0.0.13-2)
Dépend: gnome-calendar (>= 0.0.9)
Dépend: gir1.2-handy-0.0 (>= 0.0.12)
Dépend: gnome-games-app (>= 0.0.10)
Dépend: gnome-contacts (>= 0.0.12)
Dépend: gnome-clocks (>= 0.0.10)
Dépend: bijiben (>= 0.0.10)
Dépend: geary (>= 0.0.10)
Dépend: epiphany-browser (>= 0.0.10)
```
The apps that are missing:
`seahorse` (main windows is too wide on Librem 5 QEMU, but is usable)
`bijiben` (GNOME Notes) (works well on Librem 5 QEMU)
`geary` (a mail client) (impossible to add an account on Librem 5 QEMU. Didn't test further)
`gnome-calendar` (unusable on Librem 5 QEMU)
`gnome-clocks` (installed by default on Librem 5 QEMU)https://source.puri.sm/Librem5/libhandy/-/issues/263Possibly wrong minimum meson version2020-04-30T08:49:20ZMichel Le BihanPossibly wrong minimum meson versionHello,
When configuring `libhandy` I get a warning about the meson minimum version being too low:
```
michel@debian:~/git/libhandy$ meson . _build
The Meson build system
Version: 0.54.0
Source dir: /home/michel/git/libhandy
Build dir: /h...Hello,
When configuring `libhandy` I get a warning about the meson minimum version being too low:
```
michel@debian:~/git/libhandy$ meson . _build
The Meson build system
Version: 0.54.0
Source dir: /home/michel/git/libhandy
Build dir: /home/michel/git/libhandy/_build
Build type: native build
Project name: libhandy
Project version: 0.9.90
C compiler for the host machine: ccache cc (gcc 9.3.0 "cc (Debian 9.3.0-10) 9.3.0")
C linker for the host machine: cc ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Configuring config.h using configuration
Compiler for C supports arguments -Wcast-align: YES
Compiler for C supports arguments -Wdate-time: YES
Compiler for C supports arguments -Wdeclaration-after-statement: YES
Compiler for C supports arguments -Werror=format-security -Werror=format=2: YES
Compiler for C supports arguments -Wendif-labels: YES
Compiler for C supports arguments -Werror=incompatible-pointer-types: YES
Compiler for C supports arguments -Werror=missing-declarations: YES
Compiler for C supports arguments -Werror=overflow: YES
Compiler for C supports arguments -Werror=return-type: YES
Compiler for C supports arguments -Werror=shift-count-overflow: YES
Compiler for C supports arguments -Werror=shift-overflow=2: YES
Compiler for C supports arguments -Werror=implicit-fallthrough=3: YES
Compiler for C supports arguments -Wformat-nonliteral: YES
Compiler for C supports arguments -Wformat-security: YES
Compiler for C supports arguments -Winit-self: YES
Compiler for C supports arguments -Wmaybe-uninitialized: YES
Compiler for C supports arguments -Wmissing-field-initializers: YES
Compiler for C supports arguments -Wmissing-include-dirs: YES
Compiler for C supports arguments -Wmissing-noreturn: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wno-missing-field-initializers -Wmissing-field-initializers: YES
Compiler for C supports arguments -Wno-sign-compare -Wsign-compare: YES
Compiler for C supports arguments -Wno-strict-aliasing -Wstrict-aliasing: YES
Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wshadow: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wswitch-default: YES
Compiler for C supports arguments -Wswitch-enum: YES
Compiler for C supports arguments -Wtype-limits: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wunused-function: YES
Compiler for C supports arguments -fstack-protector-strong: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency gladeui-2.0 found: YES 3.22.2
Found pkg-config: /usr/bin/pkg-config (0.29.2)
WARNING: Project targeting '>= 0.49.0' but tried to use feature introduced in '0.50.0': install arg in configure_file
Configuring hdy-version.h using configuration
Program sed found: YES (/bin/sed)
Program gen-public-types.sh found: YES (/bin/sh /home/michel/git/libhandy/src/gen-public-types.sh)
Run-time dependency glib-2.0 found: YES 2.64.2
Run-time dependency gio-2.0 found: YES 2.64.2
Run-time dependency gmodule-2.0 found: YES 2.64.2
Run-time dependency gtk+-3.0 found: YES 3.24.18
Library m found: YES
Library rt found: YES
Checking if "ld_supports_version_script" links: YES
Program xmllint found: YES (/usr/bin/xmllint)
Configuring run using configuration
Message:
------
Handy 990 (1)
Tests: true
Examples: true
Documentation: false
Introspection: true
Vapi: true
Glade Catalog: true
------
Build targets in project: 38
WARNING: Project specifies a minimum meson_version '>= 0.49.0' but uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
WARNING: Deprecated features used:
* 0.50.0: {'install arg in configure_file'}
Found ninja-1.10.0 at /usr/bin/ninja
```
I also noticed that Debian control doesn't specify minimum version of Meson: https://source.puri.sm/Librem5/libhandy/blob/master/debian/control#L16. This could also be an issue because Debian stable (Buster) has Meson `0.49.2-1`. Anyway, I think that `control` should specify the same minimum `meson` version as project.https://source.puri.sm/Librem5/libhandy/-/issues/262Example: Impossible to reopen same item from pane2020-04-29T15:35:05ZMichel Le BihanExample: Impossible to reopen same item from paneHello,
If I open an item from main pane and come back to the main pane, it's impossible to reopen the same item. Please see the video.
![Peek_29-04-2020_17-32](/uploads/5ea09f67dfa1b1a8dbcef1dc6de4450d/Peek_29-04-2020_17-32.webm)Hello,
If I open an item from main pane and come back to the main pane, it's impossible to reopen the same item. Please see the video.
![Peek_29-04-2020_17-32](/uploads/5ea09f67dfa1b1a8dbcef1dc6de4450d/Peek_29-04-2020_17-32.webm)https://source.puri.sm/Librem5/libhandy/-/issues/261Broken handy-1-examples dependencies2020-05-11T10:01:03ZMichel Le BihanBroken handy-1-examples dependenciesHello,
`handy-1-examples` seems to have broken dependencies.
```
purism@pureos:~$ sudo apt install handy-1-examples
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not b...Hello,
`handy-1-examples` seems to have broken dependencies.
```
purism@pureos:~$ sudo apt install handy-1-examples
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
handy-1-examples : Depends: libhandy-0.0-0 (= 0.9.90~868.gbp460a78) but 0.0.14~644.gbpaa6b6f is to be installed
E: Unable to correct problems, you have held broken packages.
purism@pureos:~$ apt depends handy-1-examples
handy-1-examples
Depends: libc6 (>= 2.4)
Depends: libgdk-pixbuf2.0-0 (>= 2.22.0)
Depends: libglib2.0-0 (>= 2.43.4)
Depends: libgtk-3-0 (>= 3.16.2)
Depends: libhandy-1-0 (>= 0.9.90~868.gbp460a78)
Depends: libhandy-0.0-0 (= 0.9.90~868.gbp460a78)
```
Probably the dependency on `libhandy-0.0-0` is a mistake.
```
purism@pureos:~$ ldd /usr/bin/handy-1-demo | grep libhandy
libhandy-1.so.0 => /usr/lib/x86_64-linux-gnu/libhandy-1.so.0 (0x00007f00cf450000)
```https://source.puri.sm/Librem5/libhandy/-/issues/260Display all visible pages during leaflet/deck transitions2020-04-27T21:03:49ZAlexander MikhaylenkoDisplay all visible pages during leaflet/deck transitionsCurrently we show one actual child, and replace everything else with screenshots. We should try to have all children actually visible during the transition.
This has API implications, because it breaks the "widget is visible == it's the...Currently we show one actual child, and replace everything else with screenshots. We should try to have all children actually visible during the transition.
This has API implications, because it breaks the "widget is visible == it's the visible child" assumption: 2 children may be visible during child transition, all children are visible during the mode transition.
This would be the definitive fix for #85.https://source.puri.sm/Librem5/libhandy/-/issues/259Leaflet: visual glitch in nested leaflet2020-04-27T20:44:30ZJan Lukas GernertLeaflet: visual glitch in nested leafletI have 2 nested leaflets in my application:
A minor one containing the sidebar and the article list. And a major one containing the first leaflet and the article view.
Steps:
- have the window big enough to have the minor leaflet unfol...I have 2 nested leaflets in my application:
A minor one containing the sidebar and the article list. And a major one containing the first leaflet and the article view.
Steps:
- have the window big enough to have the minor leaflet unfolded
- switch to the article view
- scale down the window so the minor leaflet now also has to be folded
- switch back to view minor leaflet
-> glitch until the window is forced to redraw
![untitled](/uploads/dd0cae716b77716a0d612bc877113c53/untitled.webm)
Running on Fedora 31 x64 on wayland session. With libhandy version:
```
Name : libhandy
Version : 0.0.13
Release : 1.fc31
Architecture : x86_64
Size : 480 k
Source : libhandy-0.0.13-1.fc31.src.rpm
Repository : @System
From repo : updates
Summary : Library with GTK+ widgets for mobile phones
URL : https://source.puri.sm/Librem5/libhandy/
License : LGPLv2+
Description : libhandy provides GTK+ widgets and GObjects to ease developing
: applications for mobile phones.
```https://source.puri.sm/Librem5/libhandy/-/issues/258hdy_*_row_set_title() collision2020-04-27T13:59:27ZAlexander Mikhaylenkohdy_*_row_set_title() collisionSo, `HdyPreferencesRow` has `hdy_preferences_row_set_title()`:
```
/**
* hdy_preferences_row_set_title:
* @self: a #HdyPreferencesRow
* @title: (nullable): the title, or %NULL.
*
* Sets the title of the preference represented by @s...So, `HdyPreferencesRow` has `hdy_preferences_row_set_title()`:
```
/**
* hdy_preferences_row_set_title:
* @self: a #HdyPreferencesRow
* @title: (nullable): the title, or %NULL.
*
* Sets the title of the preference represented by @self.
*
* Since: 0.0.10
*/
```
Two of its subclasses, `HdyActionRow` and `HdyExpanderRow`, also have `hdy_action_row_set_title()` and `hdy_expander_row_set_title()`:
```
/**
* hdy_action_row_set_title:
* @self: a #HdyActionRow
* @title: the title
*
* Sets the title for @self.
*
* Since: 0.0.6
*/
```
```
/**
* hdy_expander_row_set_title:
* @self: a #HdyExpanderRow
* @title: the title
*
* Sets the title for @self.
*
* Since: 1.0
*/
```
And unlike the `hdy_preferences_row_set_title()`, title is not nullable here.
Sooo, what, why?https://source.puri.sm/Librem5/libhandy/-/issues/257hdy_expander_row_set_show_enable_switch not working properly2020-05-06T07:03:31ZJan-Michael Brummerhdy_expander_row_set_show_enable_switch not working properly`hdy_expander_row_set_show_enable_switch` does not work when row is created manually without glade:
```
#include <gtk/gtk.h>
#define HANDY_USE_UNSTABLE_API
#include <handy.h>
int main (int argc, char **argv) {
GtkWidget *window;
G...`hdy_expander_row_set_show_enable_switch` does not work when row is created manually without glade:
```
#include <gtk/gtk.h>
#define HANDY_USE_UNSTABLE_API
#include <handy.h>
int main (int argc, char **argv) {
GtkWidget *window;
GtkWidget *row;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
row = GTK_WIDGET (hdy_expander_row_new ());
hdy_action_row_set_title (HDY_ACTION_ROW (row), "Switch test");
hdy_expander_row_set_show_enable_switch (HDY_EXPANDER_ROW (row), FALSE);
gtk_container_add (GTK_CONTAINER (window), row);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
```https://source.puri.sm/Librem5/libhandy/-/issues/256HdySearchBar should respect gtk-decoration-layout2020-04-24T19:21:27ZJan-Michael BrummerHdySearchBar should respect gtk-decoration-layoutIn desktop environments where the window decorators are changed to have a close button on the left,
set the close button in HdySearchBar also to the left.In desktop environments where the window decorators are changed to have a close button on the left,
set the close button in HdySearchBar also to the left.