FLTK logo

STR #1784

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

STR #1784

Application:FLTK Library
Status:4 - Pending
Priority:4 - High, e.g. key functionality not working
Scope:2 - Specific to an operating system
Subsystem:Core Library
Summary:scrolling in ScrollGroup does not take into account labels
Version:2.0-current
Created By:goeb
Assigned To:bgbnbigben
Fix Version:2.0-current
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
 
#1 goeb
13:37 Sep 09, 2007
scroll.cxx
5k
 
 
#2 AlbrechtS
07:04 May 15, 2011
scroll2.cxx
5k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 goeb
13:37 Sep 09, 2007
With the attached example (a slightly modified scroll.cxx from the test directory), if one redimensions the windows with a smaller width, and then pull the horizontal scrollbar to the right so that the leftmost labels ("0", "5", "10",...) disappear, then it is not possible to recover these labels with the horizontal scrollbar. they are lost forever.

This also happens vertically.

I work on Linux and use version fltk-2.0.x-r5940, i don't know if it's "2.0-current" or "2.0-feature".
 
 
#2 bgbnbigben
23:05 May 14, 2011
This sounds like it should never happen; as things are scrolled redraw() will be called, but redraw() should also redraw labels. Since the label is drawn over the top of the button, and the button is redrawn, the label will also be damaged (and thus redrawn).

I can't reproduce this on my system, and I'm guessing there were a few updates between r5940 and now (r8662). As such, I'm going to close this STR on the assumption that the issue has been fixed; please refile a new one if this bug does in fact still exist.
 
 
#3 AlbrechtS
07:04 May 15, 2011
Ben, I can reproduce it, please see the attached modified file scroll2.cxx for better visibility of the RED labels. The problem manifests only with *outside* labels.

I marked two comments with "***" to show what I changed (additionally to a vertical offset of 20 pixels to show the top outside labels as well), and the 2nd comment shows a workaround by explicitly adding an invisible box at (0,0).

I didn't change the STR status though, leaving it up to you to reopen it or close with "won't fix", maybe. I believe that this effect is also in FLTK 1.x, but I didn't check (yet).

(1) Reproduced with svn r8635 (before XP theme updates), shows the described effect.

(2) Reproduced with current svn (with XP theme) as well, but (maybe OT here?): where are all the button colors gone?
 
 
#4 bgbnbigben
15:42 May 15, 2011
Bugger. Alright, I've reopened the STR, because it's a poor bug that should be fixed; chances are someone forgot to call redraw_label(). This shouldn't be too hard to pin down, but I'll have to do it when I get back home in probably 10 hours.

As for the XP theme,  I'm aware it demolishes button colours. What occurs is FLTK fills the background rectangle with a colour, but the image is placed *on top* of the button, thus hiding any colours.
For the moment, if a user wants colours, etc, one can always revert the style. I do intend to add proper transparency to the images as some point, as well as segregation the #includes amongst other things, but I really only forced the XP theme to be the default in an effort to get some feedback.
It has also allowed me to iron out some other bugs though, like no slider rectangles being redrawn....
 
 
#5 AlbrechtS
01:24 May 16, 2011
Ben wrote:
> I've reopened the STR, because it's a poor bug that should
> be fixed; chances are someone forgot to call redraw_label().
> This shouldn't be too hard to pin down, ...

It's easy to pin down what is going wrong, but it's not easy to fix IMHO. The labels are simply not considered when calculating the bounding box of all widgets. If you wanted to fix this, it would probably have to go in layout(), in the loop at line 216-224. You would have to measure the labels with all consequences as setting fonts etc.. Aside from the fact that I don't know if this would be acceptable in layout(), this could be *very* expensive, especially since this is in another loop (line #198++) that could be executed at most three times. Now consider that we have users that reported to use more than 20,000 widgets (maybe 40,000) in an [Fl_]Scroll[Group].

But there's an easy way out: Maybe it's not a bug, it's a feature?

ScrollGroup's docs say: "The bounding box of the widgets are the area it can scroll, this will remove any borders, if you want the borders preserved put some invisible widgets there as placeholders."

BTW, that's why I added the invisible box as a workaround in my demo program.

Just classifying the (outside) labels as "the borders" that should be "preserved" and documenting this would probably be enough and a clean solution WRT performance as well.

