lower and raise commands

[adilseb...@gmail.com]

Please can someone explains what is the utility of lower and raise in geometry management because pack and grid do everything and the exemple given by tk's documentation makes things more obscure

Thanks for help

[Luis Alejandro Muzzachiodi]

Lower and raise are commands to change the staking order of windows.
Pack and grid are geometry managers (as well as pack and place).
What is the example you mentioned ?

[adilseb...@gmail.com]

The exemple in raise command's documentation.
So the problem is I don't the difference between "stacking order" and "geometry management",I am sorry if I ask you an explanation about those two concepts
My apologises

[Gerald Lester]

Think of the widgets as opaque plates the are stacked on the table from
bottom to top in the order they are created (i.e. last widget created is
the top most plate) -- this is stacking order.

The geometry management is sliding plates out of the stack to where you
want them on the table -- but they magically always "float" at the same
"level" (which could "hide" some of the other plates". Raise and lower
are used to change the level they are floating at.

Does that help?

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[adilseb...@gmail.com]

from your explanation:

1)"stacking order": is like stack and queue for data's collection.

2)in comparison with "HTML" and "CSS":
-packing order: is like packing HTML's elements without any formating => " pack" command without options ( just packing Tk's widgets)
-geometry management: is like the " Float" option in CSS => "pack" command with options
-"lower" and "raise" commands work with widgets organized by geometry management ("pack" command with option)
- the problem solved by "lower" and "raise" commands is when tha parent widget don't have enough space to hold its childrens widgets managed by "geometry management", but what if they are just stacked without enough space?

[Rich]

adilseb...@gmail.com wrote:
> from your explanation:
>
> 1)"stacking order": is like stack and queue for data's collection.

Similar to "stack" - nothing like queue.

Think of a set of old-style transparency sheets for an old-style
overhead projector. If you put three transparencies one on top of the
other, you get a combined image of the three on screen.

Stacking order refers to the order in which the transparencies overlay
each other. The top item is on top, the bottom item is on the bottom
(lowest level) and the others are in between.

>
> 2)in comparison with "HTML" and "CSS":
> -packing order: is like packing HTML's elements without any formating

> - => " pack" command without options ( just packing Tk's widgets)

There is no "packing order". There is "stacking order" which is
equivalent to CSS's z-index property.

The geometry management relates to laying the items out in 2-D space on
a plane so they fit inside the boundaries of a box on the plane.

Stacking order adds a third dimension (so you now have a 3-D layout of
widgets) where some of the 2-D planes (the widgets) actually are above
(or below) and overlap other 2-D planes (other widgets).

> -geometry management: is like the " Float" option in CSS => "pack"

> - command with options

No. Geometry management is more like automatic specification of width,
height, and some of the "display" properties.

> -"lower" and "raise" commands work with widgets organized by geometry

> - management ("pack" command with option)

Yes, but only in the sense that a widget is invisible until it is
managed by a geometry manager. Lower and raise allow you to directly
control the CSS "z-index" property (should you wish to do so).

> - the problem solved by "lower" and "raise" commands is when tha

> - parent widget don't have enough space to hold its childrens widgets
> - managed by "geometry management", but what if they are just stacked
> - without enough space?

No and no. Lower and raise decide who occludes (covers up) whom when
their boundaries overlap (i.e., exactly what CSS's z-index property
handles).

[adilseb...@gmail.com]

Thank you so much I am very grateful for your explanation, in summary those two options are equivelant to CSS "Z-index" property. my last question is: when you change the parent of a widget with another parent it doesn't appears until you rise it?

[Mike Griffiths]

On Saturday, 16 December 2017 19:39:51 UTC, adilseb...@gmail.com wrote:
> Thank you so much I am very grateful for your explanation, in summary those two options are equivelant to CSS "Z-index" property. my last question is: when you change the parent of a widget with another parent it doesn't appears until you rise it?

If memory serves, unless you specifically raise or lower widgets, the most recently created widget is on top. Since you normally create a parent/container widget, then create a child widget and pack/place/grid it in the parent, everything is generally how it should be by default. If you're using pack $widget -in $sibling or something like that, though, you may need to [raise $widget].

[Rich]

A widget appears on screen when:

1) it is managed by a geometry manager
and
2) another widget does not cover all parts of it with an opaque surface

The pack, grid, and place commands allow you to control #1.

The raise and lower commands allow you to control #2.