			   YaST2 Software Selection
		          ==========================

Author:  Stefan Hundhammer <sh@suse.de>
Updated: 2002-05-22


				  Motivation
				 ============

- YaST1 is gone with SuSE 8.0 - no more fallback for those who don't like
  YaST2.

- YaST2's current single package selection has quite some flaws (see below).

- The number of packages is increasing, thus a good user interface to the
  single package selection becomes more and more important.

- It's questionable if the current way of presenting the data is really a good
  approach - the user easily suffers from information overflow.



	    Problems of the Current YaST2 Single Package Selection
	   ========================================================

- Double-click to select one item or to cycle to the next package state
  (don't install / install / update / remove)

- Need to click to view the package long description

- Poor performance

A generic (YCP) table widget is misused to serve this function as well, but it
had never been intended to do that. A custom widget for single package
selection could offer much more functionality along with much improved
ergonomics.


			       New Requirements
			      ==================

- Several installation sources must be supported (SLES!) - all of which can
  possibly contain different versions of the same packages.

  There must be some kind of priority or ranking between them: The base CD is
  superseded by a product CD which is superseded by a patch CD etc.

- The base software selections as well as the add-on selections must be
  viewable / accessible in the single package selection.



		      Bare Essential Features - Required
		     ====================================


Installation Source Selection
-----------------------------

Prior to entering the SW selection dialog, the user can select a number of
installation sources, for example

- SuSE Linux CD / DVD
- SLES Base CD
- Product CD
- Product Update CD
- FTP server
- other network servers (HTTP, NFS)
- RPMs on local hard disk

Installation sources get a ranking to indicate priorities so multiple versions
of the same pkgs on different sources can be supported.



Views
-----

The user can dynamically switch between those views:

- Add-on selections view (devlopment, multimedia, games, ...)

  The user can add or remove any number of them.


- RPM group tags view

  The RPM group tags are displayed as a tree.
  The corresponding packages are displayed as a list when a leaf in that tree
  is selected.


- Package search view

  Search form like in current YaST2:
  Search for pkg name, in pkg descriptions


The old base selections are just a special case of the system base plus
some predefined add-on selections, so there will be no exactly-one-out-of-n
choice of base selections (formerly "default", "default+office", "minimal",
etc.).




Pkg list
--------

In most views (at least for the RPM group tags view and for the pkg search
view) a list of packages is displayed:


For each pkg, the following fields are displayed in the list:

- pkg selection status
  for fresh installation:
  - [ ] not selected
  - [x] manually selected
  - [a] automatically selected because of dependencies

  for update:
  - [ ] currently not installed, will not be installed
  - [i] installed, keep that version
  - [u] update to newer version
  - [d] delete
  - [r] pkg renamed - the user cannot select this state. This is for cases
        where a new pkg (whith a new name) replaced an existing one.

- pkg versions - at least current (if pkg already installed) and preferred.
  The installation sources may contain any number of instances of the same
  pkg. The backend automatically selects the "preferred" version according to
  the installation source ranking.


Other pkg attributes like:

- pkg name

- pkg size

- pkg short description

and maybe more.


Pkg details
-----------

If screen space permits, detailed information about the current pkg is
displayed. If screen space is limited, the same information is displayed upon
user request (button press / key press).

In the simplest version, all the information in those views corresponds to the
"preferred" version of the current pkg. Advanced (optional) versions may allow
to switch from one version to another.


Pkg details views:

- Pkg long description. Both plain text and (simple - QSimpleRichText) HTML are
  supported. If the user interface supports displaying images, images are
  supported, too (screen shots etc.).

- Technical data
  The data "rpm -qi" provides (minus the pkg long description), e.g.
  pkg name, version, license, home page, source RPM, buld date, ...



Actions
-------

- Cycle pkg selection - multiple clicks may be required to
  switch from the curent state to the one desired

- Show pkg details description (if not already present on screen)

- Start pkg search (if pkg search view is selected)
  - search for pkg name
  - full-text search in pkg description
  - toggle case sensitive search

- Save / load settings

- Toggle immediate dependency check

- Check dependencies


Advanced (optional):

- Select all
- Deselect all
- Delete all
- Delete nothing
- Replace all
- Replace nothing
- Don't replace anything, delete instead
- Replace, don't delete



			Add-on Features 1 - Recommended
		       =================================

- New selection status for each pkg: "taboo"

  This excludes a pkg from automatic selection via dependencies - dependency
  conflict warnings will be issued instead. This way a user could make sure he
  doesn't get a specific package under any circumstances, in particular not
  through the back door via automatic dependency solving. Many sysadmins might
  be grateful for that: Set "xlibs" to "taboo" and make sure the new server
  doesn't get any part of X or KDE installed.

  ma+lnussel say:

  This is easy to implement in the backend if the requirement is included in
  the basic design.

  sh: For the frontend, it's trivial.


- New pkg status "don't touch" - for pkgs the user doesn't want to be updated
  or deleted in any case, such as pkgs he builds manually or gets from some
  other source.


- New view for current pkg: Conflicts

  Displays a list of pkgs this pkg conflicts with.


- New view for current pkg: Requires

  Displays a flat list of pkgs required by the current pkg along with
  indications which of those are already automatically selected anyway and
  which ones would be added by adding this pkg - plus the accumulated size of
  those new pkgs.


- New view for current pkg: Required by

  Displays a flat list of pkgs that require this pkg.



			Add-on Features 2 - Very useful
		       =================================


- New view for current pkg: File list

  Displays a list of files this pkg contains (rpm -qpl).
  This might require the installation medium the RPM is on to be inserted.


- Tools for direct status change without cycling through all possible values.

  The Qt UI should get tool buttons like in paint programs GIMP, CorelDraw
  etc. that directly set the pkg state to a defined value. The mouse cursor
  will change to indicate that - e.g. an arrow with a trash can to mark pkgs
  for deletion with one click etc.

  The NCurses UI should get one-character shortcuts to do the same - e.g. "i"
  for "install", "d" for delete etc.

  Cycling through all possible values more often than not sets intermediate
  states which cause unnecessary problems.

- Context menu for directly setting the pkg status

- Qt UI: Tool tips (balloon help) for different versions of the same pkg
  Display more info than just "V7.32" in column "CD" - e.g.

	V 7.32 from SuSE Firewall Update CD
	283k


- What if... - shows list of pkgs that will be installed, deleted, updated



			  Add-on Features 3 - Useful
			 ============================


- New view for current pkg: Versions per installation source

  Improved summary of all instances of the current pkg on all available
  installation sources, e.g.

	       V 7.32 SuSE Firewall Update CD	- 283k
	       V 7.30 SuSE Firewall CD		- 257k
	       V 6.0  UBL 1.0 Base CD		- 180k


- New view for pkg list: Supported MIME types

  Instead of the RPM group tags, display known MIME types and list pkgs that
  can handle the selected ones: Which pkgs support .png, which support MS Word
  .doc etc.

  The information is there - SuSE-WM already uses it.


- New view for pkg list: Supported hardware

  Similar to above: Which pkgs support CD recorders, sound cards etc.


- Save status of SW selection window: Current view etc.


- Pkg view: Replaced / obsoleted pkgs
  Show a list of pkgs that are replaced by other pkgs.


- New view for pkg list: Licenses
  (suggested by ke on [research] on 2002-05-22)
  View packages by license type: GPL, BSD, ...
  
  Maybe this should rather be a filter that works on top of other views.
  Otherwise we'd get too many pkgs in each category: Most pkgs (70%? 80%?) are GPL.




		       Add-on Features 4 - Nice to have
		      ==================================


- New view for current pkg: Change log

  Displays this pkg's change log.
  This might require the installation medium the RPM is on to be inserted.


- Icons in the pkg list to indicate the type of pkg (system, X, KDE, ...)

  The PDB team (Vladimir Nadvornik) say this info could automatically be
  generated from existing pkg dependencies (which pkgs are linked against KDE
  libs etc).


- Support for hyperlinks into the WWW from within the pkg description


- User Selections on Floppy: Users who usually add a few packages to one of the
  ready-made selections should be able to save those add-on selections to
  floppy so they don't forget them for future installations ("I always add 'xv'
  and 'selfhtml' to the 'default + office' selection).


