| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #351
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o 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_Text_Display: horizontal scrollbar appears unnecessarily |
|---|
| Version: | 1.1.4 |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | Not Applicable |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | greg.ercolano
14:40 Apr 11, 2004 |
| Even if there is no text going beyond the right edge of the text window, the horizontal scrollbar can appear.
It seems if the vertical scrollbar appears, the horizontal scrollbar will also automatically appear.
Replication:
1) Run the editor.cxx application (no scrollbars)
2) Enter many short lines of text (no wider than screen)
until text scrolls off bottom; vert AND horiz scrollbar appear
Horiz scroll bar should not appear unless there's somewhere to scroll to.
| |
| |
| #2 | mike
17:42 Apr 11, 2004 |
| Looking into this; I suspect this was done to avoid an infinite loop, but I'll check. | |
| |
| #3 | mike
15:20 May 15, 2004 |
| Comments from the Fl_Text_Display::resize() code:
Decide if the horizontal scroll bar needs to be visible. If there
is a vertical scrollbar, a horizontal is always created too. This
is because the alternatives are unatractive:
* Dynamically creating a horizontal scrollbar based on the currently
visible lines is what the original nedit does, but it always wastes
space for the scrollbar even when it's not used. Since the FLTK
widget dynamically allocates the space for the scrollbar and
rearranges the widget to make room for it, this would create a very
visually displeasing "bounce" effect when the vertical scrollbar is
dragged. Trust me, I tried it and it looks really bad.
* The other alternative would be to keep track of what the longest
line in the entire buffer is and base the scrollbar on that. I
didn't do this because I didn't see any easy way to do that using
the nedit code and this could involve a lengthy calculation for
large buffers. If an efficient and non-costly way of doing this
can be found, this might be a way to go.
So, unless you can think of a good algorithm for quickly calculating the maximum line width, the code will stay as-is. | |
| |
| #4 | greg.ercolano
10:07 May 18, 2004 |
| > * Dynamically creating a horizontal scrollbar based on the currently
> visible lines is what the original nedit does, but it always wastes
> space for the scrollbar even when it's not used. Since the FLTK
> widget dynamically allocates the space for the scrollbar and
> rearranges the widget to make room for it, this would create a very
> visually displeasing "bounce" effect when the vertical scrollbar is
> dragged. Trust me, I tried it and it looks really bad.
Maybe the bounce effect can be avoided if the calculation for detecting the hscroll isn't run during scrolling, ie. if the mouse is in the scrollbar, and one of the buttons is down, don't do the calculation.. just schedule the calcuation to occur when the mouse is released.
> * The other alternative would be to keep track of what the longest
> line in the entire buffer is and base the scrollbar on that. I
> didn't do this because I didn't see any easy way to do that using
> the nedit code and this could involve a lengthy calculation for
> large buffers. If an efficient and non-costly way of doing this
> can be found, this might be a way to go.
This sounds like the right solution, as it seems like what most editors do; I'm used to seeing the hscroll's tabsize indicate the widest line in the file.
It's also consistent with how the vscroll tab works; it shows the longest line count in the file. eg. the Mozilla 'Edit|View Source' window, and 'kedit' to name a few examples.
I can see where whenever a large block of text is added, a complete char-by-char scan would be needed to determine maximum line width. For optimization, a public method that allows the caller to pass in the max line length could help that, eg:
add(const char *text, int maxlen = -1 );
In my app, I have to parse through the file anyway before adding the lines to the widget, so I can include the maxlen calculation as an optimization, so the widget doesn't have to do it.
Then it's just a matter of making sure the widget detects max line widths while the user types new lines of text.
| |
| |
| #5 | mike
05:54 May 21, 2004 |
| We're open to patches... :) | |
| |
| #6 | mike
08:04 Jul 27, 2004 |
| Please open a new STR if you come up with a solution (patch)...
Thanks! | |
[ Return to Bugs & Features ]
|
| |
