The overall feedback was positive, welcoming the change. To us, this means that we will indeed merge that code branch (yes, it’s largely working already, it’s not just a mock-up) to the main development line, and you will see that new user interface appear in the next versions of the yast2-qt-pkg package on FACTORY.

There were a number of concerns and side issues that I’d like to summarize here:

1. We should not use tabs here because what goes on is not parallel. Well, this is an issue that could be debated for a long time. It’s not parallel in the same sense as multiple sessions in separate KDE konsole tabs. But it’s at least as parallel as different settings in settings dialogs in a zillion of applications: More or less unrelated stuff that would clutter the screen too much if displayed all at ounce, but that makes sense to be grouped together. In tabs. We do respect others seeing this differently, but weighing the pros and cons carefully we found that this rather abstract concern does not outweigh the benefit of migrating to tabs.
2. Missing keyboard shortcuts. Right: Each tab and each menu entry should have one. I added them to the code this afternoon.
3. Duplicate View menu, one in the main menu bar and on that new View button. That was an oversight; the label on that button was New in the first version, but that didn’t look too obvious to us, so we changed it to View, not realizing that we already had a View menu in the main menu bar. That menu in the main menu bar contained view options, so it is now renamed to Options and moved to the right. It’s not truly a traditional View menu anyway. It contains menu entries like Show -devel Packages and Show -debuginfo Packages.
4. Consuming screen space for the tabs. Right, this is a tradeoff.
5. Less surprise to first time users. That combo box was unusual, and some of you replied that they had to point first time openSUSE users to that combo box so they could switch views.
6. Don’t change for the sake of changing. No, we are not doing that. You’d be amazed how many times we had to defend our design. There were a number of attempts to radically dumb it down for the sake of newbies, but the voice of reason had always won. The world does not consist of newbies only. We also have to cater for expert or intermediate users. We came up with the simple Patterns dialog during installation for them, moving the full-fledged package selector one more mouse click away (with the Details button) for the experts. Each time we improve the usability of the package selector, there is one less arguments for dumbing it down. We believe that using tabs is a step towards that direction.
7. Nobody commented on the position of that View button. The majority of internal people here (including our usability experts) said they preferred it on the left side where it isn’t easily overlooked (unlike on the right side).
8. The current settings (which tabs are open) should be saved upon exit and restored when the user enters the dialog the next time. I hadn’t explicitly mentioned this, but this was always our intention. It’s not in the code yet, but this is the next thing on the “to do” list.

There were also some side issues that were not entirely on topic, yet worthwhile to mention:

1. Don’t quit the package management workflow after package installation is finished. There was a long discussion about that in Bugzilla why that “Install more packages?” pop-up was introduced in the first place (because of slow start-up times of the package management stack) and why we removed it when that was no longer the case. For those of you who want that question pop-up back, look here how.
2. Some users complained that the new flat list in the Package Groups filter view is confusing – too many packages are listed in each category. They want the old tree back. Well, here it is – it’s the RPM Groups filter view I had briefly mentioned:
   

   The other view (the flat PackageKit groups list) is still there, of course:

   

How do you select any of those filter views? In previous versions of the (Qt) package selector, we used to have a combo box to do that:

That’s somewhat unusual, and there have always been critics who claimed that we should use tabs instead. Our standard reply was always that this would not really be helpful because there are so many of them; you’d run out of screen space quickly, and with the number of filter views we have, this would look overwhelming and confusing:

Ugh… not good. Not even at this screen resolution. Now think about 800×480 netbooks and more verbose languages like German, French or Hungarian. No way to make this fit on the screen. And left/right scroll buttons are the last thing you want for tabs.

So, what else could we do?

Reduce the number of filter views? Well, we’ve been down that road for a while. But new ones come along all the time, and it always hurts some users when we throw out their favourite one. The “RPM groups” (the one with a tree) was such a case; it had to make way for the newer PackageKit groups. A number of users complained.

And we have more filter views in store. There are many more cool things we could do. But this should not add to confusion, so right now, we avoid to add more views.

But how is everybody else doing it? Let’s have a few looks at that.

What is it we are doing here? We are browsing for and through packages. So, let’s compare it with other kinds of browsers. Let’s look at Konqueror:

In Konqueror, you can use tabs. Once you got used to it, that’s a powerful and efficient way to avoid cluttering your screen with multiple browser windows. They are all neatly tucked away in that row of tabs.

Another application that uses a similar approach is Konsole, the KDE terminal emulator:

While in Konqueror you use the middle mouse button to open a link or a bookmark in a new tab, there is a limited number of options in Konsole. You select a session type from a pop-up menu on a special button on the bottom left corner:

So, let’s try someting similar with the YaST2 Qt package selector. Let’s try to use tabs, but not in an overwhelming number. Let’s open only a few of them right away. The user can open more if he likes.

