		   YaST2 Software Selection - Times Required
		  ===========================================

Author:  Stefan Hundhammer <sh@suse.de>
Updated: 2002-06-03



		      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.


*** 3d



** Basic infrastructure for new widget in libyui: 0.5d
** Bare-bone new widget in y2qt:		  0.5d
** Basic framework / layout / ... for y2qt:	  3d


Views
-----

** Tab widget for views, basic infrastructure:	0.5d


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.
  * 1d


- 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.

  * 2d


- Package search view

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

  * 2-3d


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.


** Simple version: 2d
** Basic add-ons: 3d



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.).


** 1d


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


** 2d


Actions
-------

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

** 1d


- 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

** 2d

- Save / load settings

** ?? 1-2d

- Toggle immediate dependency check

** 0.5d

- Check dependencies

** Dependency dialogs: 3-4d


Advanced (optional):

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

** 1-2d



			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.

** 0.5d


- 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.

** 0.5d


- New view for current pkg: Conflicts

  Displays a list of pkgs this pkg conflicts with.


** 1d (most included in "Requires" below)


- 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.

** 2d


- New view for current pkg: Required by

  Displays a flat list of pkgs that require this pkg.

** 1d (most included in "Required" above)



			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.

** 1d


- 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.

** 2d


- Context menu for directly setting the pkg status

** 0.5d


- 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

** 0.5d


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

** 2d



			  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

** Implementation: 1d
** Test: 1-2d


- 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.

** 2-3d


- New view for pkg list: Supported hardware

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

** 2d (can reuse parts of MIME type stuff above)



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

** 2d


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

** 2d (?)


- 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.

If this can be done with keywords: 1d
Otherwise: 3+ d




		       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.

** 1d


- 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).

** 2d


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

** 1-4d (depending on research)


- 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).

** ? 2-3d


- 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.

** ? 2-3d


- 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.

** 2-3d


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

** 3d


- Verify RPM (in installed system)

* 1d



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"


** Keyword view:    2-3d
** apply keywords:  2d
** test:	    3d

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