- Support for run time dependencies: Some YaST2 modules require installation of
  additional packages only on invocation. This is typical for YaST2 config
  modules for special hardware (scanner, TV card etc.) - only when that
  hardware is being configured it makes sense to actually have the related
  software. RPM supports only hard requirements, thus YaST2 needs to do that.


- Reminder list: Let the user add pkgs he wants to explore at some later time
  put on a list that he will se on his desktop after the installation. This is
  useful whenever a user sees a pkg he doesn't know yet during pkg selection -
  people often install pkgs they find interesting, yet forget to really check
  them out some day. We have so many useful pkgs on our distribution that don't
  get the attention they'd deserve - this would be an add-on value for the end
  user for very little cost for us.


- Installation history view: Display the last n pkgs installed or pkgs
  installed since a specific date.
  (sugestion cfischer)

- Verify RPM (in installed system)



Package Keywords
----------------

Packages should get keywords to characterize them so advanced queries could be
possible.

Examples:

KMail:
- KDE app
- X app
- mail client
- network

Emacs:
- X app
- console app
- editor

File utilities (ls, cp, ...):
- base system
- system utilities
- shell program


Sample queries:
- Search ("KDE app" or "X app") and "mail client"


Problem: This requires constant work for either all pkg maintainers or some
responsible person who takes care of that.




			     Ideas for the future
                            ======================

