(In reply to comment #0)
> So I started good old Yast online update, and there all uninstalled updates
> were listed.
> I clicked Accept and it died without a word (and nothing in dmesg). I tried
> again with the same result.

Maybe there wasn't anything to update at all?
Please have a detailed look at the checkmarks - there are blue and black ones.
(IIRC the blue ones mean "already installed" and the black ones "to install".)

(In reply to comment #0)
> So I started good old Yast online update, and there all uninstalled updates
> were listed.
> I clicked Accept and it died without a word (and nothing in dmesg). I tried
> again with the same result.

It didn't die, it completed successfully. It didn't have anything to do because all patches were already installed, so it exited, quickly. But because the way it exited here is fast - too fast compared to YaST in general - users conclude that it crashed.

It's the same issue as described in this post:

http://lists.opensuse.org/archive/opensuse-factory/2006-Jun/0113.html

The UI urgently needs an improvement here. Too many users get it wrong, it's simply not user-friendy enough. There are dozens of reports like this outside Bugzilla.

Created attachment 88558 [details]
you window showing checked patches

(In reply to comment #1)
> (In reply to comment #0)
> > So I started good old Yast online update, and there all uninstalled updates
> > were listed.
> > I clicked Accept and it died without a word (and nothing in dmesg). I tried
> > again with the same result.
> 
> Maybe there wasn't anything to update at all?
> Please have a detailed look at the checkmarks - there are blue and black ones.
> (IIRC the blue ones mean "already installed" and the black ones "to install".)
> 
It doesn't look so. Many checked red items of installed stuff. I attach screen dump you-crash.png.

(In reply to comment #4)

Dag, all these patches _are_ already installed (that's why the checkmarks are blue, not black) and YOU did _not_ crash.

But it's still a bug IMHO. It is unacceptable that YOU behaves in such a way that many (really many) people *think* it crashes.

Btw. the screenshot shows that you have installed all kinds of patches you probably don't need. Yet another YOU usability problem, see the mailing list post mentioned in comment 2.

One for Stefan.

I hope we can add it for 10.1, even an english message would be helpful.

> Maybe there wasn't anything to update at all?
> Please have a detailed look at the checkmarks - there are blue and black ones.
> (IIRC the blue ones mean "already installed" and the black ones "to install".)
>
may be the problem is that the "tick" color is not visible? If I understand well, there are red, blue and black _text lines_ (in decreasing patches urgency, if I understand well) and also _color_ ticks? on my screen (good 20" one), with all ticks of the same (probably blue) color, I really can't say if they are blue or black, the with of the tick line is too small...
jdd

(In reply to comment #7)
> > Maybe there wasn't anything to update at all?
> > Please have a detailed look at the checkmarks - there are blue and black ones.
> > (IIRC the blue ones mean "already installed" and the black ones "to install".)
> >
> may be the problem is that the "tick" color is not visible? If I understand
> well, there are red, blue and black _text lines_ (in decreasing patches
> urgency, if I understand well) and also _color_ ticks? on my screen (good 20"
> one), with all ticks of the same (probably blue) color, I really can't say if
> they are blue or black, the with of the tick line is too small...
> jdd
> 

This is more than color. Color or icons in a user interface is only a complement to other informtion, and is used to speed up the perception when the user get used to the meaning of the color or icon. 
In present YOU the colors have a meaning that is hidden to the user or hard to find.
I think the proper solution would be two things:
1. add textual info about the meaning of the item and the checkbox forms both in the line and in the tooltip for the checkbox. Both the current status and what will happen according to the checkbox change should be included.
2. Filter the list so that only uninstalled and applicable item are visible by default, and let the user actively choose to show already installed patches for present packages and patches for not installed packages too (three filter states).

First of all, the subject is plain wrong. There was no crash.

First issue: The icons.

The status icons in the YaST2 Qt package selector (and thus YOU which is really just a slightly different view on the same data) are unchanged since SuSE Linux 8.1. We have been using those icons since that time.

Not only would it be unwise to change their semantics now (there is a large user base out there that is used to them and would be really confused if we changed it), you seem to have the wrong expectancy about what message they give you.

The idea is not primarily to show you the transactions that will be done - packages that will get installed, updated, deleted, or remain unchanged. This is only the secondary mission of those icons.

Their primary mission is to show you what your system will look like AFTER the changes. This is what users are most interested in, in particular for packages, but also for patches (or, for that matter, selections or patterns). For consistency, we use the same icons for all of those objects.

The normal use case for the package selector is to get your system into shape to do any specific task - like programming, or as a web server. For that purpose you want to see if you have all packages you will need for that task.
For the programming example, you want to make sure you have a compiler, a linker, autotools, libraries, include files. So you will switch to a view where you can see the relevant packages and make sure you have them all. Those you don't have yet you select - they will get a check mark as well. This makes it a lot easier to make sure you have all you need. Yet there is a visual cue to tell if you already have a package or if it will get installed - but only a very slight one. And that is the color. That is why this is intentional.

It's the same for patches. The most important thing is to make sure you have all you need - i.e., if all that are relevant will be on your system AFTER the changes. If that does not require any additional download or installation, all the better.

Second issue: Displaying only relevant patches.

Right now the patches list contains more entries than it could - that is true and known. We used to have that combo box in the old YOU patch selector: "installable patches", "installable and installed patches", "all patches". In the current version of YOU this combo box is not present.

This combo box would be a definitive improvement. It would restrict the amount of data to what even very impatient users (or those who don't care to read documentation or even only the available online help) can grasp in a couple of seconds.

We want that combo box back, but this is not so trivial. The underlying libraries for package management were completely exchanged, and that information (which patches would make sense for your current system) is not yet available in all relevant library layers. We are working on that.

See also

    http://svn.suse.de/trac/zypp/wiki/YaST-UI

(Novell internal only - sorry for that)

*** Bug 181583 has been marked as a duplicate of this bug. ***

*** Bug 185998 has been marked as a duplicate of this bug. ***

*** Bug 185997 has been marked as a duplicate of this bug. ***

*** Bug 186883 has been marked as a duplicate of this bug. ***

*** Bug 185995 has been marked as a duplicate of this bug. ***

This is a very annoying bug and not "enhancement" - just see the number of duplicates. I'm quite sure users would appretiate fix of this as a patch published on our update servers.

Stefan, you've written "We are working on that"  a month ago (comment #11), is there any chance this gets fixed?

Note tha ncurses version of package selector is able to show correct set of patches.

*** Bug 200835 has been marked as a duplicate of this bug. ***

I wrote bug 200835 which has been subsumed into this one. 
I agree that the ergonomics here are not brilliant, and I actually suggested two changes, only one of which has already been covered here.

1.  It should be possible to select "new patches only" for display
2.  It should be possible to "tick all" somewhere, rather than having to go
down the list explicitly

When it comes to 2., there are some "change all" options already in the menus, but it seems to me that they would, for example, change exsting patches.  I merely wanted to tick all un ticked patches instead.

(In reply to comment #21)
> It should be possible to "tick all" somewhere, rather than having to go
> down the list explicitly

That feature does not make too much sense because YOU already ticks the actually needed patches automatically by default. The user does not have to do anything else than selecting "Accept" in order to get all patches.

More specifically, the user does not have to go through the list and tick all the patches manually. Users who think they need to do that are confused by the other UI inconsistencies this bug is about - it's really not necessary and even wrong to do that.

Exception: The optional patches. These are not ticked by default, but there it's intentional that they must be selected explicitly. Otherwise they would not have been marked as optional.

Stefan, have you already thought about fixing this?

Yes. But we need some libzypp support for this. Some more status flags need to be exported to the UI - currently, the UI doesn not get that information.

Somehow ncurses UI is able to read such information, so the problem maybe is not in libzypp.

The Zypp::PoolItemStatus contains a flag "isNeeded". This is what should be evaluated here (but is not accessible to the UI). AFAICS this is not exactly what y2-ncurses does here - it only suppresses displaying patches that are already installed:

bool PackageSelector::checkPatch( ZyppPatch 	patchPtr,
				  ZyppSel	selectable,
				  string 	filter )
{
    ...
    if ( filter == "all"
	 || ( filter == "installed" && selectable->status() == S_KeepInstalled )
	 // FIXME Is filter installable correct? There was a method installable() before. Condition was:
	 // ( patchPtr->installable() && patchPtr->getSelectable()->status() != PMSelectable::S_KeepInstalled )
	 || ( filter == "installable" && ( selectable->status() != S_KeepInstalled ) )
	 || ( filter == "new" && ( selectable->status() == S_Install ||
				   selectable->status() == S_NoInst ) )
	 || ( filter == "security" && patchPtr->category() == "security" )
	 || ( filter == "recommended" && patchPtr->category() == "recommended" )
	 || ( filter == "optional" && patchPtr->category() == "optional" )
	 || ( filter == "YaST2" && patchPtr->category() == "yast" )

	 )	
    ...
}


But this is not the intent of what is needed here. We want to display those patches that make sense for the user to install - i.e., those for which he has any package installed. If you don't have OOo installed, you don't want to get or even see any OOo patch.

"isNeeded" (resp. "is_needed") is accessible for ycp via pkg-bindings (I check the flag in online_update_select.ycp), though I don't know if this is the way UI can access it.

Stefan is asking for the UI API in zypp to provide the information. pkg-bindings do not use the UI API.

*** Bug 213740 has been marked as a duplicate of this bug. ***

*** Bug 168758 has been marked as a duplicate of this bug. ***

See also fate #301272

Fixed for yast2-qt with V 2.13.69.

*** Bug 218937 has been marked as a duplicate of this bug. ***

Fixed for yast2-ncurses with V 2.14.1 / V 2.13.49.