STR #3412

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 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #3412

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl_Text_Display scroll bug (style table with font != textsize() + wrap)
Version:1.4-current
Created By:greg.ercolano
Assigned To:Unassigned
Fix Version:1.4.0 (SVN: v12526)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 greg.ercolano
14:51 Oct 07, 2017
display-bug.cxx
1k
 
 
#2 greg.ercolano
15:05 Oct 07, 2017
quickfix.patch
1k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 greg.ercolano
14:51 Oct 07, 2017
Attached program demonstrates the vertical scrollbar isn't calculated
properly when the Fl_Text_Display has wrap_mode() set to WRAP_AT_BOUNDS
with a style table whose font text size != textsize().

To replicate:

    1) Run the app, and do not change the size of the window
    2) Scroll to the bottom of the buffer

What you SHOULD see is line 0199, which is the real "last line".
What you ACTUALLY see is a partial line (in my case, line 0109)
as being the bottom line. There's obviously more in the buffer,
but you can't reach it with the scrollbar.

Resizing the window vertically does not help.
But resizing horizontally by just a few pixels fixes the problem,
causing the scrollbar to re-calculate properly, so that one can
scroll to the real bottom of the buffer.

Seems to be a bug in Fl_Text_Display's calculations of the vertical
scrollbar values that isn't getting triggered until an actual resize()
of the horizontal size is changed.
 
 
#2 greg.ercolano
15:05 Oct 07, 2017
Attaching a small patch (quickfix.patch) that solves the
immediate problem I'm having.

I did not dig in deep, but given the horiz vs. vert resize behavior
described in comment #1, this seemed the obvious place to suspect,

Not sure if it's the right solution. If it is, then likely
'oldTAWidth' and related code should be removed.

Albrecht, I think this involves your mods introduced in r11208.
Perhaps you can weigh in.
 
 
#3 AlbrechtS
02:30 Oct 12, 2017
@Greg: I saw your comment and I'll take a look at it later.

As far as I can remember I was not really happy with 'oldTAWidth' and its calculation or whatever, but I didn't want to change more than necessary. As you know, Fl_Text_Display is a beast ;-)
 
 
#4 AlbrechtS
03:40 Oct 21, 2017
@Greg: I found that your "quickfix.patch" was (obviously unintentionally) committed in r12511 that fixes STR #2788.

I reverted that part of r12511 in svn r12518.

I'm trying to figure out what oldTAWidth is (or was) good for and I'm working on a patch. I'm not sure if we should remove it entirely or maybe only initialize it with another value (maybe 0).
 
 
#5 greg.ercolano
03:43 Oct 21, 2017
Ew, good catch, thanks..

I assume you caught it pulling 1.4 current and then noticing it had
already been applied..!
 
 
#6 AlbrechtS
04:07 Oct 21, 2017
Actually I found it because I got a compiler warning (unused variable).  
 
#7 AlbrechtS
04:05 Oct 25, 2017
Fixed in Subversion repository.

The fix in svn r12526 disables a part of the optimization introduced in svn r11208
(STR #3272).

The problem with the optimization was the (false) assumption that the resize() method is called only when a real resize of the widget happened. However resize() is also called when the data buffer was changed. Hence, the initial display width can be unchanged.

The test program display-bug.cxx works for me correctly with this commit.

Please try svn r12526 or later and report if it fixes your issues.
 
 
#8 greg.ercolano
09:54 Oct 25, 2017
Looks good to me; checked with the app I was having trouble with and I can now scroll to the bottom without trouble.  
 
#9 greg.ercolano
10:06 Oct 25, 2017
I believe STR #3361 is related.
I'll make a note there to see if r12526 solves their issue.
 
 
#10 greg.ercolano
16:49 Oct 25, 2017
STR #2682 also related.  
 
#11 greg.ercolano
09:16 Oct 26, 2017
By the way, I just made a change to Fl_Text_Display::resize()
to split out the recalc code from the resize() method so that it
can be called directly (r12529), needed to fix STR #3395.

This allows recalc'ing the display without having to round trip
through the FLTK resize() hierarchy when dimensions haven't changed.
 
 
#12 AlbrechtS
07:23 Nov 06, 2017
Re #9 - #11: I'll take a look at the mentioned STR's when time permits.

WRT splitting recalc code from the resize(): I'll take a look at this as well. It's a good move, but using the new feature [1] may change the behavior of Fl_Text_Display, so this needs thorough investigation. Maybe worth another STR?

[1] What I mean is: calling one OR the other OR both whatever is necessary where currently resize() is called. I know that resize() is called in the modify-callback (i.e. when the text buffer is/was modified), but there are supposedly other places...
 
 
#13 AlbrechtS
09:30 Dec 02, 2021
See also related issue #300:
"test/tree: hitting 'select all' hangs the application"

https://github.com/fltk/fltk/issues/300
 
 
#14 AlbrechtS
14:15 Jan 16, 2023
Unassigning myself.  
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

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'.