- Advanced multimedia support for the pkg description: Sound and video clips

- msvec: Count of pkgs of each category / of pkgs total

- msvec: Select / deselect entire categories



Package Ratings
---------------

We have dozens of mail clients, dozens of editors etc. to choose from.

Packages should get a rating by other users (how?) or by the SuSE team to
support selecting one out of many similar packages (which mailer? which
editor?).

This might become a very political issue and it involves continued work to keep
it up-to-date, but the suggestion itself is now 2.5 years old and nothing has
happened since. YaST2 should at least provide the basic infrastructure to
support something like that.

Ratings could include:
- Feature set
- Stability
- Innovation
- Completeness
- Actively maintained
- Performance
- Resource consumption
- Suitability for console environment
- Suitability for X desktop environment
- Suitability for newbies vs. experts


Ratings should age to reflect the fact that they are gradually becoming
obsolete unless updated.



Application View vs. Packages View
----------------------------------

Currently, there are the old SuSE package series and the RPM group tags, and
the old SuSE package series will be dropped.

The RPM group tags are only one view on the overal set of packages.

Average users see many more packages than they are really interested in: They
frequently neither care for base packages that they need to install anywhere
nor are they interested in subpackages. YaST2 for example has 180+ subpackages,
yet it is one single logical package to most users.

Experienced users, however, may really want to see all packages.

Conclusion: We should offer multiple views on the overal set of packages. The
user should be able to switch views easily (e.g. click on another tab in the
GUI).


Application Categories
----------------------

Display pkg list as tree, divided by user-visible categories, e.g.:

Mail Clients
[ ] KMail
[ ] Pine
[ ] Mutt
...
Editors
[ ] KWrite
[ ] Emacs
[ ] Vim
...



User Package Preferences by Type
---------------------------------

The user should be able to adjust package selections to personal preferences,
e.g.:

GNOME -> Xlib -> KDE -> console

"I want a GNOME mailer. If there is none, give me an Xlib based mailer. If
there is none, a KDE based mailer. ..."






			      Package attributes
			     ====================

Attributes already available either from RPM or from the PDB:


[Required]	pkg name
[Required]	selection / installation status
[Required]	version (including build no.)
[Required]	installation source
[Required]	architecture
[Required]	requires
[Required]	provides
[Required]	conflicts
[Required]	obsoletes

[Required]	short description
[Required]	installation size
[Required]	RPM size
[Required]	license
[Required]	RPM group tags

[Required]	long description
[Required]	long description type (HTML / plain text)

[Recommended]	file list

[Recommended]	installation date (including time)
[Recommended]	source RPM name
[Recommended]	build host
[Recommended]	build date (including time)
[Recommended]	authors
[Recommended]	distribution
[Recommended]	relocations

[Recommended]	MIME types supported		(from PDB - for SuSE-WM)
[Recommended]	(special) hardware required	(from PDB)
[Recommended]	(special) hardware supported	(from PDB)

[Useful]	change log



Attributes that are not available yet, but could be generated automatically:

[Useful]	(basic) pkg keywords (X, KDE, ...) - generated from 'ldd'
[Useful]	run time dependencies
[Useful]	suggested pkgs



Attributes that are not available yet for which the information is
expensive to collect:

[Nice]		advanced keywords (system, network, ... + X, KDE, ...)
[Nice]		ratings:
		- feature set
		- stability
		- completeness
		- actively maintained
		- performance
		- resource consumption
		- suitability for console environment
		- suitability for X desktop environment
		- suitability for newbies
		- suitability for experts
		


Other attributes not available yet that require (moderate) manual work:

[Nice]		 video clip
[Nice]		 sound



