RFC: Add options to Fl_Pack for right vs. left and bottom vs. top packing

[Greg Ercolano]

Unless I'm missing something obvious:

     1) It seems like Fl_Pack could use a few options to allow
         right vs left and bottom vs top justification.

     2) I don't think there are any tricks involving a combo of widgets
         to achieve this.. or are there?

Looking for votes on #1, and input on #2 if there is a trick
to achieving, say, right-justified packing.

Right-to-left packing would be great for e.g. a Yes/No dialog box
where the OK and Cancel buttons are right-justified:

     __________________________________________
    |  Some message          ________   ______  |
    |                       |_Cancel_| |__OK__| |
    |___________________________________________|

                            |_________________|
                                    |
                                    These buttons could be
                                    in a 'right justified
                                    horizontal Fl_Pack'

Currently, I think the only way to achieve this is with manual positioning.

If there is some way of doing this without modifying Fl_Pack,
I'd like to add a description in the Fl_Pack docs, as it doesn't seem obvious
to me.

Otherwise, I'd like to propose a patch that adds RIGHT and BOTTOM as new flags
for Fl_Pack::type(). I've actually done this already in some offline tests, but would like
to test a little more. I think can do it in a manner that doesn't break ABI either.

--

Greg Ercolano, er...@seriss.com
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: +1 626-576-0010 ext.23
Fax: +1 626-576-0020
Cel: +1 310-266-8906

[imm]

I confess I'm not a big fan of the Fl_Pack widget anyway, so I am not at all familiar with how it works.

That said, I am surprised that it doesn't have modifiers for left/right and up/down to "adjust" the H or V pack direction; that seems like something it should have...

I'm not going to object to adding them!

Cheers...

-- 

Ian

[Manolo Gouy]

> Unless I'm missing something obvious:
>
> 1) It seems like Fl_Pack could use a few options to allow
> right vs left and bottom vs top justification.

This looks like a good extension: +1

> 2) I don't think there are any tricks involving a combo of widgets
> to achieve this.. or are there?

I don’t think either.

[Albrecht Schlosser]

On 23.06.2014 21:47, Greg Ercolano wrote:
> Unless I'm missing something obvious:
>
> 1) It seems like Fl_Pack could use a few options to allow
> right vs left and bottom vs top justification.
>

> 2) I don't /think/ there are any tricks involving a combo of widgets

> to achieve this.. or are there?
>

> Looking for votes on #1, and input on #2 if there /is/ a trick

> to achieving, say, right-justified packing.

I'm late to the party, but just in case you're still waiting for votes:

+1 on adding right and bottom justification, although I don't think that
bottom justification would be very useful, but who knows...

That said, Fl_Pack resizes itself so that all widgets fit, so there is
probably no need to use right justification - it would just be a matter
of ordering the widgets. But then your given usage example wouldn't work
anyway. Or am I missing a point? As I see it, Fl_Pack only has a top
left coordinate (x,y) and either a height or width, depending on its
type and resizes itself (i.e. the missing width or height) depending on
its children. This is from the docs:

"If type() is Fl_Pack::HORIZONTAL all the children are resized to the
height of the Fl_Pack, and are moved next to each other horizontally. If
type() is not Fl_Pack::HORIZONTAL then the children are resized to the
width and are stacked below each other. Then the Fl_Pack resizes itself
to surround the child widgets."

IIRC there's an undocumented special feature with the resizable(), but
you would have to look at the code. The comment says:
"// Last child, if resizable, takes all remaining room".

That would maybe have to be interpreted as "First child, if resizable,
takes all remaining room", if ordering is reverse (from last child to
first child, starting at bottom or right border).

BTW: reading this again, this would mean: if the last child is the
resizable(), then Fl_Pack has a fixed _minimum_ size, as given with w()
or h() resp.: the last child will be resized, if the total size is
smaller than the given w() or h(). If the last child is not the
resizable, or if the total width/height of the children is bigger than
given, Fl_Pack will resize itself. Is this really what it does?

