Instead of using the GtkAssistant Widget we use a homebrewed wizard in the installer, profile chooser and tl-setup. To present a user interface with that same look and feel as the rest of the system (e.g. GNOME initial setup), we should make use of the GtkAssistant widget.
I just assumed that the profile chooser also used the homebrew Wizard widget. This is apparently not the case. So let's handle the profile chooser in its entirety under bug 7905.
The GTK Assistant widget makes heavy use of client-side decoration (placing buttons and other crazy stuff in the title bar), so when testing this we need to make sure that things still look sane on systems that don't support client-side decorations.
Since GTK Assistant is pretty heavy on client-side decorations, I have checked how it behaves when running the new tlinstaller on various not-so-conventional window managers. I have tested Openbox, i3, icewm, and twm. All of these shows our window just like GNOME does it, with the exception being twm which shows both it's own and the client-side decorations. I deem this support more than good enough.
I have identified a number of shortcomings of Gtk.Assistant which makes me consider leaving the Gtk.Assistant abstraction in preference of the more general Gtk.Notebook/Gtk.Stack approach. • Side pane • List of all the pages that is displayed to the left of the page contents. • Has a strong GTK2 smell graphically • Always shown given that page titles is set • Without page titles (if we do not want to show the side pane) we must roll our own title bar to display a title. This title is not respected by all window managers. (Can surely be hacked around, but will increase code complexity) • Navigation infrastructure • Basically unusable for our use case since the pretty nische pre-defined AssistantPageTypes does not map well how we want to handle navigation. Thus, we still have to manually keep track of page history for the "Back" button • With AssistantPageType.CUSTOM set, we only get the possibility to place buttons on the right side of the window title unless we completely ditch the assistant title bar for our own. • Does not support page switching animations (minor issue, but both gnome-tour and gnome-initial-setup uses these to a great extent) In other words, if we stick with Gtk.Assistant, we have to: 1. Introduce ugly hacks to compensate for it's shortcomings for our use-case 2. Still basically treat it as a Gtk.Stack
Also note that both gnome-tour and gnome-initial-setup both use a Gtk.Stack instead of Gtk.Assistant.
Writing style and typography will not get any attention as part of this bug, that has been split out to bug 7921. Same goes for page animations, that has been split to bug 7923.
We've done some shallow testing on - SLES12 (GNOME) - Debian 9 (KDE Plasma, XFCE4) - RHEL 7 (XFCE4, GNOME) - Ubuntu Server 22.04 (Mate, GNOME) Things tested: - Doing a clean install - Running tl-setup, verifying that missing requirements are installed - Verifying that the back button works as expected and page willingness checks - Verifying that all clickable elements shown during a clean install work as expected We now consider this done and ready for verification!
We got some feedback regarding the low emphasis on the body text on the "Server Type" page along with a couple of pages where adding titles may be appropriate. Reopening while I investigate!
tl-setup has now been changed according to the feedback mentioned in comment 70 and should be ready for testing once again!
General ---------------------------------------- Testing of tlinstaller and tl-setup using dev build #2661 has been conducted employing a combination of dists and environments listed below, • GNOME (SLES12, Ubuntu, RHEL8, RHEL9, Fedora36) • MATE (Fedora36) • Xfce (Fedora36) • KDE (Fedora 36) for which the wizard is generally working as intended. Some minor points that may need attention are 1) If tlinstaller ends up having nothing to do i.e. packages are already installed, there's no proper exit or hint towards tl-setup, contrary to when tlinstaller actually installs packages which is followed by a query to proceed with tl-setup. The installer presents no option but to Cancel, where an OK/Close button might be appropriate together with a pointer to tl-setup. 2) Failing to resolve optional packages/dependecies (e.g. Python LDAP) is followed by the claim that the configuration process *will* continue with the caveat that certain things may not work properly. However, the user must go back one page and uncheck said installation, then proceed with the setup. 3) Images are not displayed equally well in light and dark modes, where dark mode exhibits the lesser quality. tl-setup wording suggestions ---------------------------------------- Server type : Master as a proper noun. Migrate configuration : release notes contains -> release notes contain Requirements : requires a few libraries -> requires certain libraries NFS : a NFS client -> an NFS client Printers : location based -> location-based Printers : Cut 'configure' from switch button labels to enhance the feeling of the ON/OFF effect. Acceptance criteria ---------------------------------------- • The common base wizard graphical interface used in tlinstaller and tl-setup should follow the GNOME HIG • Themeing • Layout • Design patterns The installer and setup of ThinLinc appears to follow the GNOME HIG very well in accordance with the acceptance criteria. Two points concerning the HIG are listed below that could use some attention. 1) Access keys are lacking for all non-headerbar buttons. The previous GNOME HIG seems to be advocating all three types of buttons (checkboxes, radio buttons, switch buttons) having access keys, while the current HIG appears to only prefer them for switch buttons. Perhaps it's wise settling with Tab-ing since groups of buttons are never particularly large and thus access keys are unlikely to be used. 2) Undoing user mistakes is not possible at certain steps in the wizard while remaining in the same instance. Of course this may be difficult to work around since some steps determine how the setup path forks.
A couple of notes regarding the minor points listed above: 1, 2) The rather clunky UX mentioned in these two points is not regressions nor especially related to the GNOME HIG. I will break these out into separate bugs. 3) This issue is better handled under bug 7904 in which those images were added. Even though the wording suggestions are not all strictly related to this bug, I'll go ahead and fix them anyway :)
Another regression is that using TAB or arrow keys to navigate between RadioButtons, CheckButtons and the new Switch controls now requires extra steps. The first TAB press now places focus on the ListBoxRow that contains the control, the second TAB places focus on the control itself. I have investigated this thoroughly now and the solution we want in most cases is to set "can-focus" to false on the controls within the ListBoxRows. The rows are "activatable" themselves, which means that we can click anywhere on the row to toggle/activate the control. Allowing focus on the controls themselves isn't helpful. Disabling "can-focus" gives the desired behavior for CheckButton and Switch widgets inside our ListBoxes. Unfortunately, I came across a bug in GTK 3 for RadioButtons inside a ListBox. If we disable "can-focus" on the RadioButton the focus chain breaks completely, you can tab to the first row in the ListBox but then subsequent tabs don't have any effect. This bug seems to be fixed in GTK 4: https://gitlab.gnome.org/GNOME/gtk/-/issues/3633
The ListBox focus issue has been fixed now, with the exception of RadioButtons which unfortunately still will require some extra tab steps.
I have now addressed the points made in comment 82: - The minor UX points have now been broken out into bug 7941 and bug 7942 and bug 7904 has been reopened due to the lacking image/background contrast in dark mode. - The wording suggestions have been implemented. Regarding access keys/mnemonics in radio/check-buttons I have not seen a single example of these being used together with boxed lists for the radio/check-buttons (see for example gnome-control-center), so let's skip this. Regarding undoing steps, this is somewhat unfeasible with how we currently do things. Marking as resolved.
The issues brought up in comment 82 have been addressed by the developers to a satisfying degree and appropriate spin-off bugs have been opened, rendering this bug as fixed. Closing.
Testing as reported in comment 93 had missed to confirm the effects from commit r38500 (comment 90) that dealt with focus problems of button widgets whose actual button children could be focused while TAB-ing, resulting in 2 required TABs per button. This final piece has been tested with dev builds #2673 (pre-fix) and #2674 (post-fix) on SLES12 (GNOME), Ubuntu22.04 (GNOME), Fedora36 (Xfce and GNOME). We can readily identify the problem in the pre-fix build and in the post-fix build the system is working as intended: the children of check boxes and switch buttons cannot be focused thus reducing excessive TAB-ing, while the problem persists for radio buttons due to a bug in GTK 3. Closing.
A minor regression from release 4.14 has been identified for the installer and setup GTK wizard concerning TAB-ing on pages that are lacking some widget on the page -- excluding headerbar buttons -- that can be focused. This effect was seen on SLES12 (employs older GTK) but does not appear for instance on Ubuntu22.04 (employs newer GTK). The headerbar buttons cannot be focused solely using TAB, although if focus is forced on a button using the mouse, it is possible to TAB between the buttons with TAB / shift+TAB as long as one doesn't TAB beyond the headerbar at which point the chain is broken.
There is some issue with scrolling in tlinstaller. When upgrading from 4.14.0, it will show a list of packages to be removed, and a list of the package to install. All of this visually fits in the window. However, a scroll bar is still shown and there is a lot of empty space at the bottom that can be scrolled to. Oddly enough, this extra space disappears if you switch focus to another window and then back again. Seen on RHEL 9.
Concerning comment 95: this Tab-chain interruption can be observed on Ubuntu22.04 in a KDE desk. env., contrary to the former hypothesis that the phenomenon was isolated to SLES12 and attributed to older GTK.
Correction comment 98: observed in Xfce desk. env. -- not KDE.
Further testing on Fedora36 with dev build #2661 confirms the tl-setup wizard is responding properly to different choices.
(In reply to Tobias from comment #98) > Concerning comment 95: this Tab-chain interruption can be observed on > Ubuntu22.04 in a KDE desk. env., contrary to the former hypothesis that the > phenomenon was isolated to SLES12 and attributed to older GTK. I'm seeing focus issues with the default GNOME desktop on both Fedora 36 and Ubuntu 22.04 as well. On GNOME I've only seen it happen on pages listing packages to be installed. Pages that lack widgets and only show text are not problematic like they are on SLES 12. GNOME on SLES12 has problems with both package listing pages and text-only pages.
The focus issue seen on package listing pages (comment #98 and comment #102) is now fixed by allowing focus on the list rows. We have however decided to not do anything about the focus issue seen only on SLES12. The impact is fairly harmless and that platform is very old. The scrolling issue mentioned in comment #96 is also fixed. This means things is ready for testing once again.
A bug was filed with GTK regarding the focus issue with ListBoxRows: https://gitlab.gnome.org/GNOME/gtk/-/issues/4977
Tests have been done on Ubuntu22.04 (GNOME) and Fedora36 (Xfce) using dev builds #2676 and #2692. The two issues at hand, (1) scrollable page when listing old packages upgrading from 4.14 (see comment 96) (2) TAB-chain breaking when listing packages to be installed (see comment 95, comment 98, and comment 102) are both observed in the older build #2676 but cannot be observed after the implemented fixes in the more recent build #2696. Closing.
I found a bunch of places where the spacing between elements isn't the recommended [1, 2] multiple of 6. Reopening… • [1] <https://developer-old.gnome.org/hig/stable/visual-layout.html.en#general-guidelines> • [2] <https://blogs.gnome.org/tbernard/tag/design/#headerbar>
The spacing issues highlighted in comment 108 have now been fixed. Marking as resolved.
Note that there are a couple of non-6px-multiple spacings left in the installer/tl-setup for the intro and outro graphics. These will instead be handled in bug 7904.
(In reply to Pierre Ossman from comment #96) > There is some issue with scrolling in tlinstaller. When upgrading from > 4.14.0, it will show a list of packages to be removed, and a list of the > package to install. All of this visually fits in the window. However, a > scroll bar is still shown and there is a lot of empty space at the bottom > that can be scrolled to. > > Oddly enough, this extra space disappears if you switch focus to another > window and then back again. > > Seen on RHEL 9. This is now "inverted". I can't scroll in this list now, until I switch focus back and forth.
The margins on the last page of tlinstaller look a bit odd. The widgets below the title have much wider margins than the title, and previous pages.
(In reply to William Sjöblom from comment #110) > The spacing issues highlighted in comment 108 have now been fixed. Marking > as resolved. Went through most pages in tlinstaller and tl-setup on RHEL 9, and the spacing looks good to me.
The issues highlighted in comment 112 and comment 113 have now been fixed.
Retested on RHEL 9, by upgrading from 4.14.0: * Scrolling on package installation now scrolls correctly right away * Last page of tlinstaller looks great * Layout on all pages in both tlinstaller and tl-setup look good I think this is done now. :)
The scrolling issue initially noted in comment 96 and fixed in r38591 has now been reported upstream: https://gitlab.gnome.org/GNOME/gtk/-/issues/5013
Noticed a minor issue; the mnemonics are lost on the final button in tlinstaller.
The "Start (installer|setup)" buttons also had no mnemonics. These two, along with the button mentioned in comment 128 now have proper mnemonics. Marking as resolved.
Retested on RHEL 8. Mnemonics for top buttons and start buttons work well in both tlinstaller and tl-setup.
