I am working on a package that I guess would be considered a megawidget
and I vaguely remember reading somewhere that widgets (or was it
applications?) that use pack cannot contain widgets that use grid, or
maybe it was the other way around, which means that if my megawidget
uses pack, nobody would be able to use it inside another widget (or
would that be an application?) that already uses grid, or maybe the
other way around, well, you get the idea.

I also vaguely remember reading that "the other way around" was safe
though, that is, one between pack and grid may contain widgets managed
by the other geometry manager.

Is that correct? I can't seem to find that exact information. I guess
I really need to be sure before I make a commitment to either one
(or the other way around).

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> I am working on a package that I guess would be considered a megawidget
> and I vaguely remember reading somewhere that widgets (or was it
> applications?) that use pack cannot contain widgets that use grid, or
> maybe it was the other way around, which means that if my megawidget
> uses pack, nobody would be able to use it inside another widget (or
> would that be an application?) that already uses grid, or maybe the
> other way around, well, you get the idea.
>
> I also vaguely remember reading that "the other way around" was safe
> though, that is, one between pack and grid may contain widgets managed
> by the other geometry manager.
>
> Is that correct? I can't seem to find that exact information. I guess
> I really need to be sure before I make a commitment to either one
> (or the other way around).

You seem to be getting something very mixed up.

The rule is that any single widget can only be managed by one "manager"
[1] and all the direct children within a widget have to all be managed
by the same manager (because the manager operates from the parent
widget). Plus you have to obey any additional required parent/child
relationships imposed by the managers (the manual pages will detail
these).

But you can very well nest gridded items inside packed items, or packed
items inside gridded items.

# a 'gridded' item managed by pack

label .l1 -text "Label 1"
label .l2 -text "Label 2"

frame .f1
label .f1.l3 -text "Label 3"
label .f1.l4 -text "label 4"

grid .f1.l3 .f1.l4

pack .l1 .f1 .l2 -side top

# a 'packed' item managed by grid

label .l1 -text "Label 1"
label .l2 -text "Label 2"

frame .f1
label .f1.l3 -text "Label 3"
label .f1.l4 -text "label 4"

pack .f1.l3 .f1.l4 -side top

grid .l1 .f1 .l2

[1] "manager" being one of 'pack', 'place', or 'grid'.

* Luc <luc@sep.invalid>
| I am working on a package that I guess would be considered a megawidget
| and I vaguely remember reading somewhere that widgets (or was it
| applications?) that use pack cannot contain widgets that use grid, or
| maybe it was the other way around, which means that if my megawidget
| uses pack, nobody would be able to use it inside another widget (or
| would that be an application?) that already uses grid, or maybe the
| other way around, well, you get the idea.

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

HTH
R'

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.

I still haven't gone back to that code. I guess I will have to run
multiple tests on it and see what happens.

--
Luc
>>

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.

On 16/01/2025 05:11, Rich wrote:
> The rule is that any single widget can only be managed by one "manager"
> [1] and all the direct children within a widget have to all be managed
> by the same manager (because the manager operates from the parent
> widget).

[snip]

> [1] "manager" being one of 'pack', 'place', or 'grid'.

Actually, the problem is that geometry propagation may only be done by
one manager. It is possible to use both grid and pack within a single
widget if you switch off propagation on one of the two. So this works
just fine (for some definition of working):

frame .f
pack .f -fill both -expand 1
pack propagate .f 0

label .f.l1 -text label1
label .f.l2 -text label2

pack .f.l1
grid .f.l2

The place manager never does any propagation, so it can be mixed with
any of the other two managers without extra precautions. In fact, I use
that on a regular basis to create a styled toplevel:

proc ttk::toplevel {w args} {
tk::toplevel $w {*}$args
place [ttk::frame $w.tilebg] -relwidth 1 -relheight 1
}

Even though the ttk::frame is managed by place, you can still pack or
grid other widgets inside the toplevel.

Schelte.

At Thu, 16 Jan 2025 20:52:50 -0000 (UTC) Rich <rich@example.invalid> wrote:

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

Important gotcha: I *think* the OP is comtemplating packing (or gridding) his
megawidget. That would be bad practice. The widget (typically a frame)
should be returned unmanged. The caller of the function that creates the
megawidget is responsible for setting its geometry management:

proc Create-Some-Wonderful-MegaWidget {w args} {
# the frame for the MegaWidget
frame $w -class Megawidget
# pack an only child
pack [button $w.b -text "Useless Button" -command [list puts "who cares: $args"]]
# return the Megawidget
return $w
}

toplevel .foo
set w [Create-Some-Wonderful-MegaWidget .foo.bar]
grid $w

>
>
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services