EggToolbarEditor

Bug: 120645

Completion: 0% done

Difficulty: Moderate

Owners: none

The existing code is a complete hack that needs to be re-done from the ground up.

Remaining tasks

Missing features

• The main problem with the current EggToolbarEditor is that it works by DND only, which is completely non-accessible. It needs to work with the keyboard as well.

  • Tinus: I thought toolbars were additional access methods for often-used actions which are already in the menu.

• Doesn't seem to handle orientation, EggEditableToolbar is derived from GtkVBox. It should be able to switch its orientation like GtkToolbar

  • chpe: That was done because sometimes you need to put more than one toolbar in one row (e.g. the spinner toolbar in Epiphany).

    • MattthiasClasen: I don't see why that should prevent handling orientation.

      • MarcoPesentiGritti: To handle groups of toolbar and orientation we probably need some sort of dock widget in gtk

        • Tinus: A container like the Windows rebar control would be nice for that. Note that at least for that implementation the Microsoft people found that users find it hard to manage all the toolbars, causing the ui to become a mess.

API issues

• Needs to be documented

• Not clear what the GtkUIManager is used for exactly

  • chpe: ATM only to get the actions its from various action groups. I want to try to make it use the UI manager to also add the actual toolbars for Epiphany 1.10.

• Why is a separate EggToolbarsModel necessary ?

  • chpe: The model is necessary because when you edit the toolbar in one window, we (Epiphany) want to reflect that change in the toolbars of all other windows too.

  • MarcoPesentiGritti: We used our own model because we was developing outside gtk+ and we couldnt access GtkUIManager model. Ideally we would just use that. Though chpe makes a valid point, didnt think about that in detail yet.

• It looks a bit odd that EggEditableToolbar and EggToolbarsModel only have a name-based API for the actual toolbars. It would feel much more natural to just interact with the children of the editable toolbar directly. E.g. instead of calling egg_editable_toolbar_show(), one could simply call gtk_widget_show() on the toolbar in question.

  • MarcoPesentiGritti: This is related to how we deal with multiple toolbars and toolbar groups. If we have some sort of docks, I'd imagine it would provide a way to access the toolbar widgets (by name, id or anything else...), then gtk_widget_show would be enough.

• Shouldn't the xml format be merged with the uimanager xml ?
  • chpe: That looks possible. We'd need to add the ability to get a subset of the UI manager's UI definition to a string, so we can save just the toolbars not the UI loaded from other files.

  • MarcoPesentiGritti: Definately. This is going to introduce the merging issue (see the point below).

Implementation issues

• Should use a named cursor
• Currently uses libxml for loading/saving, need to use GMarkup instead
• We need a way to deal with application specified toolbar layout changes. Some possibilities:
  1. Ignore changes, just keep user layout (Not that good, that may be important additions, or even big reworks some user would miss)
  2. When there is a change just restore the application specified layout (It could be annoying especially for apps with a lot of toolbars where layout changes could be frequent and small).
  3. Store the changes as a diff and apply it over application layout. (smarter solution but I'm not sure how well it would work in practice, especially for big changes)
• DND doesnt work very well for merged toolbars. For borders you won't know in which of the groups the user is dropping the item. We should probably ask UI people input on this.

Other issues

• Needs to be relicenced from GPL to LGPL