All that sounds weird and complicated, so I would personally not want to
touch it, but feel free to do it if you like.

Note: the current behavior WRT resizable() should probably be
documented. Any volunteers? If not, I may try to do it...

[Greg Ercolano]

On 09/06/14 11:04, Albrecht Schlosser wrote:
> On 23.06.2014 21:47, Greg Ercolano wrote:
>> Unless I'm missing something obvious:
>>
>> 1) It seems like Fl_Pack could use a few options to allow
>> right vs left and bottom vs top justification.
>>
>> 2) I don't /think/ there are any tricks involving a combo of widgets
>> to achieve this.. or are there?
>>
>> Looking for votes on #1, and input on #2 if there /is/ a trick
>> to achieving, say, right-justified packing.
>
> I'm late to the party, but just in case you're still waiting for votes:
>
> +1 on adding right and bottom justification, although I don't think that
> bottom justification would be very useful, but who knows...

Thanks for reminding me about this.

I need some time to get my head back around this, and today I'm kinda
distracted by too much other stuff, but I think I found the mods I was
working on.

For my own purposes, I'm attaching a possibly rough patch here,
mainly so I can remember what I was working on. Not the best solution,
as I should really make an STR about this and attach the patch there.

(I can't honestly remember the completion state of this patch,
but I think it worked the way I wanted for testing purposes.
I'll make an STR for this later when I have some time)

Will revisit and look thru the rest of your reply on a later date
when my head is clear..

[Albrecht Schlosser]

On 06.09.2014 22:23, Greg Ercolano wrote:

> Thanks for reminding me about this.
>
> I need some time to get my head back around this, and today I'm kinda
> distracted by too much other stuff, but I think I found the mods I was
> working on.
>
> For my own purposes, I'm attaching a possibly rough patch here,
> mainly so I can remember what I was working on. Not the best solution,
> as I should really make an STR about this and attach the patch there.

Comments to your patch:

(1) I find your enum confusing. It looks like some bits that have to be
or'd together, so that right-to-left in horizontol mode would need two
bits in the API, like

type(HORIZONTAL|RIGHT);

It would be easier to use a simple 4-value enum like this:

VERTICAL = 0,
HORIZONTAL = 1,
BOTTOM_UP = 2,
RIGHT_TO_LEFT = 3

The bit 0 is for horizontal or vertical, bit 1 is for "reverse" ordering.

You could still use an additional bit encoding, such as

REVERSE = 2

that can be or'd with VERTICAL or HORIZONTAL and that can be used for
internal testing (it would be set in both BOTTOM_UP and RIGHT_TO_LEFT),
and HORIZONTAL would also be set in RIGHT_TO_LEFT.

My main point is that the user interface is only one enum value for one
ordering.

In the resize part there is:

+ // Resize self to follow size of packed children
tw += Fl::box_dw(box()); if (tw <= 0) tw = 1;
th += Fl::box_dh(box()); if (th <= 0) th = 1;
if (tw != w() || th != h()) {
- Fl_Widget::resize(x(),y(),tw,th);
+ if (right() || bottom()) {
+ Fl_Widget::resize(x()+w()-tw,y()+h()-th,tw,th);

This last line would change the Fl_Pack's x and y coordinate, and later
resizing may have a "jumping widget" effect or something like that. You
may have to uses Fl_Group::init_sizes() or store the "original x/y
coordinates" somewhere else. But I'm only guessing here. I can't imagine
what would happen in a real example.

And now that I think about it: there are still problems with nested
Fl_Pack's anyway. I took a look at it a long time ago, but I don't think
that there's an easy solution as long as Fl_Pack resizes itself during
draw(), but that can't be changed easily as well, so I gave up.

[Albrecht Schlosser]

On Saturday, September 6, 2014 at 10:23:43 PM UTC+2, Greg Ercolano wrote:

    For my own purposes, I'm attaching a possibly rough patch here,
    mainly so I can remember what I was working on. Not the best solution,
    as I should really make an STR about this and attach the patch there.

FTR: see STR #3092
http://www.fltk.org/str.php?L3092