Versions listing
Ricardo Cruz
In the following bug report, Stanislav asks us to rethink how we
present the version list (currently in the description box) because
he doesn't regard it as visible enough. In fact, he open the bug
report
thinking that feature had been removed since he had not found
it.
https://bugzilla.novell.com/show_bug.cgi?id=620513
It seems to me like simply swapping its position with the detail
box is good enough, because then the versions box
I applied this first fix immediately since it's a simple code and UI
change. Would like to know your opinions on the topic before doing
anything more drastic.
Cheers,
Ricardo
Ricardo Cruz
Stanislav posted as well his preferred suggestion fix, which consists
of moving the versions box to within the packages list:
https://bugzillafiles.novell.org/attachment.cgi?id=374346
Firefox makes use of that, and it's something we've discussed here
before.
Personally, I don't think it would satisfy well any demographic.
The seldom user of that feature often wants to install based on
repository not version, so he'd have to add the repository column as
well, and then click through every one of the versions entries to see
which repository belongs each.
For the ordinary user, we'd be providing ammo for him to shoot
himself in the foot, and it would break our straight-forward
presentation of recent / installed version pairs, and I'm not
even sure how the check-box would work when you e.g. selected
the installed version (or would that not be listed? but what
about orphaned packages?).
Stanislav also suggested we turn the list into a combo-box
as it was the case in 11.2:
https://bugzilla.novell.com/attachment.cgi?id=374313
I think it's clear a list is much nicer to use, but I guess
his idea is that with a combo-box, being much smaller than a
list, we wouldn't need to hide it below an expander.
I'm not sure it's a good idea usability-wise to immediately
have visible an install button and the versions combo. Seems
rather confusing so many different ways to get things done --
should I press the check-box, or the install button?
As it is, it should be pretty clear that the versions box is
a specialized widget for what Stanislav himself says is only
necessary for the "advanced user", and his use cases suggest
it is seldom so.
Again, I've made the versions box more visible by swapping
it with the details box, so it's now in the middle of the
overall information bar. Seems like it solves the initial
problem, and, of the choices evaluated, the usability
optimal one.
Cheers,
Ricardo
Ricardo Cruz
With regard to the suggestion to get rid of the combo-box
over the "Space available" info bar, dunno. We currently
show /usr by default, and / as a fallback, because it's
under /usr that packages are usually installed. But this
is sometimes not the case, so, since it doesn't take much
space, the fringe benefit may be enough to justify it.
Also, it's sometimes nice to be able to have the disk
space so accessible. I imagine some newbies may actually
pop up the software manager only to look at space usage.
Cheers,
Ricardo
Ricardo Cruz
By the way, you may also want to checkout what Stefan Hundhammer
(former qt plugin maintainer) wrote on this:
https://bugzilla.novell.com/show_bug.cgi?id=356410
I've already referenced that in the bug report.
His point is that if users are upset about the versions box
usability, then it means they are making a lot of use of it. If they
are using it a lot, it suggests we should look at other means
to accommodate their use case.
I find it quite a good point. Picking a version should be dealt
as a fringe case, and something to provide in the background.
If some users find it insufficient, rather than cumbersoming
the ordinary user by integrating it more heavily in the main ui,
we may want to look at other ways to cope with the fringe user's
needs.
Cheers,
Ricardo
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
C
> His point is that if users are upset about the versions box
> usability, then it means they are making a lot of use of it. If they
> are using it a lot, it suggests we should look at other means
> to accommodate their use case.
>
> I find it quite a good point. Picking a version should be dealt
> as a fringe case, and something to provide in the background.
> If some users find it insufficient, rather than cumbersoming
> the ordinary user by integrating it more heavily in the main ui,
> we may want to look at other ways to cope with the fringe user's
> needs.
The one time I really want to be able to select versions is with Wine.
I am periodically stepping up and down in the version of Wine... some
apps only work in 1.28, others in 1.45. Otherwise, it's usually...
only the latest version of any random app. Is that a corner case? :-)
Still.. one of my pet peves abut the repos is I can't select specific
versions to install.. I can either have the one from the original
install, or the latest from whichever repos I have that contain the
app... nothing in between.
C
Atri Bhattacharya
The one time I really want to be able to select versions is with Wine.
I am periodically stepping up and down in the version of Wine... some
apps only work in 1.28, others in 1.45. Otherwise, it's usually...
only the latest version of any random app. Is that a corner case? :-)
We should b careful in making it too easy for an end-user to choose between versions in my opinion, since it could lead the not-so-careful ones into big trouble [common example: install/upgrade MozillaFirefox to version from obs repository, and then firefox no longer starts; how many times have we seen that in the support forums?]
Still.. one of my pet peves abut the repos is I can't select specific
versions to install.. I can either have the one from the original
install, or the latest from whichever repos I have that contain the
app... nothing in between.
If I am correct in understanding you, I think this can be still done. For example if you click on the expander handle just beside the text "Versions" it should list all versions of the selected package available from all subscribed repos [see https://bugzillafiles.novell.org/attachment.cgi?id=374314]. You can select the one you would want, for example if you want to downgrade to a version from OSS repository after u find the Packman version not working, this is the place to do it from.
C
Bye.
--
Atri
--
yast2-gtk mailing list - http://groups.google.com/group/yast2-gtk
C
>> Still.. one of my pet peves abut the repos is I can't select specific
>> versions to install.. I can either have the one from the original
>> install, or the latest from whichever repos I have that contain the
>> app... nothing in between.
>>
>
> If I am correct in understanding you, I think this can be still done. For
> example if you click on the expander handle just beside the text "Versions"
> it should list all versions of the selected package available from all
> subscribed repos [see
> https://bugzillafiles.novell.org/attachment.cgi?id=374314]. You can select
> the one you would want, for example if you want to downgrade to a version
> from OSS repository after u find the Packman version not working, this is
> the place to do it from.
Ummm.. how to illustrate.... assume you have version 1.0 of some
random app from the DVD ISO, 1.2 from OSS, and 1.9 from Packman.
That's all you can install... what do you do if you want/need 1.7
(which was hosted on Packman at some point, but has been replaced by
1.8 and now is at 1.9). I have this scenario with Wine right now...
1.26 (I think) is the original install media version... 1.48 is what's
in the Wine repo (last I checked)... and I want 1.34. If I didn't
save the RPM for 1.34, it's not possible (with the configured repos)
to install 1.34 anymore.... or have I missed something? (I might have
the exact numbers wrong, but the point still works)
Anyway, this is beyond the original topic of this thread, and isn't a
YaST GTK issue.
C.
Atri Bhattacharya
Ummm.. how to illustrate.... assume you have version 1.0 of some
random app from the DVD ISO, 1.2 from OSS, and 1.9 from Packman.
That's all you can install... what do you do if you want/need 1.7
(which was hosted on Packman at some point, but has been replaced by
1.8 and now is at 1.9). I have this scenario with Wine right now...
1.26 (I think) is the original install media version... 1.48 is what's
in the Wine repo (last I checked)... and I want 1.34. If I didn't
save the RPM for 1.34, it's not possible (with the configured repos)
to install 1.34 anymore.... or have I missed something? (I might have
the exact numbers wrong, but the point still works)
Anyway, this is beyond the original topic of this thread, and isn't a
YaST GTK issue.
This is a repository side feature. If the repository maintains obsolete version x.1.1 after uploading x.1.2 of the package, then the package-manager will show you this obsolete version as well in the list. For example: the online-update repository keeps older versions of packages [in this case only delta packages but never mind], and the versions list does show these obsolete packages as well. But most repositories would, to conserve space on their servers, delete the older versions. Otherwise, I guess what you are suggesting is some kind of a caching feature then, which will enable one to cache packages in a local /tmp directory and allow you to install from there.
Bye
Atri Bhattacharya
Hi,
Stanislav posted as well his preferred suggestion fix, which consists
of moving the versions box to within the packages list:
https://bugzillafiles.novell.org/attachment.cgi?id=374346
Firefox makes use of that, and it's something we've discussed here
before.
I too don't think it would be wise to make it so easy for the average user to choose a version, and something like this interferes with the simplicity of the main package listing in my opinion.
It would be nice, though, to have a separator between the package description column and the version column, just to make the version column visually stand-out. This 2nd column could just be reserved for the versions listing, with the "Details" moved also to the left column/reworked within the 2nd column itself.
Again, I've made the versions box more visible by swapping
it with the details box, so it's now in the middle of the
overall information bar. Seems like it solves the initial
problem, and, of the choices evaluated, the usability
optimal one.
I am ok with the current design of the versions listing, except that it can be made a little more stand-out, more noticeable that's all. Btw, looks like this swap between the "Details" and "versions" looks like it has come too late for 11.3 [http://lists.opensuse.org/opensuse-factory/2010-07/msg00175.html], and changing this by online update wud only cause confusion.
Bye
Ricardo Cruz
> Ummm.. how to illustrate.... assume you have version 1.0 of some
> random app from the DVD ISO, 1.2 from OSS, and 1.9 from Packman.
> That's all you can install... what do you do if you want/need 1.7
> (which was hosted on Packman at some point, but has been replaced by
> 1.8 and now is at 1.9). I have this scenario with Wine right now...
> 1.26 (I think) is the original install media version... 1.48 is what's
> in the Wine repo (last I checked)... and I want 1.34. If I didn't
> save the RPM for 1.34, it's not possible (with the configured repos)
> to install 1.34 anymore.... or have I missed something? (I might have
> the exact numbers wrong, but the point still works)
Something cool I noticed about Ubuntu (and this may be true for opensuse
as well) is that when a new linux/kernel patch is released (or when
you upgrade Ubuntu), the kernel image you are currently using is left intact.
I've been riding on this feature (always telling grub to use the old kernel)
because brightness is broken for my eee-pc.
Package repositories should follow a similar policy. Always leave (at
least) the previous version behind so that users are not left in the cold
while some bug is being addressed.
Ricardo Cruz
In the post I referenced, I think Stefan was partially excusing himself
from improving the qt plugin version listing. (at the time at least
it functioned quite oddly)
But it's a good feature to have of course, and my point is that even for
those who use it, a separated widget (like qt/gtk have) is
easier to use, and can provide more information, than maladroitly
integrating it into the package list as a combo-box.
Cheers,
Ricardo
> --
C
> Package repositories should follow a similar policy. Always leave (at
> least) the previous version behind so that users are not left in the cold
> while some bug is being addressed.
Couldn't agree more.... and other distros are doing this in one form or another.
This has been discussed from time to time on the MLs... and is always
shot down. The experts don't understand why users can't just <insert
some complicated process> to keep their previous kernel(s)... and the
lesser beings don't understand or don't have time to mess about.
It's the same thing as the silliness around openSUSE being completely
incapable of setting up GRUB correctly and including menu entries for
other installed OSes... it used to be able to do it up until 11.1, and
now... it can't... even though other competing distributions have no
problem with it. (yes i know it's been explained, but.. the
explanation is a sad excuse... it's broken and won't be fixed anytime
soon).
In my opinion, it's all down to the experts losing touch with the user base...
Sigh....
C.
Ricardo Cruz
> I too don't think it would be wise to make it so easy for the average user
> to choose a version, and something like this interferes with the simplicity
> of the main package listing in my opinion.
> It would be nice, though, to have a separator between the package
> description column and the version column, just to make the version column
> visually stand-out. This 2nd column could just be reserved for the versions
> listing, with the "Details" moved also to the left column/reworked within
> the 2nd column itself.
If you click in the "Name" column in order to sort it, the background
gets darker.
Maybe we should set that effect by default? It certainly is sorted
by Name as it is.
>
>> Again, I've made the versions box more visible by swapping
>> it with the details box, so it's now in the middle of the
>> overall information bar. Seems like it solves the initial
>> problem, and, of the choices evaluated, the usability
>> optimal one.
>>
>>
>>
> I am ok with the current design of the versions listing, except that it can
> be made a little more stand-out, more noticeable that's all. Btw, looks like
> this swap between the "Details" and "versions" looks like it has come too
> late for 11.3 [
> http://lists.opensuse.org/opensuse-factory/2010-07/msg00175.html], and
> changing this by online update wud only cause confusion.
>
I think you've pointed to the wrong bug in that message. You
meant 620513 I think. :)
> Bye
>
> --
> Atri
> --
> yast2-gtk mailing list - http://groups.google.com/group/yast2-gtk
>
> --
> yast2-gtk mailing list - http://groups.google.com/group/yast2-gtk
>
----------------------------------------------------------------
Atri Bhattacharya
On Fri, Jul 9, 2010 at 18:25, Ricardo Cruz wrote:Couldn't agree more.... and other distros are doing this in one form or another.
> Package repositories should follow a similar policy. Always leave (at
> least) the previous version behind so that users are not left in the cold
> while some bug is being addressed.
This has been discussed from time to time on the MLs... and is always
shot down. The experts don't understand why users can't just <insert
some complicated process> to keep their previous kernel(s)... and the
lesser beings don't understand or don't have time to mess about.
The openSUSE update repository maintains all previous versions of kernels supported by the current distribution. So it should not be difficult to obtain an older kernel after a recent kernel update breaks ur machine in a minor way. Repositories don't really have infinite space to keep preserving older versions I guess.
It's the same thing as the silliness around openSUSE being completely
incapable of setting up GRUB correctly and including menu entries for
other installed OSes... it used to be able to do it up until 11.1, and
now... it can't... even though other competing distributions have no
problem with it. (yes i know it's been explained, but.. the
explanation is a sad excuse... it's broken and won't be fixed anytime
soon).
In my opinion, it's all down to the experts losing touch with the user base...
Sigh....
C.
--
Atri