| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3057
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_Browser: changing the textsize() does not affect scrollbars |
|---|
| Version: | 1.3-current |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.4 (SVN: v11453) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
04:55 Feb 22, 2014 |
| Ran into this while adding font resize capability to my apps
for users with very large monitors.
If one populates Fl_Browser with content, then later changes
the textsize(), the scrollbars no longer scroll content correctly.
For instance, enlarging the font size prevents one from being able
to scroll to view the bottom or right edges of content. Or shrinking
the font size causes scrollbars to appear unnecessarily.
Attaching test-browser.cxx to demonstrate; a simplified version
of the test/browser.cxx program. To replicate:
Hit the +Font and -Font buttons to enlarge/shrink
the browser's textsize().
The scrollbars do not react to the changes.
Resizing the window has no effect on scrollbar recalc.
It seems there's internal cached data not being recalculated.
Changes to textsize() and textfont() should probably trigger
this cached data to automatically be recalculated. | |
| |
| #2 | greg.ercolano
05:21 Feb 22, 2014 |
| FWIW, an application can workaround by first calling hide(int)
on all the items, then adjusting the textsize(), then show(int)
on all the items again, e.g.
for ( int t=1; t<=browser->size(); t++ ) { browser->hide(t); }
browser->textsize(14 + (++fontsize_offset));
for ( int t=1; t<=browser->size(); t++ ) { browser->show(t); }
browser->redraw();
This seems to force the internal caches for e.g. full_height_
and full_width_ to update properly. Not pretty, but something
existing apps can do without hacking FLTK's code. | |
| |
| #3 | AlbrechtS
07:08 Jan 20, 2016 |
| Attached file textsize_v1.diff seems to work, but is only a proof of concept. Please review, add comments, discuss...
I used an old patch of mine for FLTK 1.1 for the resize() part (which is working for a long time now in a commercial application) and added the textsize() modifications.
Notes:
(1) The resize() part in Fl_Browser.H and Fl_Browser.cxx fixes the 2nd issue mentioned by Greg:
> Resizing the window has no effect on scrollbar recalc.
This part alone enables you to change the font size and see the effects when/after you resize the window.
(2) The textsize() part in Fl_Browser_.H adds three statements to the /inline/ method Fl_Browser_::textsize(Fl_Fontsize). I had hoped that the first two statements would suffice, but that didn't help. So I added
resize(x(),y(),w(),h()); // *FIXME* this is kinda brute force (POC)
WRT widget size this is actually a no-op, but resize() calculates the scrollbars.
There should be a better way to do this, and maybe we should move this inline method to the .cxx file, but I ran out of time.
Comments and suggestions welcome. Using resize() in textsize() is contrary to the FLTK way that such methods are quick and do only set internal variables.
(3) All the code changes in src/Fl_Browser_.cxx are actually commented out - no need to apply this. However, the statement
max_width = 0; // force recalculation of internals
was in my previous patch. Maybe it was superfluous or I did not yet see why it was necessary. I left it commented out to remind me (us) to check this...
(4) Although I don't think that the patch changes the ABI I didn't check it thoroughly. At least one virtual method is overridden by the patch, but since it was virtual anyway I don't believe that this breaks the ABI.
As always, comments, suggestions, improvements, and test results would be very much appreciated. | |
| |
| #4 | AlbrechtS
09:29 Mar 28, 2016 |
| Fixed in Subversion repository.
I used a different approach to fix the issue, because the PoC (textsize_v1.diff) called resize() which is not appropriate.
svn r11453 fixes the issue by recalculating the internal data only when textsize(int) is called. This makes textsize(int) a potentially slow operation, but the full_size() value is cached and used whenever a single item is changed, added, deleted, shown, or hidden, hence such operations should still be fast.
FWIW: attached file test-browser_v2.cxx is a modified test version that lets you test and verify that the horizontal scrollbar is adjusted as well. Note: scrolling the contents does intentionally not reset the horizontal scrollbar width to a smaller value, but both resize() and textsize(int) do.
Regarding my comment #3 (3): max_width = 0 (now in textsize(int)) was indeed necessary to reset the horizontal scrollbar which could not be tested with test-browser.cxx (constant line width).
Please confirm that this (r11453) fixes the issue for you. | |
| |
| #5 | AlbrechtS
12:42 Jul 15, 2016 |
| @Greg: could you please check so we can close this? | |
| |
| #6 | greg.ercolano
11:11 Jul 22, 2016 |
| Thanks for the fix!
Seems to work, feel free to close. | |
| |
| #7 | AlbrechtS
09:57 Jul 23, 2016 |
| Thanks for confirmation.
Closed. | |
[ Return to Bugs & Features ]
|
| |
