Several design issues and HIGifications

1. Principal open design decision:

* should the gnome-app-installer be a normal application (including a menu) or a system preferences dialog (without menu like e.g. gnome-system-tools)?

* menu entry: should we use a command (this is the case now) or should we use the object like in other system preferences (e.g. "Applications" or "Software)? or two entries: one in the application menu named "Add/Remove Applications" and one in the system menu "Applications"? the possibility of removing apps should also appear in the menu entry. it is quite an inconsistency if you want to remove an app and have to click on "add applications".

* the expandable categories and the mix of categories and applications in one list make the list view quite bulky. to close and open another cateogory you have to scroll and search a lot. Separating the categories and the applications could help here a lot. The categories would stay in the old listview and work as filters for a separate list of applications placed at the right above the description. the dialog would be similar to the menu editors alacarte and smeg, synpatic or rhythmbox. a mockup is attached. the expander "more apps" could still be used in the applications listview. Furthermore this would also solve a bug in the current listview: the menu entries jump around if the entries are expanded

2. Suggestions to make gnome-app-installer more consistence with the GNOME desktop a.k.a the HIG:

a. Main window:

* the changes in the dialog are not instantly applied. so "apply", "cancel" and
  "ok" are the better buttons, instead of "close" and "apply". the pending
  changes dialog proofs that it is unclear would happens, if the "close" button
  is clicked. "does the user want to apply the changes or not?" "cancel" would
  make it clear.

* Move the search field above the category list view. it is common in the
  gnome desktop to put the search fields above the filtered lists. if we
  go for the separation of categories and applications the search field could
  move above the application list view. the categories would be filtered, too.

  putting the "search" and "clear results" and the general dialog buttons in
  one line does not represent their different nature.

* Use "instant filtering" in the search field. I don't know about the amount
  of data that is searched through. this would make the two buttons "search"
  and "clear" obsolete

In the case that we stay with the menu:

* Tighten up menus: a menu for one entry is obsolete, so move "Repositories" to
  the first one "file" and remove the menu "Settings"

* Rename "file" to "applications", since we handle applications and not simple
  files

* Move "Show unsupported applications" and "Show proprietary applications" to
  the menu. The decision to install unsupported or proprietary software is
  perhaps a one-timer for the user and not a decision that is made by every
  use of the installer. So there is no need to represent this function in the
  main window. Furthermore I think that non-free would be a better term instead
  of "proprietary".

* Add separators to separate the entries by function

* Rename "Quit" to "cancel". See above: instant apply and menu vs. preferences

Without the menu:

* remove "repository" completely from the dialog. we have a entry in the system
  preferences. the "repository" dialog is only used in seldom cases and no
  main function.

* put the "unsupported" and "proprietary apps" check button under the category
  browser if we go for the separation of categories and apps the category list
  isn't very long. so there is some unused place.

Beautifications:

* Add a border to the custom description widget

* Use the rules hint in the list view, since the two lined entries are quite
  hard to keep apart (is this the right English term?)

* Align the widgets

b. Dialog "Pending changes":

* do not use separators in the dialog and HIGify the alignments

c. Dialog "New Programs"

* Could we remove the dialog completely and add a notification to the
  notification bar? the dialog disrupts the work flow if you just apply
  the changes. alternatively we could disable the dialog in case of "apply"
  and enable it in the case of "ok".

* use the term "applications" instead of "programms". This is an inconsistency
  to rest of gnome-app-install

* remove separator and HIGification of alingments

* set position to "center on parents"

* do not use a window title

d. Dialog "initializing"

* use a non-technical wording

* remove window title

* wider borders