Draw and Impress have an multiselect.xml popupmenu file, while writer and calc didn't. The issue is that you have to add the multiselect specific commands (like group, arrange, distribute, ...) in graph, draw, ... popupmenu files. when you would have an multiselect.xml file the graph, draw, ... popupmenu files can have only specific actions for one selection and multiselect has the actions when you have more than one item select. this help maintanance of the code and make the files smaler.
Don't see the need/use case for that but let's discuss the idea.
when you have an action like distribute this action has to be added to all context menues cause when you select more than two item it will shown. If distribute was missing in e.g. OLE context menu than it was not available. if you have ONLY ONE multiselect.xml context menu when you select more than one item than you need all the actions that are needed only when you have more than one item selected only in this one file instead of > 5 files. this reduce in addition complexibility cause you don't have to think in each context menu like shape, ole, ... which actions should be shown when you select more than one shape, ... in addition it was available in draw and impress.
In an ideal world I support this idea, but for me it's a developer decision instead of a UX topic (first we're talking about the technical possibility and not about visual changes). I suggest to change keyword needsuxeval to needsdevadvise and let hear what devs say.
Is this topic still relevant, Andreas? Following Thomas' suggestion and remove needsUX.
From maintenance point of view I would recommend to reduce the different context menus to a minimum and have in all modules the same context menus not that it's different in each app (which mean also to know where which context menu do things). This bug can be closed if Maxim don't see an benefit.
I have some concerns about it: 1. It doesn't seem like there are many commands that apply to multiple selection but not to a single object. In fact, I can't think of anything besides the group command (there is also align sub menu in Calc which doesn't work for a single object, but hopefully it will be implemented sooner or later - see Bug 100394). Having yet another context menu just because one or two special commands, doesn't sound like something that will make maintenance easier. 2. There are two kinds of multiple selection: (a) Where all the selected objects are of the same kind (e.g. two shapes). (b) Where the selected objects are of different kinds (e.g. a shape and a form control). I think that for (a) it still makes sense to show the context menu which is associated with this kind of object, and not some generic "multiselect" menu. The use-case is applying the same attribute to several objects at once, e.g. currently it's possible to select several form controls, right click -> Control..., and set a background color for all of them. To keep this possibility after introducing a "multiselect" menu, we will need to add the form-specific commands to that "multiselect" menu (and hide them dynamically if no form control is selected), as well as other commands related to all other possible object kinds, resulting in one big menu file. Is it really something we would like to do? Of course, we can still introduce "multiselect" menu for type (b) only, but then it won't allow us to remove commands related to multiple selection from the other context menus. So while we might consider such possibility by itself, it isn't something that can reduce maintenance.
Thanks for the feedback Maxim. So it look like it's easier to no change anything which is ok for me. About commands for multiselect I think on - align - distribute - group and of corse - position - fill - line Thanks that you have a look into it.