GEPS 019: Improved Sidebar and Split Views
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
- You are on the person view, and want to move to the pedigreeview, but last view in the category was the fanchart
- You want to minimize the sidebar so as to have more space on your screen for data
- You want to embed some gramplets next to a person view
- 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.
- Should a filter/query open up a new tabbed view?
- Should view widgets be able to send/receive all signals? Should that be configurable? For example, some gramplets can both send change_active signals and react to change_active signals. Should this be better thought about who is the controller, and who is along for the ride?
How to configure a split view?
We should look at reuse the Options (aka Menu, Report Options) for the Configure View. We already have a set of gui widgets for gramps that allow one to set items for the reports and tools, and I've been using these for Gramplets, too, for the last year or two. It might take a little work to integrate with a Configure, but it should be worth it. Otherwise, we have to duplicate all of those widgets.
We should also work on a hierarchical Configure paradigm. It should be the case that a top-level object composed of many, small widgets should ask each of the subwidgets if they want to be configured, and they can report back their options. Workspaces should ask views for options, and views ask gramplets, etc. One can do this manually (see sidebarviews.py) but we can do better.
We may also want to abstract the ui_definition, and make it part of this future Configure. This could be an object that is added to/subtracted from, and displays the "<ui>...</ui>" when needed.
Split View Prototype
There is a prototype in gramps-addons/branches/gramps32 and gramps-addons/trunk:
This uses the following decisions:
- A split pane is either in vertical, horizontal, or no-split orientation
- A split view is composed of exactly the regular view and (optionally) a gramplet view
- A config file is composed based on the "Splitviews_NAME_gramplets.ini" in the root of version directory
- orientation, columns, and pane divider position are stored in the [Gramplet View Options] section.
- config file is a gramplet config file (needs to be updated to use new config)
- Pane divider position should be "-1" until manually set.
- 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.
- We do not want to allow everything.
- 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
- 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
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
- goto_category_view(category_nr, view_nr=None): if view_nr given, go to that view in category, otherwise go to last used
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 (??)
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.
- How to split?
- How to do the panes ?
point to the bug entries