[opensuse-project] YAST software installer. - QT version vs GTK version
I have raised an issue regarding the new GTK version of the YAST software installer over on the user mailing list, and it was suggested I start a new thread here. There has been a lot of work done on YAST to give the Gnome version of the frontend a GTK look and feel. For the most part, the layout and workflow of all the components remained the same with the changes focused only on GTK theming. This is a good idea as it brings YAST in line with the Gnome look and feel for the Gnome users. One change stands out though, the changes made to the software installer component. The Gnome version of the YAST software component has been completely reworked. From what I read, there were several very valid reasons for this, including (among many reasons): - a simplification of the interface - the QT based backend is in dire need of rework The result is a GTK YAST component that is radically different from the QT version. This raises an important usability issue... with a totally different software maintenance component between Gnome and KDE, there is a major impact to documentation, support and the development path. Documentation must now maintain conditional procedural information (If Gnome then do this, if KDE then do the other). Support must consider which window manager the customer is using and adapt their support processes accordingly. Development must now continue down two paths (development resources are hard to come by as it is... for example, a reason given for using only Tango icons in YAST was a lack of resources to maintain 2 icon sets). While these kinds of changes are important, and in many cases badly needed to keep openSUSE a viable product, this impact is critical to consider. I would like to propose a couple of things to help the improvement process. 1. Whenever a major change is introduced that radically changes the workflow of core components (like YAST), there must be a simple and clear way to switch between the new way of working and the old. My preference is to keep the old default in place, but make it clear there is a new tool in place that is being tested and provide the user the choice to switch. This is very important to people like myself who support openSUSE in the real world because there are massive processes built up around existing workflows. A radical change like the GTK software installer costs time and money for people who now have to contend with this change. 2. If a radical change or improvement is in the works for a YAST component, then that change must include BOTH the GTK and QT versions. (or as a bare minimum, there must be a plan to synch the two tools within one release cycle). The GTK and QT versions of YAST need to be in synch.... not in look, but in workflow. The same options need to be present in BOTH versions of YAST. If a major change is planned for QT, then the GTK version needs to reflect that change as well, and vice versa. 3. The GTK software installation component of YAST should either be reworked to bring the workflow back in line with the existing QT one, or the QT version needs to be reworked to bring its workflow in line with the GTK one. Of course this would also include usability improvements and fixing the old backend (something both versions are in real need of). I am sure that there is more I can add here, but these 2 points would go a long way towards keeping openSUSE (and SLED/SLES) consistent and usable. YAST is a highly important and critical part of openSUSE. It is this tool that really makes openSUSE stand out as a better choice (in addition to the very professional "polish" that we give the product). This critical part of openSUSE must remain consistent regardless of theming for one one window manager or another. C. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Clayton, On Tue, 2007-09-11 at 09:11 +0200, Clayton wrote:
I have raised an issue regarding the new GTK version of the YAST software installer over on the user mailing list, and it was suggested I start a new thread here.
There has been a lot of work done on YAST to give the Gnome version of the frontend a GTK look and feel. For the most part, the layout and workflow of all the components remained the same with the changes focused only on GTK theming. This is a good idea as it brings YAST in line with the Gnome look and feel for the Gnome users.
One change stands out though, the changes made to the software installer component. The Gnome version of the YAST software component has been completely reworked. From what I read, there were several very valid reasons for this, including (among many reasons): - a simplification of the interface - the QT based backend is in dire need of rework
The result is a GTK YAST component that is radically different from the QT version.
This raises an important usability issue... with a totally different software maintenance component between Gnome and KDE, there is a major impact to documentation, support and the development path. Documentation must now maintain conditional procedural information (If Gnome then do this, if KDE then do the other). Support must consider which window manager the customer is using and adapt their support processes accordingly. Development must now continue down two paths (development resources are hard to come by as it is... for example, a reason given for using only Tango icons in YAST was a lack of resources to maintain 2 icon sets).
While these kinds of changes are important, and in many cases badly needed to keep openSUSE a viable product, this impact is critical to consider.
I would like to propose a couple of things to help the improvement process.
1. Whenever a major change is introduced that radically changes the workflow of core components (like YAST), there must be a simple and clear way to switch between the new way of working and the old.
My preference is to keep the old default in place, but make it clear there is a new tool in place that is being tested and provide the user the choice to switch. This is very important to people like myself who support openSUSE in the real world because there are massive processes built up around existing workflows. A radical change like the GTK software installer costs time and money for people who now have to contend with this change.
2. If a radical change or improvement is in the works for a YAST component, then that change must include BOTH the GTK and QT versions. (or as a bare minimum, there must be a plan to synch the two tools within one release cycle). The GTK and QT versions of YAST need to be in synch.... not in look, but in workflow. The same options need to be present in BOTH versions of YAST. If a major change is planned for QT, then the GTK version needs to reflect that change as well, and vice versa.
3. The GTK software installation component of YAST should either be reworked to bring the workflow back in line with the existing QT one, or the QT version needs to be reworked to bring its workflow in line with the GTK one. Of course this would also include usability improvements and fixing the old backend (something both versions are in real need of).
I am sure that there is more I can add here, but these 2 points would go a long way towards keeping openSUSE (and SLED/SLES) consistent and usable. YAST is a highly important and critical part of openSUSE. It is this tool that really makes openSUSE stand out as a better choice (in addition to the very professional "polish" that we give the product). This critical part of openSUSE must remain consistent regardless of theming for one one window manager or another.
C.
Just wanted to say thanks for this email and the way you expressed your thoughts. I'm cc'ing Michael Meeks as he's not subscribed to this list. Cheers, Magnus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi Clayton, To echo Magnus, thanks again for the feedback & taking the time to write the summary. Personally I was surprised your comments were not more of the form "this new thing is not usable" ;-) since there are a number of bugs we are currently fixing here & hope to have in the next beta. I'm certainly not happy with the current state. Boyd Timothy is working away at it as we speak :-) On Tue, 2007-09-11 at 21:03 +1000, Magnus Boman wrote:
The result is a GTK YAST component that is radically different from the QT version.
Sure.
This raises an important usability issue... with a totally different software maintenance component between Gnome and KDE, there is a major impact to documentation, support and the development path.
Hokay, agreed - however this is basically true of all existing Gnome / KDE differences :-) how do I launch applications ? where is the menu ? how do I configure the networking ? change the screen size ? etc. So, agreed - but we're used to this problem in a lot of areas I think.
Development must now continue down two paths
And yes there is a cost to this of course.
1. Whenever a major change is introduced that radically changes the workflow of core components (like YAST), there must be a simple and clear way to switch between the new way of working and the old.
I agree that it would be ideal to expose the old software installer for those people that like it & are familiar with it. I'm still a fan of using the (fixed) new installer by default, since IMHO it is rather simpler to use. The technical problem here is that by design the Qt package installer was an integral part of yast2-qt, while in many ways being quite a separable hunk of code. I am hoping that Stefan's nice re-work of the yast2 UI backend code will (as one result) allow us to de-couple the Qt package installer from the frontend, and have it run as a standalone application of some sort. Is that so Stefan ? ie. currently the choice foisted on us by the underlying design is (nearly): either no Gtk+ integration at all, or all of it including the package selector.
A radical change like the GTK software installer costs time and money for people who now have to contend with this change.
Of course, any chance is costly; I'd personally like to help with that by increasing the performance & ease of use of the new solution, and understanding the use-cases you have for it. IMHO conceptually, installing packages should not require intensive training :-)
2. If a radical change or improvement is in the works for a YAST component, then that change must include BOTH the GTK and QT versions. (or as a bare minimum, there must be a plan to synch the two tools within one release cycle).
As you point out, this is the case for ~virtually everything except the package selector; which is unfortunately an oddity here; and I hope we can provide in parallel the old style tool you're obviously familiar with for the next release.
3. The GTK software installation component of YAST should either be reworked to bring the workflow back in line with the existing QT one, or the QT version needs to be reworked to bring its workflow in line with the GTK one.
At root this cuts to the heart of some Gnome vs. KDE philosophical differences I think, which are prolly best not discussed. As a caricature: one side rejoices in exposing complexity to the power user, and at the other extreme the other would prefer a computer to have just one button labelled "make money" that can be clicked repeatedly ;-)
Of course this would also include usability improvements and fixing the old backend (something both versions are in real need of).
AFAICS, the backend is libzypp and is a separate issue really; the installer is mostly UI AFAICS. Does this make some sense ? Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Den Tuesday 11 September 2007 13:40:53 skrev Michael Meeks:
This raises an important usability issue... with a totally different software maintenance component between Gnome and KDE, there is a major impact to documentation, support and the development path.
Hokay, agreed - however this is basically true of all existing Gnome / KDE differences :-) how do I launch applications ? where is the menu ? how do I configure the networking ? change the screen size ? etc. So, agreed - but we're used to this problem in a lot of areas I think.
Absolutely agree with mmeeks. There are definitely some costs. But there are also benefits - the "one-size-to-fit-them-all"-approach of our biggest competitor, is one of their weaknesses. Offering different solutions for different users is a strength in the long run - albeit more costly. And come on, how difficult is it to adapt from one package manager to the other. Joe Sixpack will figure it out in seconds.. the basic concept for the basic tasks is the same for any package management gui on any distro.. search -> select/remove package -> accept.. Let's not try to squeeze everyone into the same box. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Absolutely agree with mmeeks.
Me too.
There are definitely some costs. But there are also benefits - the "one-size-to-fit-them-all"-approach of our biggest competitor, is one of their weaknesses. Offering different solutions for different users is a strength in the long run - albeit more costly.
I agree.
And come on, how difficult is it to adapt from one package manager to the other. Joe Sixpack will figure it out in seconds.. the basic concept for the basic tasks is the same for any package management gui on any distro.. search -> select/remove package -> accept..
I also don't see where is the problem in having two different interfaces to the package manager. That's the whole point in my opinion. GNOME and KDE are different environments with different philosophies and different users. So having a perfect GTK clone of the YaST-qt tools is not the point: a theme would have been enough for that. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Alberto Passalacqua
I also don't see where is the problem in having two different interfaces to the package manager. That's the whole point in my opinion. GNOME and KDE are different environments with different philosophies and different users. So having a perfect GTK clone of the YaST-qt tools is not the point: a theme would have been enough for that.
Disagree, YaST *is* YaST, just as previously presented that Firefox is Firefox. YaST should appear similarly even if it were presented on windoz, and have the same functions. YaST *should-be* YaST, not a KDE apt or a GnOme apt. The function of YaST is to configure/install the openSUSE operating system, not to function as a window manager sub-system. gimp works/looks the same on kde/gnome/xfce/windoz...... AS It SHOULD and so should YaST! -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Disagree, YaST *is* YaST, just as previously presented that Firefox is Firefox. YaST should appear similarly even if it were presented on windoz, and have the same functions.
Exactly. Similarly. And Firefox is the right example. It's _different_ on Windows and Linux. Check menu entries and options, for example. What counts is it does the same things. Moreover, we are speaking of a package manager, and who have root's access to the system is supposed to know how to use it, considering that its interface is quite simple. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I also don't see where is the problem in having two different interfaces to the package manager. That's the whole point in my opinion. GNOME and KDE are different environments with different philosophies and different users. So having a perfect GTK clone of the YaST-qt tools is not the point: a theme would have been enough for that.
My point was not about GTk vs QT and which was better or worse... it was about the change in workflows. Do you run one computer with one window manager? or do you administer multiple computers across multiple locations? If it was one computer with one window manager, I could care less, but the issue arises when you are dealing with more than one wm on multiple computers... If you guys who are disagreeing here read carefully what I wrote, I am not advocating GTK over QT, or QT over GTK. I am saying that the tool itself needs to have a common workflow regardless of window manager. Does it make logical sense to develop a core tool (that should NOT be window manager specific) in two different paths? YAST should not be KDE or Gnome or any window manager centric. It is a common tool for setting up and administering openSUSE.. not Gnome.. not KDE. This is the issue. C. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
If you guys who are disagreeing here read carefully what I wrote, I am not advocating GTK over QT, or QT over GTK. I am saying that the tool itself needs to have a common workflow regardless of window manager. Does it make logical sense to develop a core tool (that should NOT be window manager specific) in two different paths? YAST should not be KDE or Gnome or any window manager centric. It is a common tool for setting up and administering openSUSE.. not Gnome.. not KDE. This is the issue.
I understood that, and my points have nothing to do with the Qt vs GTK version. YaST-qt and YaST-gtk are identical in all parts, with the main exception of the installer module. Both the GTK and the Qt installer modules have similar workflows: they can't be much different, considering they use the same backend and that they have to do the same basic task. As Martin said, the workflow, intended as the operations a user has to do to install packages, is very similar. In Yast-Qt installer: * Search for the package you need. * Click on the check-box to select it. * Click on Accept to install it. * Accept additional dependency-releated packages. * Answer to the question "Do you want to install other packages?" In Yast-GTK installer: * Search for the package you need. * Select it in the pool on the left and click on the arrow to move it in the pool on the right. * Click on Accept to install it. * Accept additional dependency-releated packages. * Answer to the question "Do you want to install other packages?" There is _one_ different step, which shouldn't really be an obstacle for a system administrator. There are minimal differences also in how you select the visualisation of the packages (patterns, full list, ...), or you show package properties, but they are all very intuitive. I would agree with this consistency issue if it were wider, with a completely rewritten YaST, without the possibility of switching among the different versions. But considering it affects mainly one module, in a practically not substantial way, with the possibility of using the version you like changing a single line in a configuration file, as explained in the help, I really don't think this is an issue. With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (6)
-
Alberto Passalacqua -
Clayton -
Magnus Boman -
Martin Schlander -
Michael Meeks -
Patrick Shanahan