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.
> This raises an important usability issue... with a
> 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
> 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 ?
michael.meeks(a)novell.com <><, Pseudo Engineer, itinerant idiot
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org