Forwarding to ml... On Tue, 2007-09-11 at 12:22 +0100, Michael Meeks wrote:
Hi Clayton,
To echo Magnus, thanks again for the feedback.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org