Re: [Gramps-devel] GEPS 019: Improved sidebar

[Nick H. <nic...@ho...>]

Benny Malengier wrote:
>
>
> 2010/4/6 Nick Hall <nic...@ho... 
> <mailto:nic...@ho...>>
>
>     Benny,
>
>     I'll answer your questions in bugtracker below.
>
>     Creating a base class for the sidebar plugins would be trivial -
>     it would consist of four methods raising NotImplementedError. Why
>     I brought up the subject of the Import, Export and Gramplet
>     plugins was because I wanted to be consistent.
>
>
> Well, Import/Export is the old way, Gramplet is the new way: a gpr.py 
> file and loading info via the pluginregister, loading when plugin 
> needed. That is, src/plugins/export/... is not using 
> gen/plug/_import.py, the gramps infrastructure uses it to create gui 
> interface. So those plugins are not the plugins, but wrappers around 
> the plugins :-)
> Some people would like PluginData class split up per plugin, but I 
> wanted all options together to be clearly visible to the maintainers 
> what could be reused for other plugins, and have one central 
> documentation on the gpr.py files.

I'll add an abstract base class. I just wanted to check that I was 
putting it in the correct place.

>
>
>     Import and Export inherit from Plugin whilst Gramplet doesn't. The
>     other base classes are in src/gen/plug but you suggested src/gui -
>     why not src/gen/plug?
>
>     More below ...
>
>     Benny Malengier wrote:
>
>
>
>         2010/4/5 Nick Hall <nic...@ho...
>         <mailto:nic...@ho...> <mailto:nic...@ho...
>         <mailto:nic...@ho...>>>
>
>
>         As part of GEPS 019 I have put a new sidebar in trunk.
>
>         http://www.gramps-project.org/wiki/index.php?title=GEPS_019:_Improved_Sidebar_and_Split_Views
>
>         This new sidebar contains sidebar plugins. At present there is
>         only one
>         plugin - the Category sidebar. The intention is for this plugin to
>         provide the same functionality as the old sidebar.
>
>         There are a few changes that the user will notice:
>
>         1. The name of the sidebar is displayed above the sidebar and
>         clicking
>         it will display a drop-down list. There will only be one entry in
>         this
>         list at the moment, but if more sidebar plugins are written,
>         then this
>         is the way they can be selected. The idea is to make it easier
>         to try
>         out new ideas for sidebars.
>
>         2. There is a close button next to the sidebar name.
>
>         3. The sidebar is now re-sizable.
>
>         4. The option to display the categories as tabs has been removed.
>
>
>         To write a plugin:
>
>         I have created a new plugin type called SIDEBAR. There is a new
>         folder
>         called src/plugin/sidebar where you can find the code for the
>         category
>         sidebar.
>
>         In the gpr files there are 2 new options: sidebarclass to
>         specify the
>         class, and menu_label to specify the name that will appear in the
>         drop-down list.
>
>         A sidebar class should implement the following methods:
>
>         __init__(self, dbstate, uistate)
>         get_top(self) - Returns the top level gtk widget.
>         view_changed(self, page_num) - Called when a page is changed
>         in the
>         viewmanager.
>         handlers_block(self) - Called before the viewmanager changes a
>         page.
>         handlers_unblock(self) - Called after the viewmanager changes
>         a page.
>
>         handlers_block(self) and handlers_unblock(self) are used in the
>         category
>         sidebar to block the button handlers. This may be useful to
>         prevent
>         recursive calls or to prevent spurious effects.
>
>         I have simplified the viewmanager code so that it no longer nests
>         notebooks. The code to handle categories is now contained almost
>         entirely within the category sidebar plugin.
>
>         Views are now loaded on demand and not all loaded at start-up.
>         This
>         should allow view plugins to be re-loaded without re-starting
>         Gramps,
>         but I haven't the code to remove a view yet. To do this, I
>         needed to
>         know the view icons before the view is loaded. I have added an
>         option
>         called stock_icon to the gpr files for views and the cateogory
>         icons are
>         now defined within the category sidebar plugin.
>
>         The following public methods are available in the viewmanager:
>
>         create_page(self, plugin_data, view_class)
>         goto_page(self, page_num)
>
>         I have not written a remove_page method yet.
>
>         There are 2 utility functions available in the viewmanager:
>
>         get_available_views() - Previously in grampsgui.py, returns a list
>         of all available views.
>         views_to_show(views, use_last=True) - Previously a private
>         function,
>         returns the current view in each category.
>
>
>         If you have any problems or comments then let me know - there is
>         plenty
>         of time to change or refine this concept.
>
>
>         Ok, I understand what the category drop down is for now.
>
>
>     The design was inspired from Nautilus. Although with a single
>     plugin it doesn't seem very useful, with more plugins I think that
>     its purpose will become obvious.
>
>
>         I would do the following:
>         * no close button, the sidebar can be hidden by reducing it's
>         space anyway. As tabs are not present, closing makes Gramps
>         unusable now.
>
>
> It is not nice with the present sidebar because the icons are smaller 
> than the combo, so the combo forces the sidebar to be bigger than it 
> should be. Then if you minimize the sidebar it messes up the top. Sure 
> we'll find a solution, I could add an ini setting for now to not be 
> annoyed by it :-).
>
>
>     This is useful for people with smaller screens. It is much easier
>     to click a button than to move a pane slider. It takes up little
>     space and I hope that its purpose is obvious. Applications like
>     nautilus, gedit and thunderbird use this approach, so it should be
>     familiar to users.
>
>
> I use none of those applications :-)
> The question is not if it is obvious, but if it is needed/usefull. I 
> agree to see how it evolves, but I would like to be able to create a 
> sidebar plugin to try things out and not see the close/plugin 
> selector, as it will not fit with the design I want to try. So an ini 
> setting for now I guess

