Difference between revisions of "GTK+ 4 issues"
(→Menus) |
|||
| Line 29: | Line 29: | ||
GTK4 uses menus based on Gio::Menu using Gio::Actions. These are easy to construct with .ui files. They automatically keep in sync with action states and with shortcuts. We are moving to them for the main menu bar in GTK3. | GTK4 uses menus based on Gio::Menu using Gio::Actions. These are easy to construct with .ui files. They automatically keep in sync with action states and with shortcuts. We are moving to them for the main menu bar in GTK3. | ||
Gio::Menus do have some issues. The first, and perhaps the most important, is with icons. Icons can be specified in the .ui files. In GTK3 they are always shown while in GTK4 they are never shown | Gio::Menus do have some issues. The first, and perhaps the most important, is with icons. Icons can be specified in the .ui files. In GTK3 they are always shown while in GTK4 they are never shown (by default). | ||
Icons visibility must be enabled for GTK4 using a callback when a menu is opened (similar to how we shift icons with GTK3). To allow a user to choose between: | |||
# Showing all icons. | |||
# Showing only icons tagged with 'use-icon' attribute in the .ui file. | |||
# Never showing icons. | |||
we must resort to rebuilding the Gio::Menu constructed from the .ui file. This is due to a series of unfortunate events including Gio::MenuItem's being immutable and the limited passing of attributes from Gio::Menu's to Gtk::Menu's (GTK3) or Gtk::PopoverMenu's (GTK4). The rebuilding is complicated but doable. See the "Toy program" linked to below. The menu,, once set, is not changeable so Inkscape must be restarted when a user changes their icon preference. Note that GTK discourages the use of "Verb" icons. See: https://discourse.gnome.org/t/toggling-on-off-icon-visibility-in-gmenu-items/7234/2 . | |||
The second problem, is that shifting icons into the space reserved for check and toggle button icons in GTK4 doesn't work properly. The "allocation" of widget space seems to have some kind of feedback loop based on the previous icons shift. | |||
== Useful Links == | == Useful Links == | ||
Revision as of 16:20, 23 August 2021
Specific Issues
Toolbars
Gtk::Toolbar and related widgets have been removed as "outdated". The suggested replacement is a Gtk::Box with normal widgets. This means that toolbars will have a minimum width defined by the sum of the widths of their child widgets rather being allowed to shrink to a smaller width with "over-flowing" widgets being replaced by a drop-down menu at the end of the toolbar. This requires us to re-think our toolbars.
In practice, many of the replacement menu items for dropped widgets are not very practical. Having toolbars that are quite wide probably is a sign of poor design. Many of the current toolbar widgets could be packed in non-modal popovers, that is, pop-up menus that stay open until dismissed. It would be relatively easy to then reduce most toolbar widths to less than 1000 pixels. The most difficult toolbar to reduce in size is the main toolbar. This could be dealt with by removing all the dialog buttons. One might think of putting all dialogs into a new menu bar sub-menu or into a modal popover.
The longest toolbars (width):
- Text (1650)
- Calligraphy (1450)
- Main Toolbar (1350 - Horizontal, 950 - Vertical)
- Selector (1300)
- Spray Paint (1300)
- Node (1250)
- Ruler (1100)
- Eraser (1050)
- Tweak (1050)
- Tool Toolbar (800 - Vertical)
- Snapping (750 - Vertical)
We need to decide on the minimum size window we should target. The current minimum window size is about 811x524 pixels with main toolbar on top. Most modern budget displays are 1366x768 and are used by about 20% of desktops. A smaller fraction of about 5% use 1280x720. See Screen Resolution Stats . Gnome recommends a minimum display size of 1024x600.
Menus
GTK4 uses menus based on Gio::Menu using Gio::Actions. These are easy to construct with .ui files. They automatically keep in sync with action states and with shortcuts. We are moving to them for the main menu bar in GTK3.
Gio::Menus do have some issues. The first, and perhaps the most important, is with icons. Icons can be specified in the .ui files. In GTK3 they are always shown while in GTK4 they are never shown (by default).
Icons visibility must be enabled for GTK4 using a callback when a menu is opened (similar to how we shift icons with GTK3). To allow a user to choose between:
- Showing all icons.
- Showing only icons tagged with 'use-icon' attribute in the .ui file.
- Never showing icons.
we must resort to rebuilding the Gio::Menu constructed from the .ui file. This is due to a series of unfortunate events including Gio::MenuItem's being immutable and the limited passing of attributes from Gio::Menu's to Gtk::Menu's (GTK3) or Gtk::PopoverMenu's (GTK4). The rebuilding is complicated but doable. See the "Toy program" linked to below. The menu,, once set, is not changeable so Inkscape must be restarted when a user changes their icon preference. Note that GTK discourages the use of "Verb" icons. See: https://discourse.gnome.org/t/toggling-on-off-icon-visibility-in-gmenu-items/7234/2 .
The second problem, is that shifting icons into the space reserved for check and toggle button icons in GTK4 doesn't work properly. The "allocation" of widget space seems to have some kind of feedback loop based on the previous icons shift.