FLTK logo

STR #2788

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 guyben
16:52 Feb 13, 2014
Fl_Text_Editor_cursor_2788.diff
2k
 
 
#2 guyben
05:46 Feb 15, 2014
Fl_Text_Editor_cursor_2788_2.diff
2k
 
 
#3 AlbrechtS
11:58 Sep 18, 2014
Fl_Text_Editor_cursor.patch
4k
 
 
#4 greg.ercolano
12:13 Oct 08, 2017
Fl_Text_Editor_cursor_v2--r12482.patch
4k
 
 
#5 greg.ercolano
12:15 Oct 08, 2017
test-with-colors.cxx
1k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.