Comments on: Tabbed Browsing for Packages

By: smspvdm

smspvdm — Wed, 28 Jan 2009 21:42:26 +0000

actually, i liked the old way best.

By: Stefan Hundhammer

Stefan Hundhammer — Wed, 28 Jan 2009 10:55:57 +0000

No change for the NCurses version for this: The NCurses package selector is an independent piece of code. We had done that years ago (for SuSE Linux 8.2 IIRC) so we don’t have to get down to the least common denominator for everything we do. Package management is just too complex for the generic (and thus simple) widget set we use elsewhere in YaST2.

By: Lars Vogdt

Lars Vogdt — Tue, 27 Jan 2009 20:01:09 +0000

+1 for using tabs in YaST – even if I like to see the ncurses screenshots before I make my final decision 😉

I liked the RPM-Groups view in the past – and hopefully this is a chance to get it back. Other people might have other preferenced views – they should be stored between the sessions.

Thinking about my current “main usage” of the sw_single module is searching for a special package. So I like to vote for a general available search box (like the addressfield in konqui) – perhaps in the top beside the “view” drop-down box? Perhaps such a textbox can also be used in combination with the “view” drop-down box…(no final idea, just a innovation impulse 😉 ?

By: Atri

Atri — Tue, 27 Jan 2009 19:55:14 +0000

Couldn’t agree with you more. But we could also have the toolbar show only 3 (or whatever the number of default tabs to show is) tabs and have a button for additional views (a drop-down just like the one you have in the current implementation). The advantage with the toolbar would be that you could implement other buttons (like I mentioned buttons for install pattern, uninstall pattern, etc.) context-sensitively (depending on which tab is active) to functions that in the current implementation require a (non-intuitive) right click. Just read your follow-up too, and very glad to know that this is going into factory soon. Any plans for back-porting this to 11.1 when it is ready, so that people could test this out for usability without having to use a factory OS?

By: Stefan Hundhammer

Stefan Hundhammer — Tue, 27 Jan 2009 12:33:25 +0000

Which part of the dialog would you be willing to sacrifice for those big buttons? Remember that in many cases the dialog will be full screen, so simply adding more stuff at any side will always mean sacrificing screen space that is currently used for something else.

By: Stefan Hundhammer

Stefan Hundhammer — Tue, 27 Jan 2009 12:30:59 +0000

I think I know what you mean. But look at the screen shots: Right now we have 7 different views already, not counting new ones or more exotic ones like “update problems” or even just “patches”. In the model you suggested, that would correspond to 7-9 toolbar buttons. Would it be possible to find icons for each of them that are self-explanatory for most users – or that users could even just remember? I have doubts. So there would have to be a textual description for each one, too. If there is only a text or an icon with a text right beside it, it would consume exactly as much screen space as the “all tabs shown” screenshot above, and it would suffer from the same problem: Overwhelming, intimidating, confusing. If we’d rely on pure icon toolbar buttons with tooltips, most users would have to wait for the tooltip to appear for each mouse movement – because the icons (in particular, in the size a toolbar button mandates) would not be enough information. I fear that most of those icons would just be colorful heaps of pixels.

The difference to a file browser is that for a file browser there are (a) much fewer icons (much fewer views) and (b) the icon can be a miniature visual representation of what the user will get. Both points don’t apply here IMHO.

By: Stefan Hundhammer

Stefan Hundhammer — Tue, 27 Jan 2009 10:57:06 +0000

“Incidentially” means “I am now beginning to talk about something completely else”, right? 😉

Still…

Somebody else had proposed that with similar arguments, and we had done that for openSUSE-10.2. It was a major disaster. Getting rid of that incredibly slow sqlite for openSUSE-11.0 brought a 1000% (factor 10) performance gain.

Plus, considering the complexity of the subject, do you really think it’s a good idea to let users manipulate the package data without any kind of sanity check (dependency resolving!) ? This would be a whole lot of accidents waiting to happen.

By: Christian

Christian — Tue, 27 Jan 2009 10:53:00 +0000

This is still possible with KDE4 Konsole but a little bit hidden. You can enable the buttons, when you edit your profile in the subwindow tab.

By: Stefan Hundhammer

Stefan Hundhammer — Tue, 27 Jan 2009 10:38:34 +0000

That’s the difference between the PackageKit package groups (a flat list) and the RPM group tags (a tree) that I mentioned. That one is already back in that prototype – see the screenshots above with the “View” pop-up menu. You’ll see “Package Groups” there (the flat PackageKit groups list) as well as “RPM Groups” (the old tree).

By: Bubli

Bubli — Mon, 26 Jan 2009 21:34:55 +0000

That feature is back in Factory since last week, in even better and more flexible way, since it is now configurable what pkg manager will do at the end: http://lists.opensuse.org/opensuse-factory/2009-01/msg00492.html
In fact, not only in Factory, there is some 11.1 version available in lslezak’s OBS home