Re: [fltk.general] Fl_Scroll issue?
On 28.05.2012 13:44, testalucida wrote: seems as if widgets placed onto a Fl_Scroll don't keep their positions on scrolling. E.g.: the topmost widget's y-position is 30. There is a vertical scrollbar due to another widget with y-position 300. Pull the vertical scrollbar down and move it back to its top position. The y-value of the topmost widget will be 0. I would expect it keeping its original value. Am I wrong or is FLTK? Aside from what Greg correctly replied, your problem seems to be that your widget(s) don't fill the entire area of your Fl_Scroll. Fl_Scroll always calculates the bounding box of all your widgets and adjusts the scrolling area accordingly. Hence your observation that your topmost widget doesn't keep its y-position. If you really want to maintain a border around your widgets inside the Fl_Scroll, then you can add an invisible small box widget, in your example at position (0,0). This will keep your border intact, even if you scroll down and back again. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
On 28.05.2012, at 16:54, testalucida wrote: On 05/28/12 04:44, testalucida wrote: seems as if widgets placed onto a Fl_Scroll don't keep their positions on scrolling. Yes, when you scroll, it changes the children's xy positions in order to move them. and is there a way to prevent FLTK from doing so? In FLTK3, you can put a Group inside the ScrollGroup. While Group coordinates will change, the coordinates of the widgets inside the Group will not. Then again, FLTK3 is not even Alpha yet. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Fl_Scroll issue?
Hi,
seems as if widgets placed onto a Fl_Scroll don't keep their positions on
scrolling.
E.g.: the topmost widget's y-position is 30. There is a vertical scrollbar due
to another widget with y-position 300.
Pull the vertical scrollbar down and move it back to its top position. The
y-value of the topmost widget will be 0. I would expect it keeping its original
value. Am I wrong or is FLTK?
Here's my code. OS is Linux Mint 12, FLTK 1.3.0.
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Scroll.H
#include FL/fl_draw.H
#include FL/Fl_Box.H
class Box : public Fl_Box {
public:
Box( int x, int y, int w, int h, const char *lbl ) :
Fl_Box( x, y, w, h, lbl )
{
labelcolor( FL_BLACK );
}
protected:
void draw() {
Fl_Box::draw();
fl_draw_box(FL_UP_BOX, x(), y(), w(), h(), FL_YELLOW );
}
};
int main() {
Fl_Double_Window *pWin = new Fl_Double_Window( 100, 100, 300, 300, Scroll
Tests );
pWin-box( FL_NO_BOX );
Fl_Scroll scroll( 0, 0, 300, 300 );
scroll.box( FL_DOWN_BOX );
Box box1( 0, 30, 100, 50, BOX1 );
Box box2( 300, 300, 100, 50, BOX2 );
scroll.end();
pWin-end();
pWin-resizable( scroll );
pWin-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
On 05/28/12 04:44, testalucida wrote: seems as if widgets placed onto a Fl_Scroll don't keep their positions on scrolling. Yes, when you scroll, it changes the children's xy positions in order to move them. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
On 05/28/12 04:44, testalucida wrote: seems as if widgets placed onto a Fl_Scroll don't keep their positions on scrolling. Yes, when you scroll, it changes the children's xy positions in order to move them. and is there a way to prevent FLTK from doing so? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
On 05/28/12 07:54, testalucida wrote: On 05/28/12 04:44, testalucida wrote: seems as if widgets placed onto a Fl_Scroll don't keep their positions on scrolling. Yes, when you scroll, it changes the children's xy positions in order to move them. and is there a way to prevent FLTK from doing so? No, that is how it operates. Drawing and event delivery of widgets all work in absolute positions to prevent constant x/y conversions for events and drawing. Routes I /don't/ think would work easily: a) put the widgets into a subwindow (which resets the drawing origin to 0,0) and then pan that around, or.. b) use the new fltk matrix stuff (fl_pushmatrix(), fl_translate()..) to move the drawing origin around I don't think (a) works well because IIRC sub Fl_Window's don't work inside Fl_Scroll (for reasons I can't remember, but I recall having trouble making that work), and although (b) would work for drawing, I don't think the matrix stack affects important things like event delivery. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
thank you and have a nice day. and is there a way to prevent FLTK from doing so? No, that is how it operates. Drawing and event delivery of widgets all work in absolute positions to prevent constant x/y conversions for events and drawing. Routes I /don't/ think would work easily: a) put the widgets into a subwindow (which resets the drawing origin to 0,0) and then pan that around, or.. b) use the new fltk matrix stuff (fl_pushmatrix(), fl_translate()..) to move the drawing origin around I don't think (a) works well because IIRC sub Fl_Window's don't work inside Fl_Scroll (for reasons I can't remember, but I recall having trouble making that work), and although (b) would work for drawing, I don't think the matrix stack affects important things like event delivery. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Scroll issue?
On 05/28/12 10:19, testalucida wrote: thank you and have a nice day. b) use the new fltk matrix stuff (fl_pushmatrix(), fl_translate()..) to move the drawing origin around I should add to (b), I don't think the new matrix manipulation functions affect most widget drawing. Doing a little research, according to the new 1.3 docs for drawing: http://fltk.org/doc-1.3/drawing.html ..there are apparently two classes of FLTK drawing functions now; some are un-affected by the matrix functions, and some that are: 1) Fast Shapes-- fl_rect(), fl_line(), etc.. (unaffected) 2) Complex Shapes -- fl_begin_polygon(), fl_begin_line().. (affected) The new transformation matrix stuff only affects the complex shape drawing functions (2), whereas fltk's widgets mostly use (1) which are unaffected by the new matrix routines. Since the drawing matrix doesn't affect fast shapes, and I don't think if affects event positions (like Fl::event_x(), Fl::event_y()), it can't be used to move widgets or events. Perhaps this is something being rectified in fltk3, not sure(?). If it were, I suppose that would allow for things like rotated widgets, such as what the newer html5 webpages support now, eg: http://www.carto.net/svg/gui/combobox/index.svg ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
