Hi,
It was requested in the mailing list, twice IIRC, for double-clicking into Compiler or Messages tab to not only open the file and seek into it, but also focus the editor window. That makes sense, IMHO, since pressing Space opens and seeks, while Enter opens, seeks and focuses. It's a small patch, and I think it also improves the code a bit - using a gboolean looks better to me than passing a fake key 0 and constantly checking for enter-or-return.
Seeking into the file 3 times (release, 2button press, release) is not very good, but the subsequent seeks are quick. At least I'm not able to click so fast as to cause any delay.
Le 10/08/2011 12:02, Dimitar Zhekov a écrit :
Hi,
Hi,
It was requested in the mailing list, twice IIRC, for double-clicking into Compiler or Messages tab to not only open the file and seek into it, but also focus the editor window. That makes sense, IMHO, since pressing Space opens and seeks, while Enter opens, seeks and focuses. It's a small patch, and I think it also improves the code a bit - using a gboolean looks better to me than passing a fake key 0 and constantly checking for enter-or-return.
Looks good. Though, why handling button-press rather than button-release for getting double clicks?
Seeking into the file 3 times (release, 2button press, release) is not very good, but the subsequent seeks are quick. At least I'm not able to click so fast as to cause any delay.
Well, I'm not sure what we could do to avoid at least release and double-click, and I think it's not a real problem anyway. It's not like we're doing it in a loop.
Regards, Colomban
On Thu, 11 Aug 2011 00:14:02 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 10/08/2011 12:02, Dimitar Zhekov a écrit :
It was requested in the mailing list, twice IIRC, for double-clicking into Compiler or Messages tab to not only open the file and seek into it, but also focus the editor window. [...]
Looks good. Though, why handling button-press rather than button-release for getting double clicks?
Because there is 2BUTTON_PRESS, but not 2BUTTON_RELEASE, and I didn't want to track the press-release relation.
Luckily, that is not needed - the selection is ready at 2BUTTON_PRESS, and can not be changed by it.
Le 11/08/2011 15:55, Dimitar Zhekov a écrit :
On Thu, 11 Aug 2011 00:14:02 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 10/08/2011 12:02, Dimitar Zhekov a écrit :
It was requested in the mailing list, twice IIRC, for double-clicking into Compiler or Messages tab to not only open the file and seek into it, but also focus the editor window. [...]
Looks good. Though, why handling button-press rather than button-release for getting double clicks?
Because there is 2BUTTON_PRESS, but not 2BUTTON_RELEASE, and I didn't want to track the press-release relation.
Makes sense. Anyway it seems to be the usual even for double-click in GTK/GNOME apps.
Patch applied, thanks :)
Regards, Colomban
Hi,
Since it's not part of the message parsing, but affects the double clicking, I'll continue this thead a bit.
Currently, on a keypress / click on Compiler or Message line which contains valid filename and a too large line number (editor.c:9999), Geany does the following:
1. Opens the file, if not already open; that makes it's tab active. 2. Stores the previous file name and position, and the current file name with position -1 [our line # is too big] in the navqueue. 3. Attempts to seek to filename and position -1 and fails. 4. Does not focus editor on Enter / double click, since #3 failed.
(Of course, the steps are a bit different technically.)
What's wrong:
- The file tab becomes active for newly open files, but not for already open files. - An invalid position will be stored in the navqueue. Sometimes (when that position becomes current?), both <- and -> buttons will be disabled. - We reconginze the file, but neither switch to it's tab nor focus the editor.
My proposition:
1. Opens the file, if not already open; that makes it's tab active (same as before). 2. Stores the old filename and position. 2. Attempts to seek to the new position. 3. If successful [which implies that the file tab is activated], stores the new filename and position. 4. Otherwise, explicitly activates the file tab. 5. On Enter / double click, focuses the editor.
From Geany/plugin developers point of view, navqueue_goto_line()
will remain the same.
Alternatively, we can simply replace an invalid position with the current file position. The <- -> queue will be more consistent, but if a plugin wants to seek to editor.c:9999 and do something there, navqueue_goto_line() will "lie" that goto was successful.
So, please tell me what you think (and disregard my previous comments about position -1 in the "msgwin line and column" thread). Both variants are easy to implement.
-- E-gards: Jimmy
Hi Dimitar,
My proposition:
- Opens the file, if not already open; that makes it's tab active
(same as before). 2. Stores the old filename and position. 2. Attempts to seek to the new position. 3. If successful [which implies that the file tab is activated], stores the new filename and position. 4. Otherwise, explicitly activates the file tab. 5. On Enter / double click, focuses the editor.
In a previous thread it was suggested that line 0 go to line 1, so why not make line "too big" go to last line? Wouldn't that make it all easier?
Cheers Lex
Le 20/08/2011 16:04, Lex Trotman a écrit :
Hi Dimitar,
My proposition:
- Opens the file, if not already open; that makes it's tab active
(same as before). 2. Stores the old filename and position. 2. Attempts to seek to the new position. 3. If successful [which implies that the file tab is activated], stores the new filename and position. 4. Otherwise, explicitly activates the file tab. 5. On Enter / double click, focuses the editor.
In a previous thread it was suggested that line 0 go to line 1, so why not make line "too big" go to last line? Wouldn't that make it all easier?
Looks sensible to me.
Cheers, Colomban
On Sun, 21 Aug 2011 00:04:15 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Dimitar,
My proposition:
- Opens the file, if not already open; that makes it's tab active
(same as before). 2. Stores the old filename and position. 2. Attempts to seek to the new position. 3. If successful [which implies that the file tab is activated], stores the new filename and position. 4. Otherwise, explicitly activates the file tab. 5. On Enter / double click, focuses the editor.
In a previous thread it was suggested that line 0 go to line 1, so why not make line "too big" go to last line?
1. We know that some parsers return line 0, but I haven't seen line# larger than the #lines + 1 (equal to #lines + 1 is accepted by scintilla and goes to EOF). So we probably parsed a number which is not a line #.
2. The plugins may expect navqueue_goto_line() to return a precise result. Well they don't ATM, and handling 0 is not precise either. If we decide on big line == last line, we'd better (a) make the function void after the release and (b) seek to EOF, for sync with scintilla.
Wouldn't that make it all easier?
A bit shorter (all variants are pretty easy). I proposed the most logical (IMHO), but anything that'll make focusing work is fine by me.