Accéder au contenu principal

Playing with GtkAssistant

I decided to spend some time today to play with GtkAssistant, more precisely, I tried to build a mock installation wizard mimicking Boxes' one in order to test how I could adapt its behaviour to make it GtkAssistant ready.

Overall, I enjoyed using GtkAssistant, it is a quite well thought out widget offering a lot of potential for a small API.

But despite how good GtkAssistant is, I encountered problems adapting it to my need. Here follows a list of what bogged me down.

A sequence of pages

GtkAssistant is great at implementing a sequence of pages, unfortunately, Boxes' wizard is more like a graph of pages.

Boxes' wizard's page graph
Boxes' wizard's page graph

Such a configuration is clearly out of GtkAssistant's scope and it can easily be solved by arranging the pages as a sequence and setting a custom "forward" function, so it's not that much of a problem.

Action area

GtkAssistant allows you to mark a page as custom, which will show no button in the action area when visiting this page. You can then add buttons to the action area in order to give some controls to the user. Unfortunately, I found no way to add buttons to the left side of the action area, usually containing the "back" and "cancel" buttons, which is pretty annoying.

Adding a way to add widgets to the left side or to hide only the buttons of the right side of the action area would help. In the end, I didn't found a way to make the "custom" page type useful to my case (which may just be better in the long run).

Content padding

GtkAssistant sourround its pages with some padding, which most of the time is a good idea, unfortunately one of the pages I want to use is a big and complex widget (a GtkFileChooserWidget) which need to take as much space as possible for the user's ease, but also not to look ugly.

In red, the unwanted padding
In red, the unwanted padding

Cancelling a progressing page

You can't cancel (and go back from) a page typed as "progress" if it haven't been completed. It may make sense if the work in progress must be finished properly, but it's not always the case.

For example, Boxes use a progress bar to indicate that an installation medium is being downloaded, but such a task should be cancellable by the user (he could notice that he isn't downloading the right image), so even if the "progress" page type seems to correspond to this use case, it can't be used because it doesn't allow you to cancel a possibly wrong and probably long task.

It's not that much of a problem though as a regular page can be tweaked to have the desired behaviour.

Transition animations

There is no transition animation when moving between pages. It's not a huge problem but having some animation could make the page transitions more understandable. I would love to have a left to right animation when progressing forward and vice versa when progressing backward. =)

Help wanted

If you are a Gtk+ developer or that you know how to fix some of these problems, especially the padding one, I would greatly appreciate you help! =D

Commentaires

  1. GtkAssistant -> content_box -> margin_border = 12 -> change it by 0 and that's it =)
    A good way to figure out this things is to use GtkInspector. If you don't know about it, press ctrl+alt+d and it will open, then you can see the widget hierarchy and see it's properties and css properties and change it on live. It's awesome!

    PD: I also hate by default padding and margin in widgets :(

    RépondreSupprimer
    Réponses
    1. there's also a 12px spacing set on the "main_box" GtkBox

      Supprimer
    2. Thanks a lot! Thanks to both of you I have been able to hack something working. Unfortunately I haven't found a clean way to retrieve the internal widgets though, the only I found being something like the following.

      construct { realize.connect (get_content_boxes); }

      private void get_content_boxes () {
      if (main_box == null) {
      forall ((child) => {
      if (child.name == "GtkBox")
      main_box = child as Gtk.Box;
      });

      if (main_box != null)
      main_box.set_property ("spacing", 0);
      }
      }

      Supprimer
    3. I think this is a general problem which should be addressed upstream directly, would you file a bug about it?

      Supprimer
    4. Yep, here it is: https://bugzilla.gnome.org/show_bug.cgi?id=750631

      Supprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone.Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones.How Fit are Existing GTK+ Apps?Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it.A first kind of layout is found in applications like Documents, I'll call it stack UI: it uses all the available space to display the collection of information sources (in that case, documents), clicking an element from t…

One Widget to Adapt Them All and to The Librem 5 Port Them

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.C'est pas sorcierThe underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.To achieve that, I wrote a GTK+ widget which…

Adaptive GNOME Web

I started working on making GNOME Web work well on the Librem 5; to be sure it fits a phone's screen I want the windows to fit in a 360 points width, which is definitely small. To do so I started with the advices from Tobias Bernard to make Web have two modes that I named normal and narrow. The normal mode is Web as you know it, while the narrow mode moves all buttons from the header bar but the hamburger menu to a new action bar at the bottom, letting the windows reach yet unreachable widths. Web autmatically adapting to small sizes. And now, with device rotation on a tablet. The code is overall ready, I still need to break it into reviewable bits before submitting it upstream.Once this get merged:we want to not show tabs in narrow mode and instead to display a popover listing the available pages,we want to make the search bar shrink rather than to limit the minimum window size,we consider migrating away from the application menu model.A quick layout test of the pages popover. P.S.…