Mailinglist Archive: opensuse-ux (15 mails)

< Previous Next >
Re: [opensuse-ux] yast-gtk package selector
  • From: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 09 Jul 2007 18:20:09 +0100
  • Message-id: <1184001609.8875.78.camel@xxxxxxxxxxxx>
Seg, 2007-07-09 às 09:32 +0200, Joerg Kress escreveu:
> On Thu, 2007-07-05 at 17:09 +0100, Ricardo Cruz wrote:
> > > The Package Selector window is also good, but to me needs
> > > improvement/changing:
> > > 1. Swop the columns of installed and available software as people
> > >    normally want to know what they have first before selecting an
> > >    upgrade to it.
> > > 
> >  That can be done -- but Alberto voted against -- anyone want to make
> > themselves heard and uneven the voting? :)
> Well, I'm sorry to tell you. But which column makes more sense on which
> side, seems to be driven by what I want to achieve.

 Yep, I would say people judge interface layouts based on their
perception of what the main purpose of the interface is. That's why you
have debates on music players whether the central widget should be the
playlist or information on the music being played.

 In our case, their position and size relatively to the window is
identical, and I find this to be merely a first impression thing, that
people get used pretty quickly, so I don't put the same importance on
it, as you seem to. I don't feel this is a flaw, certainly not to the
point that could possibly render the approach unworkable.

>  It was fun to
> realize ;-) So I can't uneven the vote.
> 
> But seriously. I think, a lot of people will have a similar feeling at
> some point. If you want to operate on your existing packages, one might
> want this list on the left. If you rather want to search for new
> software, it might be the pool that needs to be on the left. That's the
> main reason for me, why the 2-list approach might not work. But I'm
> happy to try it with our users for the next release and get some more
> data from them (i.e. feedback on whether it works for them).
> 
> Most of the points have already been raised:
>       * Don't keep installed packages in the list of installable
>         packages. It confuses (though this has been improved in the
>         latest version, where the install/upgrade button changes its
>         label).

 Could do, but it seems like people just aren't understanding, at least
at first, the approach used, so we could try to make that better
explicit.
 The Available pool should probably be labeled differently;
"Repositories Packages"?
 We could also make entries more humanly-readable: "X version 1 is
installed" - "X new version 2 is available at repo1". A one-to-one entry
approach might also be more clear and allow for better syncing: "X is
not installed" - "X version 1 is available at repo1".

>       * Some way to mark different states of a package (installed is
>         latest, installed has update available, installed is newer than
>         pool)

 The second one seems nice; lets highlight the version number. The
others don't seem important enough to bother the user; we can of course
make it explicit by offering some filter (ie. show me packages that are
no longer available in the repositories). Anyway, I would need to know
use cases.

>       * A way to manipulate the lists (maybe a menu), to restrict the
>         list to packages in a certain state or of a certain kind and
>         than be able to operate on this restricted list on the whole
>         (partially done with the "View Packages" field when selecting
>         languages. We now have 4 possible selections, maybe it's time to
>         switch to a drop-down menu.

 Not sure what you are thinking of, but sounds interesting. :)

>       * List packages by source (I use this very often to check packages
>         from build service).

 We could have an actual view mode for sources (aka repos)... We do have
something that I would think it better, since it integrates with the
view modes, and that could become part of the filters you talk on the
other point.
 In the Advanced expander, you can choose the package repos you want the
pool to be build from. I would rather improve this than to add another
view mode, since this lets you work on the existing views...

>       * Mark packages and install their -devel, -debug, whatever
>         packages.
> 
 Thats probably undesirable; some users may not even have compilers
installed, so that would drag all that stuff...

 What we do not do, and yast-qt can, is to propagate dependencies as you
install stuff. If you install "gtk-devel", "gtk" will of course also be
installed; you should be told about it once you hit Accept, but it
wouldn't be marked as such in the selector.
 We would need a more complete storage model to offer this. It seems
that Zypp changes package statuses, not offering a way to listen to
those changes, so we need to actively query for statuses and match that
with the ones on our storage.
 We probably also want to work on this to move away from Zypp's
uni-dimensional pool, and structure packages better, so we can build
models in no time.

> In the end, even if we stick to the two column approach, the GTK+ front
> end should be feature equivalent with the Qt front end.
> 
 If people want to we can offer a more yast-qt similar interface as an
option. GTK+ ensures we keep the data splitted from the list/tree
widget, so we would only need to touch interface code.
 Still, we have some Zypp code on the interface callbacks, so I would
want to work on the storage first, and make it a bridge for Zypp.

Cheers,
 Ricardo

> Cheers
> 
> -- 
> Jörg Kreß <jkress@xxxxxxx>
> YaST2 Development
> _________________________________________________________________
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
> 

-- 
To unsubscribe, e-mail: opensuse-ux+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-ux+help@xxxxxxxxxxxx

< Previous Next >
List Navigation