First try:

Hm – or maybe put that “View” button in the top left corner?

Of course, the user can close any of the open tabs (except the last one) again – just like in Konqueror or in Konsole:

If we really do that, that means that the door is now no longer closed for new filter views. Some that could be added immediately are:

• Show all available (not installed) packages (yes, available via “Installation Summary”, but not that obvious to novice users)
• Show all installed packages (also available via “Installation Summary”)
• Keywords / tag cloud (“KDE application” (linked against KDE libs), “GNOME application”, “mail client”, “Java application”)

We don’t want to overdo it, of course.

So… what do you out there think? Do you like it? Should we use tabs there? If yes, where to put that “View” menu? Left? Right? Elsewhere? Use a toolbar button with just an icon (like in Konsole) instead? Add it to the main menu, too?

Comments? (on topic please, there are other tools and forums for support or bug reports)

The underlying abstract YaST UI library (libyui) already had most of what it took to make this happen: An abstract concept of properties for each widget class including setting, getting and enumerating those properties.

What I had to add was the table widget for the YDialogSpy window (of course) and to add some more fields of the YWidget base class of all YaST widgets to those properties (VStretch, HStretch, VWeight, HWeight). This has the added benefit that they can now also queried and changed as properties from YCP code.

BTW the funny thing about this YDialogSpy is that you can apply it onto itself: You can start another YDialogSpy from the YDialogSpy if you hit Ctrl-Shift-Alt-Y there. That’s how I colorized the widgets in the screen shots above.

Further reading
http://en.opensuse.org/YaST/Development/Misc/YDialogSpy

But if dialogs become more complex, it can get demanding to make them look good and – equally important – to behave well as the user resizes dialogs:

The YaST UI (user interface) engine now features a new debugging tool to make life easier for developers: YDialogSpy. In the Qt version, hit the magic key combination

Ctrl-Shift-Alt-Y

and you will get a YDialogSpy window like this:

This shows the widget hierarchy of the original dialog as a tree. Clicking around in that tree, you can highlight the corresponding widget (and its child widgets) in the original dialog (move the YDialogSpy window to the side first):

This can also make widgets visible you normally can’t see such as H/VSpacing, H/VStretch etc., and it shows the extent of alignment widgets (left, right, top, bottom) as well as layout boxes (H/VBox):

Availability

yast2-libyui-2.17-9 or later
yast2-qt-2.17.8 or later

The Future

This is just a first version, of course. Future versions will get a “Properties” table that can show certain values of the current widget. Maybe there will also be some (very limited) editing capabilities.

Stay tuned.

Further Reading

http://en.opensuse.org/YaST/Development/Misc/YDialogSpy
(With original-size screen shots)

Where KDE uses something like this:

GNOME would use something like this:

Which one is right? Which one is wrong? There is no real answer to that; it will always be more a religious debate rather than an objective discussion.

YaST Button Order

So, which button order to choose for YaST?

For historical reasons, we used the KDE button order. But this has repeatedly started the same heated discussions as for KDE vs. GNOME, with the same results — which is, no tangible result, only something along the lines of “because we says so” (and didn’t you always hate it as a kid when mom or dad said that?).

YaST should not favour one of the major desktops over another. YaST should work well for all users. So, YaST should adapt to the environment it runs in.

YaST comes in different flavours. There is the graphical version: The YaST Qt UI (user interface) engine (Side note: The YaST Qt UI is not in any way KDE specific; Qt just happens to be a great toolkit for making graphical user interfaces, and KDE happens to use it, too. There is not one single line of KDE-specific code in the YaST Qt UI.).

There is also the text-based version, the YaST NCurses UI.

As an alternative graphical UI, there is also the YaST Gtk UI which uses the same widget toolkit (Gtk) as GNOME. That brings YaST closer to the GNOME crowd. At least, that’s the theory. Yet, that alone didn’t improve the situation in any way for this button order issue:

YaST dialogs are specified in a subset of the YaST-specific YCP scripting language. Those dialog descriptions include input fields, list boxes, headings, etc. as well as the logical arrangement of all those user interface elements (widgets, even though that term has seen a lot of misuse recently). And buttons, too, of course.

So, the arrangement of buttons was still fixed. The YaST Gtk UI couldn’t really do anything about changing that button order so it looked more GNOMEish.

This is now different. We introduced a new widget ButtonBox that abstracts exactly that. A YaST module developer now only specifies “there is a ButtonBox, this is where I put my buttons, and the ButtonBox will arrange them as appropriate”.

…for users…

So now it is possible for the first time to use the proper button order for each environment: GNOME button order for the Gtk UI, KDE button order for the Qt UI.

But there is more.

…for power users…

