GEPS 019: Improved Sidebar and Split Views

From Gramps
Revision as of 14:21, 8 March 2010 by Bmcage (talk | contribs) (New page: Several ideas are floating around to change the main interface of Gramps for 3.3. This GEPS collects these ideas and must result in a design document =Background= Gramps 3.2 allows views ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Several ideas are floating around to change the main interface of Gramps for 3.3. This GEPS collects these ideas and must result in a design document


Gramps 3.2 allows views as plugins. The main organization is now: The sidebar is used to navigate to categories, a category can contain several views.


  • keep it simple for the user. There is no need to let him every time choose which person listview he wants to use. If he is in the person category, he uses the person listview he last viewed.
  • no overload of views. Organizing the views in categories avoids an overload in the sidebar, eg, we don't want the interface to look cluttered


  • The sidebar does not allow scrolling, while users can add plugins in new categories. In other words, we need to rewrite sidebar for the case there are more categories than fit on a screen
  • Users might not discover the other views because they are only a button in the toolbar, sometimes hidden among a lot of other buttons

use cases

  1. You are on the person view, and want to move to the pedigreeview, but last view in the category was the fanchart
  2. You want to minimize the sidebar so as to have more space on your screen for data
  3. You want to embed some gramplets next to a person view
  4. Add use cases here


  • menu: the top menu in Gramps. Reacts to the active view
  • toolbar: the toolbar of the active view
  • category sidebar: the bar to the left to select category/view in category. Every category has a workspace
  • workspace: the widget holding the are where views/filtersidebar can be shown. There is one workspace per category
  • main view: the view connected to the workspace (the left view or the top view)
  • secondary view: the extra view that can be added as per the users requirement.
  • workspace sidepane: a sidepane that can be added to a workspace to hold eg the filter sidebar which can be added to listviews to filter the lists.
  • active view: the view that has focus.

Desired outcome

  1. The new sidebar must be easy to use, and not in the way. There are ways to use split views, the sidebar should take this into account.
  2. We do not want to allow everything.
    1. We do not want to allow an eventview next to a noteview. First, the user must be protected from draining the resources of his computer. Second, we need to keep design simple. If there is no good use case, do not allow it
    2. We do not want more than two side by side views. It would be nice to allow the user to decide if vertical next to each other, or horizontal.

Several ideas for a reworked main interface. Focus is on usability, so how the use cases are handled

Design idea - 1

  • Sidebar as vertically placed buttons with vertical text to choose category (scrollable if needed). Context menu to go to view in category immediately.
  • Workspace to the right of sidebar
  • Toolbar to the top of workspace. Holds icons to switch view in category, icons to split workspace, icons defined by the active view

Design idea - 2


Design document

Viewmanager API

The viewmanager is the controller for the GUI elements on the main view. It holds the category sidebar, the workspace, the menu and the toolbar. These elements use the viewmanager API to do actions that concern them all. The broker is DisplayState with holds callbacks related to the GUI

Following methods are present

  • next_category
  • previous_category
  • goto_category_view(category_nr, view_nr=None): if view_nr given, go to that view in category, otherwise go to last used
  • next_view_in_category
  • previous_view_in_category

Best would be a signal before view will change, so all widgets can lock themselves and not emit other commands until the change is finished (??)



Sidebar API

A sidebar must do the following:

  • connect to view-changed from displaystate, and set it's content to match that
  • action on the sidebar that should change the view shown should call one of viewmanager.next_category/previous_category/goto_category_view/next_view_in_category/previous_view_in_category and then wait for view-changed to update itself
  • sidebar might have different representations for how above methods can be called.
  • otherwise, the sidebar is independent of the reset of Gramps.

Workspace API

  • How to split?
  • How to do the panes ?


point to the bug entries