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/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/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/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/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/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.https://source.puri.sm/Librem5/libhandy/-/issues/255Support updating window buttons/icon from HdyHeaderBar2020-04-22T18:51:03ZAlexander MikhaylenkoSupport updating window buttons/icon from HdyHeaderBarThis is a GTK issue that's not even exclusive to headerbars inside the window (happens with split headerbars etc), but would be nice to fix it regardless.
We should trigger layout update when window's `deletable`, `resizable`, `modal` o...This is a GTK issue that's not even exclusive to headerbars inside the window (happens with split headerbars etc), but would be nice to fix it regardless.
We should trigger layout update when window's `deletable`, `resizable`, `modal` or `transient-for` properties change, trigger icon update when `icon-name` changes.
There's also the title, but that one is probably fine.https://source.puri.sm/Librem5/libhandy/-/issues/254HdyViewSwitcher should handle more than 4 entries in narrow mode2020-04-23T15:54:02ZJan-Michael BrummerHdyViewSwitcher should handle more than 4 entries in narrow modeCurrently it is not possible to reliable use more than 4 tiles in narrow mode. Please add
a 3-dots menu button in the view switcher to toggle between more views in narrow mode (see iOS).
Sometimes it is just not possible to shrink prefe...Currently it is not possible to reliable use more than 4 tiles in narrow mode. Please add
a 3-dots menu button in the view switcher to toggle between more views in narrow mode (see iOS).
Sometimes it is just not possible to shrink preferences to 4 section.https://source.puri.sm/Librem5/libhandy/-/issues/253Handy-CRITICAL on closing a window with HdyViewSwitcherTitle2020-04-16T16:40:57ZNahuel Gomez CastroHandy-CRITICAL on closing a window with HdyViewSwitcherTitle```
(unitube:2): Handy-CRITICAL **: 13:28:29.847: hdy_view_switcher_get_stack: assertion 'HDY_IS_VIEW_SWITCHER (self)' failed
(unitube:2): Gtk-CRITICAL **: 13:28:29.850: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
```
...```
(unitube:2): Handy-CRITICAL **: 13:28:29.847: hdy_view_switcher_get_stack: assertion 'HDY_IS_VIEW_SWITCHER (self)' failed
(unitube:2): Gtk-CRITICAL **: 13:28:29.850: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
```
I'm not really sure if the last one is related.
Steps to reproduce:
- Open a window that uses HdyViewSwitcherTitle
- Close it
- Check the output
This happens on masterhttps://source.puri.sm/Librem5/libhandy/-/issues/251HdyKeypad shouldn't expose GtkGrid API2020-04-16T18:53:22ZAlexander MikhaylenkoHdyKeypad shouldn't expose GtkGrid APIWe should make it a `GtkBin` subclass containing a grid, and expose useful API (spacing?) explicitly. Right now the API looks like we support stuff like this:
![Screenshot_from_2020-04-14_04-18-51](/uploads/1f28825babaec9cb6ad46392a579c...We should make it a `GtkBin` subclass containing a grid, and expose useful API (spacing?) explicitly. Right now the API looks like we support stuff like this:
![Screenshot_from_2020-04-14_04-18-51](/uploads/1f28825babaec9cb6ad46392a579ce3c/Screenshot_from_2020-04-14_04-18-51.png)https://source.puri.sm/Librem5/libhandy/-/issues/250HdyComboRow needs active-id2020-04-13T11:39:20ZJan-Michael BrummerHdyComboRow needs active-idThe current implementation of HdyComboRow only supports binding settings based on the index of the given model. This will not work reliable in cases where the combo menu part holds non static items, e.g. list of audio devices/outputs/dis...The current implementation of HdyComboRow only supports binding settings based on the index of the given model. This will not work reliable in cases where the combo menu part holds non static items, e.g. list of audio devices/outputs/displays. Therefore it is mandatory to set the active entry based on it's name instead of an id. Please add something like GtkComboBox active-id.https://source.puri.sm/Librem5/libhandy/-/issues/248Make translations available on GNOME Damned Lies2020-04-10T11:02:08ZAsciiWolfMake translations available on GNOME Damned LiesSince the libhandy support is merged into upstream GNOME, please, consider making its translations available on the GNOME [Damned Lies](https://l10n.gnome.org) website. It would help bring many new translations from the GNOME community. ...Since the libhandy support is merged into upstream GNOME, please, consider making its translations available on the GNOME [Damned Lies](https://l10n.gnome.org) website. It would help bring many new translations from the GNOME community. Thanks!