You could just hide the HBox in your plugin, but then you would lose the 
functionality to change to another page.

>
>
>
>         * selection of type of sidebar, I find this combobox quite
>         annoying. At a minimum I would put it at the bottom,
>         preferably, I would not show it to users, and create another
>         mechanism to change sidebar.
>
>
>     I have seen applications that change sidebar pages in different
>     ways. Both tabs and combos are common, and different locations are
>     used. There is certainly one application I have seen that uses a
>     combo at the bottom (I can't remember what at the moment). It
>     would be interesting to get other peoples views on this. It would
>     be easy to change.
>
>
> Looking at firefox, they use a Sidebar submenu in the View menu. That 
> is one way to switch we should support. They seem to be using a gtk 
> checkbutton menubutton, but have it work a bit like a radiobutton 
> (setting one checkbutton unchecks the other)

Yes, I was actually thinking of firefox rather than thunderbird. I like 
the radiobuttons in the view menu in firefox.

Thunderbird has a slightly different way of changing sidebar pages. The 
combo is replaced by a heading of the current page and they have two 
buttons next to it to scroll backwards and forwards between pages.

>
>
>
>         I would think a user only sets his sidebar once, then does not
>         think about this anymore. In general, this possibility could
>         be offered by a sidebar plugin, but the default should not
>         allow for it in my opinion.
>
>
>     With the current design, the combo is the mechanism to change
>     between plugins so it is outside the plugins themselves. The
>     plugin gui is the rectangle below the combo and close button.
>
>     The number of times the user changes the sidebar page will depend
>     on the plugins available. I suggest we wait to see how things
>     develop. We can alter the page change mechanism later or even
>     remove it if we don't develop plugins that benefit from it.
>
>
>         As a consequence, the sidebar entry in the view menu could be
>         a submenu listing the possible sidebars to use. The gramps ini
>         file should contain the default sidebar to use, so we can ship
>         gramps with the sidebar which we believe is most user friendly.
>
>
>     I thought that the gpr files might define a default, but the ini
>     file is another alternative.
>
>     Your suggestions in the bugtracker:
>
>     1/make the buttons not expand, it does not look nice to have
>     buttons like that. If you do let them expand, make sure the icon
>     is centered
>
>     Yes, I'll look into this. The buttons should not expand. The icon
>     should be to the left of the text and centred when there is no text.
>
>     2/I don't like the close button much. Users will click it and not
>     know how to get the sidebar back. For the default sidebar, I would
>     just offer the menu way of removing the sidebar, so no close
>     button. Normal users need the sidebar.
>
>     All users need the sidebar. It is useful to be able to remove it,
>     but it should be equally easy to put it back again. I'll think
>     about this.
>
>
> yes, main thing is, should the gramps sidebar be closable from the 
> sidebar itself, or is it sufficient to close via the menu. An 
> alternative is close being equal to a minimize, with the sidebar going 
> to a button eg on the statusbar or somewhere else.
>
> About the close button, you should not use pack_end and pack_start on 
> the same hbox here. You should do all pack_end and add an empty 
> expanding label between the two. Then if I'm not mistaken, the close 
> button will not overlap the selection button, and the close button 
> will be the one that remains longest visible.

Good suggestion. It isn't quite right at the moment, so I'll give it a try.


Nick.


>
> Benny
>
>
>     3/ Also, if you close the sidebar, you cannot change categories
>     anymore with this setup. So if we allow sidebar to close, some
>     other way to navigate
>
>     I was anticipating complaints about the loss of the tabs, so I
>     have thought about tabs in the design. It would not be too
>     difficult to bring them back.
>
>     4/Further, the keybindings are not working:
>
>     Probably a bug introduced by this upgrade.
>
>     Regards,
>
>
>     Nick.
>
>
>         Benny
>
>
>
>         Regards,
>
>         Nick.
>
>
>         ------------------------------------------------------------------------------
>         Download IntelŽ Parallel Studio Eval
>
>         Try the new software tools for yourself. Speed compiling, find
>         bugs
>         proactively, and fine-tune applications for parallel performance.
>         See why Intel Parallel Studio got high marks during beta.
>         http://p.sf.net/sfu/intel-sw-dev
>         _______________________________________________
>         Gramps-devel mailing list
>         Gra...@li...
>         <mailto:Gra...@li...>
>         <mailto:Gra...@li...
>         <mailto:Gra...@li...>>
>
>         https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>