The Qt UI can now demonstrate the fact that it’s not KDE specific. It checks what environment it runs in and uses the appropriate button order: GNOME button order when running in GNOME and KDE button order for KDE (or other window managers).

It checks the $DESKTOP_SESSION and $WINDOWMANAGER environment variables to figure that out. But of course power users can still override that and set the $Y2_BUTTON_ORDER environment variable to “KDE” or “GNOME”.

…for YaST developers…

Of course, such a change doesn’t come over night. There is a very large amount of YaST code. I counted 69 .desktop files in my /usr/share/applications/YaST2 directory; that corresponds to 69 YaST modules. On my machine I have 432000+ lines of YCP code below /usr/share/YaST2 . Now try to figure out how many YaST dialogs that might be, and how many of them need to be converted to use that new ButtonBox mechanism.

Obviously, it’s a lot of stuff to change. So the change should not hurt the people doing the change more than it absolutely has to. Don’t forget, it’s not just working hours that have to be paid; it’s also working hours that can’t be spent on implementing other features or on fixing bugs. And any change (even more so changing code at so many places) means a possibility to introduce new bugs.

…trying to be smart…

So this ButtonBox mechanism was made to be smart, to re-use existing information (things that are already there in the code), to make good use of existing conventions.

In principle, using something like the ButtonBox means having to tell it which logical role each button has so it can be arranged according to the current button order’s conventions: Which button is the positive confirmation of a dialog (it might be “OK” or “Continue” or “Yes”, but it might also be someting like “Save” or “Print”), which one is the “safe escape” (“Cancel”, but sometimes also “No”), which one is the “Apply” button or the “Help” button, and which ones are just “other” buttons. Remember, YaST is being translated into some dozen languages, so just hard-coding the English button labels won’t do.

But we already have a mechanism that maps (translated!) button labels to function keys, and that mechanism does something similar: There is a list of commonly used button labels and what function key is to be used (in the NCurses UI) for them. For example, “OK”, “Continue”, “Yes”, “Next” all map to the F10 key, “Cancel” to F9, “Help” to F1.

Extending that thought some more, it makes sense to assume an “okButton” role for buttons that are otherwise assigned the F10 key, “cancelButton” for buttons that get the F9 key, etc.

Buttons in YCP each are assigned a widget ID. That ID is the “handle” by which a button is being referenced; this is what the YCP application receives when it is informed that the user clicked that key. When specifiying a layout with buttons, this looks (slightly simplified) like this:

UI::OpenDialog( 
    `VBox(
         `InputField(`id(`name  ), "Name" ),
         `InputField(`id(`street), "Street" ),
         ...
         `HBox(
               `PushButton(`id(`ok    ), "OK" ),
               `PushButton(`id(`apply ), "Apply" ),
               `PushButton(`id(`cancel), "Cancel" )
               )
         )
);

As shown in this example, a button with the “OK” role typically has an ID like `id(`ok), a “Cancel” button has `id(`cancel), an “Apply” button has `id(`apply). So this information is used, too, to figure out what role a button has.

Of course, there are still situations where the system needs to be explicitly told what button has which role: It’s hard to figure out in a generic way that a “Print” button or a “Save” button has the “okButton” role in a dialog. In that case, the YCP developer has to change the code to look like this:

`PushButton(`id(`print), `opt(`okButton), "Print" )

…the normal case…

But in many cases, the migration is as simple as replacing the `HBox() (the horizontal layout box) holding the buttons with `ButtonBox():

UI::OpenDialog( 
    `VBox(
         `InputField(`id(`name  ), "Name" ),
         `InputField(`id(`street), "Street" ),
         ...
         `ButtonBox(        // This is the only line that changed
               `PushButton(`id(`ok    ), "OK" ),
               `PushButton(`id(`apply ), "Apply" ),
               `PushButton(`id(`cancel), "Cancel" )
               )
         )
);

…taming the masses…

Just imagine doing only this little change in 432000+ lines of code – of course, only where such a `HBox() contains `PushButtons, not just blindly replacing all `HBoxes. And just changing it is not all there is to it; each dialog has to be tested, too. And that alone is not so trivial: A dialog might easily only be shown in very exotic cases, so the developers doing the test have to recreate each of those exotic cases just to see the dialog.

You see, masses of code are a dimension of complexity all of their own. Little things that look trivial to do gain a whole new meaning. Everybody can do this change in one or two places, but try to do it in someting as big as YaST — without introducing new bugs that would wreck other people’s system.

Yet, we do those kinds of changes, typically unnoticed by the user community. And those little things are what, if added up, make or break a system’s quality.

We don’t take such decisions lightly. But we felt that in this specific case (the button order) the gain would be worth the pain: Users should feel at home in the tools we provide. And having the buttons where you are used to is part of this feeling at home.

Further Reading

http://en.opensuse.org/YaST/Development/Misc/Button_Order