https://issues.apache.org/ooo/show_bug.cgi?id=121960
--- Comment #13 from Ariel Constenla-Haile <[email protected]> --- (In reply to comment #10) > Arial, thanks for your thorough analysis. The ToolBarManager in framework/ > is applying some magic to command handling and dispatching. In the generic case (no magic), every toolbar item in the toolbar is controlled by a UNO based toolbar controller (even those in svx are UNO based, derived from svt::ToolboxController; see http://wiki.openoffice.org/wiki/User:Arielch/UI_Controllers#ToolBar_Controllers - rather old but still valid in the general overview), see framework::ToolBarManager::CreateControllers() where the toolbar is iterated, and for every item a toolbar controller is created. This means: a) getting feature state updates from the dispatch object queried at the XFrame as dispatch provider b) dispatching the UNO commnad with the dispatch object queried at the XFrame > Something that > I previously thought would be done for every command, not just the ones in > the toolbars. The SvtCommandOptions() singleton is used to determine > whether a command is disabled. If it is not disabled a command is > dispatched via XDispatch::dispatch() and not via SfxDispatcher::Execute(). SvtCommandOptions has two main uses in the framework module: a) when the dispatch providers (the Desktop and the Frame) get queried for a dispatch object, they check before if the command is disabled; if so, they return an empty reference; this has the effect that commands disabled by configuration are disabled in the UI: every item in every UI element has a controller that is a status listener at the dispatch object it queries from the XFrame, when it queries the dispatch provider for a dispatch object for its command, and the dispatch object is empty, the UI element controller disables its item. b) the UI element managers use SvtCommandOptions to look up the command of every item, and when the command is disabled, the UI elemenet manager hides it from UI element (and to save resources, does not create a UI element controller for this item). > I still have to find out whether the use of SfxDispatcher::Execute(), which > is used throughout the office for the majority of slot calls, generally > bypasses the framework command processing or if that happens only in the > sidebar panels. In this case I like the layers metaphor. The SfxDispatcher is used all over the office but at the lower level, for example when a shell executes an slot. The shell interface definition defines which function in the shell should be called to retrieve the slot status, and which to execute the slot. But on top of this, you have the UNO layer, whose "central" object the css.frame.XFrame. In the UNO layer, when you want to know the state of a feature, represented by a UNO command, you have to query for a dispatch object at the XFrame. If the XFrame returns a valid dispatch object, you add an status listener at this dispatch object to get feature state updates (the approach is the same in every UI element controller, though the behavior may vary: the menu items are only visible when the menu is activated, so there is no sense in keep listening for feature status updates, thus the menu item controller adds itself as status listener at the dispatch object, and removes itself immediately, just to get a single feature update. Toolbar and statusbar items controllers keep listening for feature updates at the dispatch object, because they are visible longer than menu items, and thus need to constantly reflect the state of the command they control). When the UNO layer provides a valid dispatch object, all will end up calling the functions defined in the respective shell interface, to retrieve the slot state, and to execute it. But here is where the Symphony implementation fails: everything is implemented in the old sfx2 framework, at the lower level, state retrieval and command execution is not mediated by the UNO frame; thus, when the UNO layer decides to return no dispatch object at all (because the command is disabled), or to return a different one (because it was intercepted), the sidebar is left out this game. The only way not to bypass the UNO layer is controlling *every item* in the sidebar by a UNO based UI element controller that controls a UI element identified by a UNO command (this point of the UNO command being very important to solve other bugs in the Symphony implementation, see below), not a class derived from the SfxControllerItem. In the end, the sidebar is a UI element too, it must follow the general UNO approach by the other UI element managers and controllers, not only in this particular issue, and the other related, the dispatch provider interception, but in a more general sense - I mean, there are several other bugs in the Symphony implementation that will go away by using the approach taken in the framework: - there is a duplication of strings to be translated: just take as example all the strings for the toolbox items in RID_SIDEBAR_TEXT_PANEL. In the framework, a UI element item has a command, you retrieve the item label from the command. Following this approach, you simply use a single string in XxxCommands.xcu - the sidebar items have HelpIDs of their own. This is a duplication too, someone will have to sit down and write help content so that pressing F1 on a sidebar item opens the respective help, and extended tooltips display it too. This can be simply solved by using UNO commands instead of brand new HelpIDs: for example, not HID_PPROPERTYPANEL_TEXT_TBI_BOLD but ".uno:Bold". Here again, the UNO command is the main entry point, the Online Help is able to retrieve the help text for a UNO command, no need to create new help content for the sidebar items that are already available on other UI elements - hard-coded shortcuts, as in STR_QH_BOLD, STR_QH_ITALIC, STR_QH_UNDERLINE, is error prone, will not reflect user customization. The toolbar manager uses other approach (see ToolBarManager::RetrieveShortcut used when the toolbar is constructed from the XML structure, in ToolBarManager::FillToolbar() ). In short, using UNO commands, at least where it seems more easy, in the sidebar's ToolBoxes, will solve several issues. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
