Re: pack or grid (or the other way around)?

Luc <luc@sep.invalid> wrote:

On Thu, 16 Jan 2025 11:34:34 +0100, Ralf Fassel wrote:
 

In addition to what Rich wrote, here is what you *cant* do:
>
 frame .f
 label .f.l1
 label .f.l2
 
 pack .f.l1
 grid .f.l2
 => error: cannot use geometry manager grid inside .f which already has
slaves managed by pack 
>
 grid .f.l2
 pack .f.l1
 => error: cannot use geometry manager pack inside .f which already has
slaves managed by grid 
>
But .f itself can be managed by either grid or pack, regardless of what
you use to pack/grid widgets 'inside' .f

**************************
 
That is my concern.
 

.f itself can be managed by either grid or pack, regardless of what
you use to pack/grid widgets 'inside' .f

 
That's because .f is the parent.
 
Now suppose someone has an application that uses grid. Everything is
inside one big 'gridded' frame. And suppose my megawidget uses pack.
 
Or the other way around.
 
That is my concern.

Provided your megawidget exposes only one single top level widget
(usually a frame which holds all the internal widgets) to the user of
the megawidget it will make no difference.  The user of the megawidget
can do anything they like to the outer container as far as
pack/grid/placing it, zero impact on your bits and pieces inside that
container.