| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2788
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Annoying Fl_Text_Editor mouse cursor behavior |
Version: | 1.3-feature |
Created By: | mingodad |
Assigned To: | greg.ercolano |
Fix Version: | 1.4.0 (SVN: v12511) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | mingodad 03:57 Dec 07, 2011 |
| There is an annoying behavior of Fl_Text_Edito when we use the mouse to position the cursor over a text, with Fl_Input if we click on past half character (more or less) it position the cursor in front of this character but Fl_Text_Editor position the cursor before this character and that is a lot annoying.
Ex: <table><tr> : if we try to sposition the cursor between >< and point the mouse a pixel over ">" we get the cursor before ">" but with Fl_Input we get the cursor after ">" as at least I expext it to be. | |
|
#2 | ianmacarthur 04:55 Dec 07, 2011 |
| I am not sure what I like best.
I just spent a while, on a WinXP box, trying different text tools in an attempt to ascertain what is "normal".
It appears that the majority are (by whatever means) taking account of how far across the character you click.
If I click less than half-way across, the insertion point goes before the character.
If I click more than half-way across the character, the insertion point goes after the character.
In FL_Text_Editor, the insertion point goes before the character, regardless of how far across it I click, so even if I click on the right-hand edge of the glyph, the insertion point is set at the left of the glyph.
Note: This all assumes Latin L-to-R text ordering, and is only from testing on WinXP. I have no idea what other host systems do, or what would be normal for a R-to-L language order. | |
|
#3 | mingodad 04:58 Dec 07, 2011 |
| Exactly the Fl_Input has on my point of view the best behavior and my rerquest is to make Fl_Text_Editor behave like Fl_Input. | |
|
#4 | matt 08:36 Dec 08, 2011 |
| Yes, this issue is explained in the source code. It's not a big deal to fix it, but after fighting Fl_Input for a month or so to get UTF8 working, I was just too sick and tired to implement that. I should be able to get that done in a while. | |
|
#5 | guyben 16:58 Feb 13, 2014 |
| I did an attempt to fix the issue. Most of it was straight forward - propagating the "is this cursor position" bit to the end.
It did require changing the interface (in Fl_Text_Display.H) to add the bit to the find_x function. We can set this bit to a default value so as not to break existing programs.
But TBH I would prefer having find_x return a float, saying how far into the character the event happened. This would allow more flexibility for the user.
The diff is attached. It's a diff of both Fl_Text_Display.H and Fl_Text_Display.cxx, from fltk-1.3.x-r10095. | |
|
#6 | guyben 05:50 Feb 15, 2014 |
| After seeing how important binary compatibility is - I tweeked the code a bit so as to not change the interface of find_x. The "is this cursor position" bit is now passed by giving a negative 'x' location.
I'm not really sure what does constitute a change in binary compatibility, and the new interface has an extra value in an enum. If that's a problem it can be easily reverted.
The new diff is attached. It's a diff of both Fl_Text_Display.H (only the change in the enum, added a value at the end) and Fl_Text_Display.cxx, from fltk-1.3.x-r10095. | |
|
#7 | AlbrechtS 11:11 Feb 21, 2014 |
| Thanks for the patch, but we prefer "diff -u" for patches. This is better readable and has more context, which is helpful if the code changes before the patch is applied.
Could you please upload the patch again with diff -u ? Thanks. | |
|
#8 | ianmacarthur 16:28 Mar 11, 2014 |
| Does anyone know if guyben's patch is ABI safe or not? I don't and he seemed unsure too.
Also, GB, ore that Greg recently posted some notes on using an external ABI checking tool - that might be worth a look?
Can we move this one on and close it?
Cheers... | |
|
#9 | ianmacarthur 03:38 Sep 05, 2014 |
| Ping:
Any updates on this...? | |
|
#10 | AlbrechtS 11:58 Sep 18, 2014 |
| I don't see any reason why the patch would break the ABI. The only critical point seems to be the extension of an enum; I believe this is safe, particularly because the new value is used only in the .cxx file.
I posted an updated patch Fl_Text_Editor_cursor.patch, since the original patch was outdated and not according to the CMP. I could not even use it with `patch` directly. Fixed indentation and some other formatting issues. This new patch is against svn r 10319.
Beware: I did not test this, and I probably won't do that. I was curious about the ABI question, and so I did the patch and formatting work...
Leaving tests to others... | |
|
#11 | greg.ercolano 12:13 Oct 08, 2017 |
| I tested this quite a bit, both with test/editor and the attached 'test-with-colors.cxx' to test style variations, seems good, even with different sized fonts in the same document.
Attaching: Fl_Text_Editor_cursor_v2--r12482.patch against 1.4.x-svn current. Made a few small non-functional changes:
o Added STR #2788 markers to the changed code
o Rewrote this: --- int mode; if (posType == CURSOR_POS) mode = FIND_CURSOR_INDEX; else mode = FIND_INDEX; --- ..as a one liner: --- int mode = (posType == CURSOR_POS) ? FIND_CURSOR_INDEX : FIND_INDEX; // STR #2788 ---
I must admit I don't fully understand what's going on in there.. as Matt once said, I think it'd take the better part of a week just to get one's head around this widget's internals.
For that reason, not applying to svn, but it's definitely better behavior. I vote +1 for applying. | |
|
#12 | greg.ercolano 00:18 Oct 18, 2017 |
| Fixed in Subversion repository.
Thanks for the report mingodad, and esp. Guyben for the patch..! | |
[ Return to Bugs & Features ]
|
| |