[posted to both devel and user lists, sorry to those on both]
Hi All,
Geany currently hard codes two actions to the <ctrl>-<left mouse down> input, "goto tag" if the click is over an identifier or "goto matching brace" otherwise.
This blocks the standard action of "add to selection" on <ctrl>-<left click> and <ctrl>-<left drag>. (See Gnome HIG http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse 10.1.2)
I did a quick check on my system and didn't find any application that did not comply with that guideline, so Geany is the odd one out.
Geany has not supported multiple selections so it hasn't been an issue (other than being non-standard and occasionally confusing users), but as there is a proposal to add support for multiple selections to Geany this non-standard behavior is now a problem.
As both actions now have a default keybinding (in Git version) I propose that the binding to <ctrl>-<left mouse down> simply be removed.
Cheers Lex
Hi,
Le 24/05/2012 03:27, Lex Trotman a écrit :
[posted to both devel and user lists, sorry to those on both]
Hi All,
Geany currently hard codes two actions to the <ctrl>-<left mouse down> input, "goto tag" if the click is over an identifier or "goto matching brace" otherwise.
This blocks the standard action of "add to selection" on <ctrl>-<left click> and <ctrl>-<left drag>. (See Gnome HIG http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse 10.1.2)
I did a quick check on my system and didn't find any application that did not comply with that guideline, so Geany is the odd one out.
Geany has not supported multiple selections so it hasn't been an issue (other than being non-standard and occasionally confusing users), but as there is a proposal to add support for multiple selections to Geany this non-standard behavior is now a problem.
As both actions now have a default keybinding (in Git version) I propose that the binding to <ctrl>-<left mouse down> simply be removed.
Your arguments looks sensible to me, as does the ones from Dimitar in the other thread (that this Ctrl-LMB has too many things bound to it). Of course it'd be better if we had configurable mouse bindings, but that's another story.
I also think that if we want to keep a mouse binding for "go to tag", we could choose something less common -- Ctrl+Alt, Super, whatever uncommon modifier. Do we want to keep one?
Finally, although it's probably obvious, the multi-select feature should have a keybinding.
Regards, Colomban
PS: funny thing, I just discovered that Mozilla apps did support multi-selection :)
On Fri, 25 May 2012 17:25:19 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
I also think that if we want to keep a mouse binding for "go to tag", we could choose something less common -- Ctrl+Alt, Super, whatever uncommon modifier. Do we want to keep one?
Maybe Alt+Click under *nix, and either Alt+ or Ctrl+ Click under Windows, depending on which modifier does rectangle selection. In my WM Alt+Click triggers move window, but after a short timeout.
Finally, although it's probably obvious, the multi-select feature should have a keybinding.
Cursor movement clears at least the primary selection, and multicursors clears all selections on arrow. Since the keyboard navigation is problematic, I'm not sure how useful a keybinding will be.
--
On Fri, 25 May 2012 20:50:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
IMO Replace and Toggle Case must be updated to work properly.
On Sat, 26 May 2012 10:59:46 +1000 Lex Trotman elextr@gmail.com wrote:
Just document them to only work on single selection would be ok.
Or block them for now if multiply selections exist? SCI_GETSELECTIONS.
"Rectangular selections are handled as multiple selections although the original rectangular range is remembered so that subsequent operations may be handled differently for rectangular selections. For example, pasting a rectangular selection places each piece in a vertical column." from Scintilla.
Doesn't say how its "remembered" though.
IIRC, the main (stream) and rectangular selections are stored as caret position + anchor position + caret virtual space + anchor virtual space, similar to ScintillaDoc.html#SelectionAndInformation api-s.
Rect selection was simply anchor + caret in scintilla v1. Not so fancy, but the current implementation is painfully slow after a few thousand lines (YMWV depending on the CPU).
On 29 May 2012 02:45, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 25 May 2012 17:25:19 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
I also think that if we want to keep a mouse binding for "go to tag", we could choose something less common -- Ctrl+Alt, Super, whatever uncommon modifier. Do we want to keep one?
Maybe Alt+Click under *nix, and either Alt+ or Ctrl+ Click under Windows, depending on which modifier does rectangle selection. In my WM Alt+Click triggers move window, but after a short timeout.
As you say alt+click is used by window managers so thats not appropriate (even if it has a timeout, hesitation will cause different behavior).
IMHO no Geany function is *so* important that it should be exclusively bound to mouse clicks, potentially blocking something else, so I don't think we should keep such a binding.
Finally, although it's probably obvious, the multi-select feature should have a keybinding.
Cursor movement clears at least the primary selection, and multicursors clears all selections on arrow. Since the keyboard navigation is problematic, I'm not sure how useful a keybinding will be.
The HIG defines ctrl-<cursor key> to move the cursor without modifying the selection, but unfortunately Scintilla binds these to move by word :( If that was fixed it would work ok.
--
On Fri, 25 May 2012 20:50:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
IMO Replace and Toggle Case must be updated to work properly.
On Sat, 26 May 2012 10:59:46 +1000 Lex Trotman elextr@gmail.com wrote:
Just document them to only work on single selection would be ok.
Or block them for now if multiply selections exist? SCI_GETSELECTIONS.
Maybe, but then how do you tell the user? dialog? etc IMHO it gets too much code for too little return.
"Rectangular selections are handled as multiple selections although the original rectangular range is remembered so that subsequent operations may be handled differently for rectangular selections. For example, pasting a rectangular selection places each piece in a vertical column." from Scintilla.
Doesn't say how its "remembered" though.
IIRC, the main (stream) and rectangular selections are stored as caret position + anchor position + caret virtual space + anchor virtual space, similar to ScintillaDoc.html#SelectionAndInformation api-s.
Maybe I'm having a bad day, but how does that tell us it is rectangular vs multiple?
Cheers Lex
2012/5/29 Lex Trotman elextr@gmail.com:
On 29 May 2012 02:45, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 25 May 2012 17:25:19 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
I also think that if we want to keep a mouse binding for "go to tag", we could choose something less common -- Ctrl+Alt, Super, whatever uncommon modifier. Do we want to keep one?
Maybe Alt+Click under *nix, and either Alt+ or Ctrl+ Click under Windows, depending on which modifier does rectangle selection. In my WM Alt+Click triggers move window, but after a short timeout.
As you say alt+click is used by window managers so thats not appropriate (even if it has a timeout, hesitation will cause different behavior).
IMHO no Geany function is *so* important that it should be exclusively bound to mouse clicks, potentially blocking something else, so I don't think we should keep such a binding.
agree on both
Finally, although it's probably obvious, the multi-select feature should have a keybinding.
Cursor movement clears at least the primary selection, and multicursors clears all selections on arrow. Since the keyboard navigation is problematic, I'm not sure how useful a keybinding will be.
The HIG defines ctrl-<cursor key> to move the cursor without modifying the selection, but unfortunately Scintilla binds these to move by word :( If that was fixed it would work ok.
--
On Fri, 25 May 2012 20:50:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
IMO Replace and Toggle Case must be updated to work properly.
On Sat, 26 May 2012 10:59:46 +1000 Lex Trotman elextr@gmail.com wrote:
Just document them to only work on single selection would be ok.
Or block them for now if multiply selections exist? SCI_GETSELECTIONS.
Maybe, but then how do you tell the user? dialog? etc IMHO it gets too much code for too little return.
i just updated "replace in selection" to correctly handle multiselections, it's on my enable-multislection branch
...but still i cannot find the "toggle case" command :/
davemds
"Rectangular selections are handled as multiple selections although the original rectangular range is remembered so that subsequent operations may be handled differently for rectangular selections. For example, pasting a rectangular selection places each piece in a vertical column." from Scintilla.
Doesn't say how its "remembered" though.
IIRC, the main (stream) and rectangular selections are stored as caret position + anchor position + caret virtual space + anchor virtual space, similar to ScintillaDoc.html#SelectionAndInformation api-s.
Maybe I'm having a bad day, but how does that tell us it is rectangular vs multiple?
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Tue, 29 May 2012 12:48:04 +1000 Lex Trotman elextr@gmail.com wrote:
I also think that if we want to keep a mouse binding for "go to tag", we could choose something less common -- Ctrl+Alt, Super, whatever uncommon modifier. Do we want to keep one?
Maybe Alt+Click under *nix, and either Alt+ or Ctrl+ Click under Windows, depending on which modifier does rectangle selection. In my WM Alt+Click triggers move window, but after a short timeout.
As you say alt+click is used by window managers so thats not appropriate (even if it has a timeout, hesitation will cause different behavior).
IMHO no Geany function is *so* important that it should be exclusively bound to mouse clicks, potentially blocking something else, so I don't think we should keep such a binding.
Well, yes. BTW, I checked SciTE on Win~1: Alt+Click does rectangular selection, and Ctrl+Click - guess what? - multi-selection. And if you click only, not drag, that's "multi-cursors".
Finally, although it's probably obvious, the multi-select feature should have a keybinding.
Cursor movement clears at least the primary selection, and multicursors clears all selections on arrow. Since the keyboard navigation is problematic, I'm not sure how useful a keybinding will be.
The HIG defines ctrl-<cursor key> to move the cursor without modifying the selection, but unfortunately Scintilla binds these to move by word :( If that was fixed it would work ok.
Isn't there a special case for text editing? Any editors I've seen use Ctrl+Arrow (if available) for word movement, and if you invoke File -> Open, type "tess test test" in the Location field, and try Ctrl+Arrow, it clears the selection, if any, or does word left/right, if none.
IMO Replace and Toggle Case must be updated to work properly.
Just document them to only work on single selection would be ok.
Or block them for now if multiply selections exist? SCI_GETSELECTIONS.
Maybe, but then how do you tell the user? dialog? etc IMHO it gets too much code for too little return.
Simply block them, as Cut/Copy/etc. are blocked if no selection... but that's not worth, they should be fixed anyway.
"Rectangular selections are handled as multiple selections although the original rectangular range is remembered [...]
Doesn't say how its "remembered" though.
IIRC, the main (stream) and rectangular selections are stored as caret position + anchor position + caret virtual space + anchor virtual space, similar to ScintillaDoc.html#SelectionAndInformation api-s.
Maybe I'm having a bad day, but how does that tell us it is rectangular vs multiple?
Oh, I replied literally. :) SCI_GETSELECTIONMODE, SC_SEL_RECTANGLE or SC_SEL_THIN.
[...]
The HIG defines ctrl-<cursor key> to move the cursor without modifying the selection, but unfortunately Scintilla binds these to move by word :( If that was fixed it would work ok.
Isn't there a special case for text editing?
Not that I could find.
Any editors I've seen use
Ctrl+Arrow (if available) for word movement, and if you invoke File -> Open, type "tess test test" in the Location field, and try Ctrl+Arrow, it clears the selection, if any, or does word left/right, if none.
My quick survey of editors/ides showed that they used ctrl-arrow for move by word because they didn't support multiple selections so they didn't need move without changing selection.
[...]
Cheers Lex
Hi All,
As there are rumblings about a release and as this is a UI breaker, I'll leave it until after the release to remove.
Cheers Lex
Am 24.05.2012 03:27, schrieb Lex Trotman:
[posted to both devel and user lists, sorry to those on both]
Hi All,
Geany currently hard codes two actions to the<ctrl>-<left mouse down> input, "goto tag" if the click is over an identifier or "goto matching brace" otherwise.
It also also mapped to rectangular selection which is a huge annoyance (it obviously doesn't work most of the time if a tag/matching brace is found).
I did a quick check on my system and didn't find any application that did not comply with that guideline, so Geany is the odd one out.
Eclipse uses ctrl+click for the same operation. However only if you press ctrl first and then move the mouse pointer a tiny bit. This seems to be necessary to enter some "make tags clickable html-like links" mode.
Geany has not supported multiple selections so it hasn't been an issue (other than being non-standard and occasionally confusing users), but as there is a proposal to add support for multiple selections to Geany this non-standard behavior is now a problem.
As both actions now have a default keybinding (in Git version) I propose that the binding to<ctrl>-<left mouse down> simply be removed.
Clearly the behavior needs to be changed, or at least changable by the user. And goto tag/matching brace needs to trigger on mouse-button-up to allow selection actions to take place. The multiple and incompatible mapping are a problem since a long time and really annoying indeed.
Best regards.