|
@etorth Thank you very much for your test code and the description.
What I did (abstract):
- I tested your code (.fl) with the original fluid and found the "bug" in your .fl file
- I fixed your .fl file for usage with the original fluid
- Conclusion
- Hint: I propose to use the new
Fl_Flex class as an alternative for what you likely wanted to achieve.
Details:
-
The "fault" in your .fl file is that you create the widget with another (smaller!) size than the designed size. Thus the second button appears outside the group which makes it "unclickable", as you already know (this is what your patch would change). Later resizing doesn't help, obviously.
-
The solution with the original fluid is to create the group in the exact size it was designed for and then resize it to the desired size. This looks a little confusing but it is a possible solution with the original fluid. No need to patch. Here is my working solution:
pr-481_resize_rescale_v3.fl.txt
Except adding test statements I gave all the relevant widgets names (or renamed them): b1 , b2 , and tc (the test_widget_class instance). In the generated code you'll notice the following main changes (explained here by comments):
{ Test_widget_class* o = tc = new Test_widget_class(10, 25, 530, 35, "Test_widget_class");
// use "original" size of class (530 x 35) in constructor
tc->box(FL_UP_FRAME);
// ... some code elided ...
Fl_Group::current()->resizable(tc);
// resize the widget to desired size (below):
o->size(325, 55);
} // Test_widget_class* tc
-
Conclusion: there is no need to patch fluid to do what you want to achieve. Admittedly, it would be "nice to have" to define a new class and to be able to create an instance in an arbitrary size and position. However, I'm not sure if fluid should be used to do it in the way you propose. I tend not to include your PR because it's not strictly necessary. However, I'm open for arguments.
-
That said, the new Fl_Flex widget can be used to achieve what you showed in your example. I copied your .fl file and modified it to use the new Fl_Flex class and derived my own flex class similar to what you did. The result is shown in an application that creates three flex instances (flex1, flex2, flex3) in different sizes. But note that Fl_Flex is brand-new and has no built-in fluid support yet. My fluid file is just a quick hack, it could maybe be done better and I hope that we will also get fluid support of Fl_Flex soon. Note that I made a design decision to make the buttons in two different widths (b1: 100, b2: 80) and the floating box in the middle gets the remaining size. Here is my fluid file that uses three instances of the class flex derived from Fl_Flex . Enjoy!
# data file for the Fltk User Interface Designer (fluid)
version 1.0400
header_name {.h}
code_name {.cxx}
widget_class flex {open selected
xywh {168 274 530 35} box THIN_DOWN_BOX resizable
code0 {type(Fl_Flex::HORIZONTAL);}
class Fl_Flex visible
} {
Fl_Button b1 {
label b1
callback {printf("b1 clicked\\n");
printf("b1 = (%d, %d, %d, %d)\\n", b1->x(), b1->y(), b1->w(), b1->h());
printf("b2 = (%d, %d, %d, %d)\\n", b2->x(), b2->y(), b2->w(), b2->h());}
xywh {0 0 105 35}
code0 {((Fl_Flex *)(o->parent()))->set_size(o, 100);}
}
Fl_Box {} {
comment {invisible spacing}
xywh {125 0 280 35}
}
Fl_Button b2 {
label b2
callback {printf("b2 clicked\\n");
printf("b1 = (%d, %d, %d, %d)\\n", b1->x(), b1->y(), b1->w(), b1->h());
printf("b2 = (%d, %d, %d, %d)\\n", b2->x(), b2->y(), b2->w(), b2->h());}
xywh {425 0 105 35}
code0 {((Fl_Flex *)(o->parent()))->set_size(o, 80);}
}
}
Function {main()} {open return_type int
} {
Fl_Window m_window {
label {Fluid Test Fl_Flex} open
xywh {344 74 500 202} type Double resizable visible
} {
Fl_Box flex1 {
label flex1
xywh {10 25 480 35} box UP_FRAME
class flex
}
Fl_Box flex2 {
label flex2
xywh {120 75 280 35} box UP_FRAME
class flex
}
Fl_Box flex3 {
label flex3
xywh {50 130 400 60} box UP_FRAME resizable
class flex
}
}
code {m_window->show();
m_window->size_range(500, 240);
return Fl::run();} {}
}
Finally, there's another "flexible" widget Fl_Grid I'm working on now which will give us even more flexibility in grouping widgets in rows and columns (i.e. in a grid) without strict pixel positions.
Final note: I did not test your patch/PR because I found a working solution. As said above, there's still room for discussion.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/pull/481/c1214401757@github.com>
[ Direct Link to Message ] | |