- Oct 22, 2020
-
-
Alice Mikhaylenko authored
-
Alice Mikhaylenko authored
-
- Oct 21, 2020
-
-
Sebastian Krzyszkowiak authored
gestureswipe: Count last event when calculating velocity Closes #17 See merge request Librem5/gtk!23
-
The last event, matching lifting the finger/releasing the mouse button, is important when there's a large delay between it and the previous events, as in when performing a movement, stopping, then releasing fingers as opposed to doing a swipe. If this event is skipped, doing this will result in kinetic deceleration matching the previous finger movement, while the expected behavior would be no deceleration. See also 97f54062 for a similar fix in GtkEventControllerScroll.
-
- Oct 08, 2020
-
-
Alice Mikhaylenko authored
Tree view is not adaptive, and has multiple issues: * Each column takes extra horizontal space. When there are few enough columns, it can fit, but it can be broken by simply adding another column, like what happened with Type recently. * Rows are tiny and don't make for good click targets on touch. To solve both problems, introduce a single unified column and show file name and its metadata (date, time, type, size, location) on a separate row. Also increase icon size and hide all the other columns and headers.
-
When a fixed size is active (e.g. the window is maximized), gtk_window_resize() shouldn't take immediate effect, so the request was dropped. This made GTK unhappy if this happened, it will freeze updating the window until it received the new size it demanded. Handle this by being nice and emitting a dummy GDK_CONFIGURE event with the old size where we previously ignored it. It won't resize the window immediately, so it shouldn't have a visible effect, and the size GTK requested is still saved away for when the window is unmaximized, but emitting the event will make GTK receive the event it expects. We still drop the request on the floor, e.g. if we still haven't seen the initial configuration, just as we do when actually doing the resize. Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
-
When GtkApplication starts listening to the screensaver's D-Bus status, the screensaver-active property is not initialised and applications making use of the property are out of sync until the first state change. Any application starting when the screensaver is active will think it's inactive. To fix this, we set the property when we first start monitoring the screensaver.
-
This helps GtkfontChooserDialog fitting in mobile phone screens.
-
Drop the minimum number of characters for the filename entry, and instead expand it. This helps it fit in narrow screens.
-
This avoids overloading the headebar, and lets the save entry be populated just below it, where there is room. Fixes Librem5/Apps_Issues#99.
-
This will help the infobars fit on phone screens.
-
That is when initially maximized windows are expected to be maximized, not just before realizing them.
-
This is less agressive than resizing all resizable windows.
-
This will allow to drop the close buttons and make the transient windows look like proper mobile dialogs.
-
This will make them look better on phone screens.
-
This will allow to drop the close buttons and make the dialogs look like proper mobile dialogs.
-
This will make them look better on phone screens.
-
This makes it nicer on phones by avoiding having to scroll too much on a touch screen and it makes it match the changes we applied to WebKitGTK for the same reasons.
-
This makes the dialog work better with horizontally constrained screens.
-
-
This will be used to reveal/conceal the file chooser sidebar.
-
-
-
This is imported from HdyViewSwitcherBar from libhandy 1.0.0.
-
This is imported from HdyViewSwitcher from libhandy 1.0.0.
-
This is imported from HdyViewSwitcherButton from libhandy 1.0.0.
-
Adrien Plazas authored
Update pureos/sloppy to 3.24.23; fix window resizing and file chooser See merge request Librem5/gtk!20
-
They need to be updated for the patches, and cause a CI failure atm.
-
-
This reverts commit 95d5bd11.
-
Alice Mikhaylenko authored
-
Alice Mikhaylenko authored
Tree view is not adaptive, and has multiple issues: * Each column takes extra horizontal space. When there are few enough columns, it can fit, but it can be broken by simply adding another column, like what happened with Type recently. * Rows are tiny and don't make for good click targets on touch. To solve both problems, introduce a single unified column and show file name and its metadata (date, time, type, size, location) on a separate row. Also increase icon size and hide all the other columns and headers.
-
When a fixed size is active (e.g. the window is maximized), gtk_window_resize() shouldn't take immediate effect, so the request was dropped. This made GTK unhappy if this happened, it will freeze updating the window until it received the new size it demanded. Handle this by being nice and emitting a dummy GDK_CONFIGURE event with the old size where we previously ignored it. It won't resize the window immediately, so it shouldn't have a visible effect, and the size GTK requested is still saved away for when the window is unmaximized, but emitting the event will make GTK receive the event it expects. We still drop the request on the floor, e.g. if we still haven't seen the initial configuration, just as we do when actually doing the resize. Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
-
When GtkApplication starts listening to the screensaver's D-Bus status, the screensaver-active property is not initialised and applications making use of the property are out of sync until the first state change. Any application starting when the screensaver is active will think it's inactive. To fix this, we set the property when we first start monitoring the screensaver.
-
This helps GtkfontChooserDialog fitting in mobile phone screens.
-
Drop the minimum number of characters for the filename entry, and instead expand it. This helps it fit in narrow screens.
-
This avoids overloading the headebar, and lets the save entry be populated just below it, where there is room. Fixes Librem5/Apps_Issues#99.
-
This will help the infobars fit on phone screens.
-
That is when initially maximized windows are expected to be maximized, not just before realizing them.
-
This is less agressive than resizing all resizable windows.
-