Principal open design decision

Normal app vs preferences dialog

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

An alternative would be to name the app menu entry "Add/remove..." and add a tooltip "Install and uninstall applications from your system" to avoid a very long and not good looking entry. So there should be no need for a second entry in the admin menu, since there are already synaptic and the software properties. This will result in quite a mess.

Separation of categories and 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 what 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

3. Mockup

A patched glade file with menbar (application style): http://librarian.launchpad.net/1513413/gnome-app-install-suggestions.glade

A patched glade file without menubar (dialog style): http://librarian.launchpad.net/1513393/gnome-app-install-no_menu.glade