P.S.: As for the XP theme, I'll reply directly in fltk.development.
 
 
#6 bgbnbigben
19:35 May 16, 2011
If you look at line 126 in your scroll2.cxx (and most likely the same line in test/scroll.cxx), the first button will be positioned at (50, 20) with length (75, 25).
When the ScrollGroup scrolls over, it _doesn't_ honour this (50, 20) starting point; it shifts it to (0, 0). This isn't so much to do with the labels as it is with the actual positioning of elements within a ScrollGroup; whether or not I use ALIGN_INSIDE on the label or not, it will still shift this if, for whatever reason, I deem there needs to be padding to the left or above the boxes.
I claim that this behaviour is buggy, even though it's documented; it shouldn't really be up to FLTK to decide that something is or isn't where I originally put it.
Plus, it does look like it was originally intended to do drawing properly anyway; lines 121-123 suggest this.


It should simply be a matter of working out where the original placement was and *properly* setting the clip region, rather than overwriting it.
 
 
#7 AlbrechtS
03:23 May 17, 2011
I agree that the general problem "isn't so much to do with the labels as it is with the actual positioning of elements within a ScrollGroup".

However, you wrote: "It should simply be a matter of working out where the original placement was and *properly* setting the clip region, rather than overwriting it." Unfortunately I don't think that it is that easy. First of all, it has nothing to do with clipping (setting the clip region), since this is fixed. The problem is to determine what the displayable portion of the scrolling region should be. The (outside) labels are only a symptom, because this is not defined properly, and FLTK (1.x and 2.0) assume that it ought to be the bounding box of all widgets (ignoring outside labels).

I had the "padding" issue in my own application (FLTK 1), and I solved it by adding an invisible box. I believe that setting margins (top, left, right, and bottom) could be a working solution, so that the user could add padding as s/he likes.

I came to the conclusion that your idea of saving the initial position and restoring it wouldn't work in the general case. First of all, you wouldn't be able to define padding at the right and bottom side, but sometimes this could be desirable. Secondly, it is possible to position widgets initially at negative coordinates relative to the ScrollGroup. Imagine using the ScrollGroup for displaying a single (boy with an) image that may or may not fit in the ScrollGroup. The initial position shall be centered. If the image is bigger than the ScrollGroup, then it would have to be positioned on negative x/y. Now imagine that you also want to add a label below, above, left or right of the image...

If we don't want to measure all labels in the ScrollGroup (as I said above, and I wouldn't propose doing it), then we must either:

  (a) add user-defined margins/borders in all directions (around the
      bounding box as it is calculated now)
or
  (b) tell the user to use invisible boxes (as documented now).

Since the latter is also used for resizing (resizable()), I believe that (b) could be an acceptable solution, whereas (a) could be implemented easily w/o much overhead, but with ABI breaking extensions (this would not be a problem for FLTK 2, but for FLTK 1.3, since it is now to be released soon).

In the long term I'd probably favour (a).

BTW: lines 121-123 don't suggest much to me, since they are needed anyway to draw outside labels *between* other widgets, and the drawing is always done correctly. It's only the scrolling (calculating the bounding box) that is buggy, if you like to see it so.
 
 
#8 AlbrechtS
03:43 May 17, 2011
Typo correction: Of course, the following sentence should contain the word "box" instead of "boy":

Imagine using the ScrollGroup for displaying a single (box with an) image that may or may not fit in the ScrollGroup.
 
 
#9 bgbnbigben
18:23 May 17, 2011
Yeah, I attempted to follow up the clipping idea earlier and realised that the clipping region was static; it's simply the viewable rectangle inside ScrollGroup.

I do agree that the padding functions should definitely be added, and I'll turn this into an RFE (eventually) to make sure I do this.

In regards to your point about the displayable region, would the child widget's bounding box not start at (50, 50) in your [scroll2.cxx] example, rather than (0, 0)? This is probably the crux of this discussion; I believe it should start at (50, 50) because that's where you've positioned it to begin with.

In terms of the image example, you could set the box to start at (0, 0) and extend to the width and height of the image. Then just use the scrollTo() method to set the initial viewing point to the centre of the image. You shouldn't need to start it at negative coordinates.
 
 
#10 AlbrechtS
04:52 May 18, 2011
Ben, I'll reply to your last message in a more general way in fltk.development later, since I think that we should discuss this more deeply, but this is not the right place. However, I can't do it right now, other work must be done.  
     

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