"Create Snippet From Selection" context-menu entry

Milian Wolff mail at milianw.de
Fri Feb 12 12:15:06 UTC 2010

On Friday, 12. February 2010 12:54:50 Milian Wolff wrote:
> On Friday, 12. February 2010 08:12:38 Andreas Pakulat wrote:
> > On 12.02.10 01:41:22, Milian Wolff wrote:
> > > On Thursday 11 February 2010 23:46:23 David Nolden wrote:
> > > > Hi! I have a problem with this context-menu entry in the editor. The
> > > > problem is that it shows up _always_, and it shows up in a very bad
> > > > place, without any separation from the code-navigation features.
> > >
> > > If you tell me how I could separate it from the code-navigation
> > > entries, I'll happily do so. And regarding the "shows up always": I can
> > > change it to only show once a selection is actually available, but that
> > > imo decreases the discoverability of that feature immensely. What do
> > > others think?
> >
> > This part I kind of agree with David and actually you do too. We've had
> > very long discussions about the context menu in the treeview only
> > containing actions which make sense based on the current context. The
> > same applies here. If you want to improve discoverability of this
> > feature, then add a permanent action to the main menu (in
> > Editor->Snippets for example), that is greyed out without a selection in
> > the editor.
> Yes, after sleeping about it I came to the same conclusion.
> > > > Yes in same cases it's greyed out, but anyway I think this anyway is
> > > > not something you will be doing all the time. Such "random plugin"
> > > > entries should only show up if there is a real indication that the
> > > > user is actually using that plugin, for example it should definitely
> > > > not show up if I don't even have the snippet tool view added to my
> > > > mainwindow.
> > >
> > > Well, the question here is: Is a plugin supposed to be "working" or
> > > "activated" without it's view? In the snippets case it is not imo -
> > > just like you say, but what about other plugins? And this also imposes
> > > a bit of additional cruft on my side (i.e. track how many views are
> > > available and only show if the number of views is higher than 0.
> > >
> > > But actually snippets are "working" without a snippets view. You just
> > > can't edit them.
> >
> > FACK. Having plugins track how many views are open to check wether they
> > should add view-unrelated actions is simply wrong. If a plugin is loaded
> > all its functionality should be available.
> OK, what I'll do is:
> - only add context menu when selection is available

done, fixes most issues. But what I did notice is that e.g. "cut" "copy" 
"paste" and "undo", "deselect" are always shown as well, and get 
activated/deactivated as required.

> - somehow separate the action from the navigation actions (dunno if that
> really works with the current API).

Yes, as I feared there is no way to sub-group actions, e.g. "find uses" and 
"Show declaration" are added at two different places, hence no guarantee that 
they are listed consecutively.

We could:

- add a CodeNavigation group
- don't add navigation actions when there is a selection

Actually, the latter makes quite a lot of sense imo, but dunno what you guys 
think about it: When a user does has a selection and requests the contextmenu, 
it's relative to the selection (i.e. the cursor position). To test that: 
Select something with that stops in a declaration and then request the context 
menu in e.g. a comment or whitespace: You'll still see the "show declaration" 
etc. pp. So should we filter some actions when a selection is available?

> - add permanent action to menu

Milian Wolff
mail at milianw.de

More information about the KDevelop-devel mailing list