Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Again "cannot use geometry manager pack inside ..."
3,481 views
Skip to first unread message
Gerhard Reithofer
Nov 11, 2012, 6:33:36 AM11/11/12
to
Hi TCLers,
once again I collided with the strict behavior of 8.6 when trying to
pack a widget controlled by grid - more exact an existing running
application throws this error.
Is there some "standard solution" documented anywhere or does onyone
know, how the necessary changed can be applied to repair this situation?
E.g. error message:
Error in startup script: cannot use geometry manager pack inside
.mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
grid
while executing
"pack $window.t -fill both -expand yes"
Can this message be used to change the pack command to another
"compatible" one which circumvents this error?
One idea could be to create a tool which is able to "analyze" the widget
structure and create warnings and/or give hints for "repairing" this
situation.
IMHO this is also a risk for creating megawidgets. E.g. if you use a
text inside of something, you don't know if it is used within a pack,
place or grid controlled widget.
Is this situation avoidable anyway?
TIA
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
once again I collided with the strict behavior of 8.6 when trying to
pack a widget controlled by grid - more exact an existing running
application throws this error.
Is there some "standard solution" documented anywhere or does onyone
know, how the necessary changed can be applied to repair this situation?
E.g. error message:
Error in startup script: cannot use geometry manager pack inside
.mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
grid
while executing
"pack $window.t -fill both -expand yes"
Can this message be used to change the pack command to another
"compatible" one which circumvents this error?
One idea could be to create a tool which is able to "analyze" the widget
structure and create warnings and/or give hints for "repairing" this
situation.
IMHO this is also a risk for creating megawidgets. E.g. if you use a
text inside of something, you don't know if it is used within a pack,
place or grid controlled widget.
Is this situation avoidable anyway?
TIA
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
Christian Gollwitzer
Nov 11, 2012, 10:04:26 AM11/11/12
to
Am 11.11.12 12:33, schrieb Gerhard Reithofer:
before, where the application would simply lockup completely using 100%
CPU and maybe X resources. Therefore thank God it's finally handled.
> One idea could be to create a tool which is able to "analyze" the widget
> structure and create warnings and/or give hints for "repairing" this
> situation.
>
> IMHO this is also a risk for creating megawidgets. E.g. if you use a
> text inside of something, you don't know if it is used within a pack,
> place or grid controlled widget.
> Is this situation avoidable anyway?
I can't understand what it is good for to have slaves managed by pack
and grid in the same master. You are free to put frames into grid
layouts and pack inside those and vice versa.
For megawidgets, which allow configurable children, usually a frame is
placed at the desired position. For example, itcl::dialog hase a
childsite command. There you are free to grid/pack/place whatever you want.
Christian
> Hi TCLers,
> once again I collided with the strict behavior of 8.6 when trying to
> pack a widget controlled by grid - more exact an existing running
> application throws this error.
>
> Is there some "standard solution" documented anywhere or does onyone
> know, how the necessary changed can be applied to repair this situation?
> E.g. error message:
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
>
> Can this message be used to change the pack command to another
> "compatible" one which circumvents this error?
The error has been introduced into 8.6 instead of the very odd behaviour
> once again I collided with the strict behavior of 8.6 when trying to
> pack a widget controlled by grid - more exact an existing running
> application throws this error.
>
> Is there some "standard solution" documented anywhere or does onyone
> know, how the necessary changed can be applied to repair this situation?
> E.g. error message:
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
>
> Can this message be used to change the pack command to another
> "compatible" one which circumvents this error?
before, where the application would simply lockup completely using 100%
CPU and maybe X resources. Therefore thank God it's finally handled.
> One idea could be to create a tool which is able to "analyze" the widget
> structure and create warnings and/or give hints for "repairing" this
> situation.
>
> IMHO this is also a risk for creating megawidgets. E.g. if you use a
> text inside of something, you don't know if it is used within a pack,
> place or grid controlled widget.
> Is this situation avoidable anyway?
and grid in the same master. You are free to put frames into grid
layouts and pack inside those and vice versa.
For megawidgets, which allow configurable children, usually a frame is
placed at the desired position. For example, itcl::dialog hase a
childsite command. There you are free to grid/pack/place whatever you want.
Christian
Gerhard Reithofer
Nov 11, 2012, 2:50:20 PM11/11/12
to
Hello Christian
On Sun, 11 Nov 2012, Christian Gollwitzer wrote:
> Am 11.11.12 12:33, schrieb Gerhard Reithofer:
> > Hi TCLers,
> > once again I collided with the strict behavior of 8.6 when trying to
> > pack a widget controlled by grid - more exact an existing running
> > application throws this error.
> >
> > Is there some "standard solution" documented anywhere or does onyone
> > know, how the necessary changed can be applied to repair this situation?
...
> > Can this message be used to change the pack command to another
> > "compatible" one which circumvents this error?
>
> The error has been introduced into 8.6 instead of the very odd behaviour
> before, where the application would simply lockup completely using 100% CPU
> and maybe X resources. Therefore thank God it's finally handled.
I know that problem (have discussed it many years ago at time when
BWidgets changed his ScrolledWindow behavior), but it is not DEFINTELY
the situation, that Tk hangs of this reason, it is only "sometimes" the
case, I don't know why.
> > One idea could be to create a tool which is able to "analyze" the widget
> > structure and create warnings and/or give hints for "repairing" this
> > situation.
> >
> > IMHO this is also a risk for creating megawidgets. E.g. if you use a
> > text inside of something, you don't know if it is used within a pack,
> > place or grid controlled widget.
> > Is this situation avoidable anyway?
>
> I can't understand what it is good for to have slaves managed by pack and grid
> in the same master. You are free to put frames into grid layouts and pack
> inside those and vice versa.
I don't think that people WANT to use pack in a grid mastered with
intent, but often they don't know how provided windows are controlled.
Some companies have several 100 scripts which must be ported.
At least I know a few departments which stopped testing 8.6 because of
that incalculable fact. Many programs run without problems for years,
but not with 8.6.
One idea was to use [winfo manager] to write portable scripts without
thinking of the master grid management, example:
text $w.t
if {[winfo manager $w] eq "grid"} {
grid $w.t -sticky news
} else {
pack $w.t -fill both -expand yes
}
But my 1st script where I tried to test this (my favorite ased),
does not provide the manager info!
Code from asedcon.tcl:
text $window.t -width $width -height $height -bg white
puts "\$window=$window"
puts "manager='[winfo manager $window]'"
$window=.mainframe.frame.pw.nb.fasedCon.sw
manager=''
Everything is working ...
Tcl 8.6:
$window=.mainframe.frame.pw.nb.fasedCon.sw
manager=''
grid $window.t -sticky news
solved the problem - I expected to have solved with the code above.
But back to my original question - taking into account that many scripts
already exist:
Is it possible to find the problematic code parts which have to be
ported - except manually check everything?
Is there a simple way to write "portable" programs which do the right
thing in the rigth situation when using "foreign" packages (like
BWidgets) with Tcl/Tk only (no binary extensions)?
...
Thank you very much,
Gerhard
On Sun, 11 Nov 2012, Christian Gollwitzer wrote:
> Am 11.11.12 12:33, schrieb Gerhard Reithofer:
> > Hi TCLers,
> > once again I collided with the strict behavior of 8.6 when trying to
> > pack a widget controlled by grid - more exact an existing running
> > application throws this error.
> >
> > Is there some "standard solution" documented anywhere or does onyone
> > know, how the necessary changed can be applied to repair this situation?
> > Can this message be used to change the pack command to another
> > "compatible" one which circumvents this error?
>
> The error has been introduced into 8.6 instead of the very odd behaviour
> before, where the application would simply lockup completely using 100% CPU
> and maybe X resources. Therefore thank God it's finally handled.
BWidgets changed his ScrolledWindow behavior), but it is not DEFINTELY
the situation, that Tk hangs of this reason, it is only "sometimes" the
case, I don't know why.
> > One idea could be to create a tool which is able to "analyze" the widget
> > structure and create warnings and/or give hints for "repairing" this
> > situation.
> >
> > IMHO this is also a risk for creating megawidgets. E.g. if you use a
> > text inside of something, you don't know if it is used within a pack,
> > place or grid controlled widget.
> > Is this situation avoidable anyway?
>
> I can't understand what it is good for to have slaves managed by pack and grid
> in the same master. You are free to put frames into grid layouts and pack
> inside those and vice versa.
intent, but often they don't know how provided windows are controlled.
Some companies have several 100 scripts which must be ported.
At least I know a few departments which stopped testing 8.6 because of
that incalculable fact. Many programs run without problems for years,
but not with 8.6.
One idea was to use [winfo manager] to write portable scripts without
thinking of the master grid management, example:
text $w.t
if {[winfo manager $w] eq "grid"} {
grid $w.t -sticky news
} else {
pack $w.t -fill both -expand yes
}
But my 1st script where I tried to test this (my favorite ased),
does not provide the manager info!
Code from asedcon.tcl:
text $window.t -width $width -height $height -bg white
puts "\$window=$window"
puts "manager='[winfo manager $window]'"
pack $window.t -fill both -expand yes
Tcl 8.5:
$window=.mainframe.frame.pw.nb.fasedCon.sw
manager=''
Everything is working ...
Tcl 8.6:
$window=.mainframe.frame.pw.nb.fasedCon.sw
manager=''
Error in startup script: cannot use geometry manager pack inside
.mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
grid
Finally replacing the
.mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
grid
pack $window.t -fill both -expand yes
manually by
grid $window.t -sticky news
solved the problem - I expected to have solved with the code above.
But back to my original question - taking into account that many scripts
already exist:
Is it possible to find the problematic code parts which have to be
ported - except manually check everything?
Is there a simple way to write "portable" programs which do the right
thing in the rigth situation when using "foreign" packages (like
BWidgets) with Tcl/Tk only (no binary extensions)?
...
Thank you very much,
Gerhard
Gerald W. Lester
Nov 11, 2012, 7:54:57 PM11/11/12
to
On 11/11/12 5:33 AM, Gerhard Reithofer wrote:
> ...
You do realize the value of $window is ".mainframe.frame.pw.nb.fasedCon.sw"?
> IMHO this is also a risk for creating megawidgets. E.g. if you use a
> text inside of something, you don't know if it is used within a pack,
> place or grid controlled widget.
It only applies to the direct children of the widget, not all of its
dependents. The megawidget would only use one thing to manage its direct
descendents.
> Is this situation avoidable anyway?
Yes, don't do it!
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
> ...
> E.g. error message:
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
>
> ...
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
>
You do realize the value of $window is ".mainframe.frame.pw.nb.fasedCon.sw"?
> IMHO this is also a risk for creating megawidgets. E.g. if you use a
> text inside of something, you don't know if it is used within a pack,
> place or grid controlled widget.
dependents. The megawidget would only use one thing to manage its direct
descendents.
> Is this situation avoidable anyway?
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
Uwe Klein
Nov 12, 2012, 3:28:46 AM11/12/12
to
Gerhard Reithofer wrote:
> Is there a simple way to write "portable" programs which do the right
> thing in the rigth situation when using "foreign" packages (like
> BWidgets) with Tcl/Tk only (no binary extensions)?
If you can't fix the source
> Is there a simple way to write "portable" programs which do the right
> thing in the rigth situation when using "foreign" packages (like
> BWidgets) with Tcl/Tk only (no binary extensions)?
the tcl way to mend such things would imho
go by way of redefining some command.
i.e.
rename pack native_pack
proc pack args {
if {[catch [linsert $args 0 native_pack] cerr]} {
switch $cerr ...
}
uwe
Christian Gollwitzer
Nov 12, 2012, 7:53:05 AM11/12/12
to
Hi Gerhard,
Am 11.11.12 20:50, schrieb Gerhard Reithofer:
for one master scattered through all the source code? As you mention
megawidgets, any reasonable megawidget framework does NOT grid/pack the
topmost frame itself, but simply returns it to the caller. If you have
functions like this
proc maketext {frame some args} { text $frame.t; pack $frame.t }
# caller
maketext .frame.some.long some args
this is broken. You should instead write
proc maketext { w some args } {
text $w;
#dont pack;
return $w
}
# caller
pack [maketext .frame.some.long.t]
This way the caller has full control over the widget and can pack/grid
to his liking. maketext than behaves like a regular widget. I recommend
to use a real megawidget framework (like snit) to handle this stuff,
though - it takes care of all the gory details.
> Some companies have several 100 scripts which must be ported.
> At least I know a few departments which stopped testing 8.6 because of
> that incalculable fact. Many programs run without problems for years,
> but not with 8.6.
I'd say these scripts have been broken before. IIRC the reason for the
lockup is that both grid and pack try to resize the master window to
different sizes, causing an endless series of Configure events. It is
therefore actually possible to to grid ad pack into the same master by
switching -propagate to off. However, I'm very much convinced this isn't
the solution, since it does not make sense to have a gridded and pakced
wigets in the same master. I simply can't think of a layout where
something like this would be hlepful.
> Is it possible to find the problematic code parts which have to be
> ported - except manually check everything?
Does the error message not find the buggy lines for you? Is the
problematic pack/grid triggered at runtime?
Christian
Am 11.11.12 20:50, schrieb Gerhard Reithofer:
> I don't think that people WANT to use pack in a grid mastered with
> intent, but often they don't know how provided windows are controlled.
Then your program design is seriously broken. Are the pack/grid commands
> intent, but often they don't know how provided windows are controlled.
for one master scattered through all the source code? As you mention
megawidgets, any reasonable megawidget framework does NOT grid/pack the
topmost frame itself, but simply returns it to the caller. If you have
functions like this
proc maketext {frame some args} { text $frame.t; pack $frame.t }
# caller
maketext .frame.some.long some args
this is broken. You should instead write
proc maketext { w some args } {
text $w;
#dont pack;
return $w
}
# caller
pack [maketext .frame.some.long.t]
This way the caller has full control over the widget and can pack/grid
to his liking. maketext than behaves like a regular widget. I recommend
to use a real megawidget framework (like snit) to handle this stuff,
though - it takes care of all the gory details.
> Some companies have several 100 scripts which must be ported.
> At least I know a few departments which stopped testing 8.6 because of
> that incalculable fact. Many programs run without problems for years,
> but not with 8.6.
lockup is that both grid and pack try to resize the master window to
different sizes, causing an endless series of Configure events. It is
therefore actually possible to to grid ad pack into the same master by
switching -propagate to off. However, I'm very much convinced this isn't
the solution, since it does not make sense to have a gridded and pakced
wigets in the same master. I simply can't think of a layout where
something like this would be hlepful.
> Is it possible to find the problematic code parts which have to be
> ported - except manually check everything?
problematic pack/grid triggered at runtime?
Christian
Robert Heller
Nov 12, 2012, 10:04:34 AM11/12/12
to
At Mon, 12 Nov 2012 13:53:05 +0100 Christian Gollwitzer <auri...@gmx.de> wrote:
>
> Hi Gerhard,
>
> Am 11.11.12 20:50, schrieb Gerhard Reithofer:
> > I don't think that people WANT to use pack in a grid mastered with
> > intent, but often they don't know how provided windows are controlled.
>
> Then your program design is seriously broken. Are the pack/grid commands
> for one master scattered through all the source code? As you mention
> megawidgets, any reasonable megawidget framework does NOT grid/pack the
> topmost frame itself, but simply returns it to the caller. If you have
> functions like this
>
> proc maketext {frame some args} { text $frame.t; pack $frame.t }
>
> # caller
> maketext .frame.some.long some args
>
> this is broken. You should instead write
>
> proc maketext { w some args } {
> text $w;
> #dont pack;
> return $w
> }
>
> # caller
> pack [maketext .frame.some.long.t]
>
> This way the caller has full control over the widget and can pack/grid
> to his liking. maketext than behaves like a regular widget. I recommend
> to use a real megawidget framework (like snit) to handle this stuff,
> though - it takes care of all the gory details.
Right. The way BWidget does things where it provides some sort of
>
> Hi Gerhard,
>
> Am 11.11.12 20:50, schrieb Gerhard Reithofer:
> > I don't think that people WANT to use pack in a grid mastered with
> > intent, but often they don't know how provided windows are controlled.
>
> Then your program design is seriously broken. Are the pack/grid commands
> for one master scattered through all the source code? As you mention
> megawidgets, any reasonable megawidget framework does NOT grid/pack the
> topmost frame itself, but simply returns it to the caller. If you have
> functions like this
>
> proc maketext {frame some args} { text $frame.t; pack $frame.t }
>
> # caller
> maketext .frame.some.long some args
>
> this is broken. You should instead write
>
> proc maketext { w some args } {
> text $w;
> #dont pack;
> return $w
> }
>
> # caller
> pack [maketext .frame.some.long.t]
>
> This way the caller has full control over the widget and can pack/grid
> to his liking. maketext than behaves like a regular widget. I recommend
> to use a real megawidget framework (like snit) to handle this stuff,
> though - it takes care of all the gory details.
'container' type widget is to provide an *empty* frame (eg with no
provided children) at the place where 'user' code would place/pack/grid
childred widgets and provides a 'getframe' method to retrieve this
frame: 'pack [text [.foocontainer getframe].t]'. 'User' code (eg other
programmers) have no reason to mess with or add additional widgets to
containers *internally* managed by a megawidget. All *sane* megawidget
containers create an 'empty' frame at the core place where user code
(eg other programmers) can place widgets and can use whatever flavor of
geometry manager makes sense. All widget creators simply return the
toplevel widget and make NO attempt to apply a geometry manager to it
-- it is up to the user code to apply a geometry manager to
place/pack/grid it into its parent container (as shown above by
Christian).
>
>
> > Some companies have several 100 scripts which must be ported.
> > At least I know a few departments which stopped testing 8.6 because of
> > that incalculable fact. Many programs run without problems for years,
> > but not with 8.6.
>
>
> I'd say these scripts have been broken before. IIRC the reason for the
> lockup is that both grid and pack try to resize the master window to
> different sizes, causing an endless series of Configure events. It is
> therefore actually possible to to grid ad pack into the same master by
> switching -propagate to off. However, I'm very much convinced this isn't
> the solution, since it does not make sense to have a gridded and pakced
> wigets in the same master. I simply can't think of a layout where
> something like this would be hlepful.
>
>
> > Is it possible to find the problematic code parts which have to be
> > ported - except manually check everything?
>
> Does the error message not find the buggy lines for you? Is the
> problematic pack/grid triggered at runtime?
>
> Christian
>
>
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
Emiliano
Nov 12, 2012, 11:37:09 AM11/12/12
to
On 11 nov, 08:33, Gerhard Reithofer <gerhard.reitho...@tech-edv.co.at>
wrote:
It always has been.
>
> Is there some "standard solution" documented anywhere or does onyone
> know, how the necessary changed can be applied to repair this situation?
> E.g. error message:
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
If the trailing sw widget is a BWidget ScrolledWindow, then the code
is buggy. You are not supposed to use geometry managers to put a
widget
inside a scrolledwindow, but use its "setwidget" subcommand.
I've found code in the wild which happens to have the same
bug. Apparently, there is a widespread misundertanding on how
to use BWidget's ScrolledWindow.
In the case of ASED, simply commenting out the offending [pack]s
fixes the issue.
Regards
Emiliano
wrote:
> Hi TCLers,
> once again I collided with the strict behavior of 8.6 when trying to
> pack a widget controlled by grid - more exact an existing running
> application throws this error.
Trying to use pack and grid on the same master is an error.
> once again I collided with the strict behavior of 8.6 when trying to
> pack a widget controlled by grid - more exact an existing running
> application throws this error.
It always has been.
>
> Is there some "standard solution" documented anywhere or does onyone
> know, how the necessary changed can be applied to repair this situation?
> E.g. error message:
> Error in startup script: cannot use geometry manager pack inside
> .mainframe.frame.pw.nb.fasedCon.sw which already has slaves managed by
> grid
> while executing
> "pack $window.t -fill both -expand yes"
is buggy. You are not supposed to use geometry managers to put a
widget
inside a scrolledwindow, but use its "setwidget" subcommand.
I've found code in the wild which happens to have the same
bug. Apparently, there is a widespread misundertanding on how
to use BWidget's ScrolledWindow.
In the case of ASED, simply commenting out the offending [pack]s
fixes the issue.
Regards
Emiliano
Gerhard Reithofer
Nov 14, 2012, 4:39:54 PM11/14/12
to
Hallo Uwe,
a practical approach - thank you very much.
Gerhard Reithofer
Nov 14, 2012, 5:27:52 PM11/14/12
to
Hallo Christian,
On Mon, 12 Nov 2012, Christian Gollwitzer wrote:
> Hi Gerhard,
>
> Am 11.11.12 20:50, schrieb Gerhard Reithofer:
> > I don't think that people WANT to use pack in a grid mastered with
> > intent, but often they don't know how provided windows are controlled.
>
> Then your program design is seriously broken. Are the pack/grid commands for
> one master scattered through all the source code? As you mention megawidgets,
> any reasonable megawidget framework does NOT grid/pack the topmost frame
> itself, but simply returns it to the caller. If you have functions like this
I'm just using an existing extension (from an external user) which is in
productive use for many years - why is MY design broken?
...
> > Some companies have several 100 scripts which must be ported.
> > At least I know a few departments which stopped testing 8.6 because of
> > that incalculable fact. Many programs run without problems for years,
> > but not with 8.6.
>
>
> I'd say these scripts have been broken before. IIRC the reason for the lockup
> is that both grid and pack try to resize the master window to different sizes,
> causing an endless series of Configure events. It is therefore actually
> possible to to grid ad pack into the same master by switching -propagate to
> off. However, I'm very much convinced this isn't the solution, since it does
> not make sense to have a gridded and pakced wigets in the same master. I
> simply can't think of a layout where something like this would be hlepful.
More clearly:
I'm talking about code written in a period of time of over 10 years, by
different programmers, some of them are not present anymore. Some of the
scripts are mission critical, they are used on several 100 workstations.
I'm NOT talking about code that is written now!
Open questions are:
# Which one of "these scripts have been broken before"?
# How many will have to be ported?
# How much time/money will it cost?
# How secure will the porting be?
# How many "bugs" (you call "broken") will be missed?
No one can answer these questions seriously, therefore no one will
approve the upgrade?
...
> Does the error message not find the buggy lines for you? Is the problematic
> pack/grid triggered at runtime?
With some effort the "buggy lines" can be located.
Currently only the error messages at runtime have been used to make
some tests. Of cource it is not secured that all program parts will be
reached which include the investigated bugs when testing cursory.
But some of them are not easy to understand (like in my example where
the [winfo manager] does not provide the manager info), the pack/grid
lines have been located in different code parts, partially in other
files.
The real problem is the large code base.
Thank you,
On Mon, 12 Nov 2012, Christian Gollwitzer wrote:
> Hi Gerhard,
>
> Am 11.11.12 20:50, schrieb Gerhard Reithofer:
> > I don't think that people WANT to use pack in a grid mastered with
> > intent, but often they don't know how provided windows are controlled.
>
> Then your program design is seriously broken. Are the pack/grid commands for
> one master scattered through all the source code? As you mention megawidgets,
> any reasonable megawidget framework does NOT grid/pack the topmost frame
> itself, but simply returns it to the caller. If you have functions like this
productive use for many years - why is MY design broken?
...
> > Some companies have several 100 scripts which must be ported.
> > At least I know a few departments which stopped testing 8.6 because of
> > that incalculable fact. Many programs run without problems for years,
> > but not with 8.6.
>
>
> I'd say these scripts have been broken before. IIRC the reason for the lockup
> is that both grid and pack try to resize the master window to different sizes,
> causing an endless series of Configure events. It is therefore actually
> possible to to grid ad pack into the same master by switching -propagate to
> off. However, I'm very much convinced this isn't the solution, since it does
> not make sense to have a gridded and pakced wigets in the same master. I
> simply can't think of a layout where something like this would be hlepful.
I'm talking about code written in a period of time of over 10 years, by
different programmers, some of them are not present anymore. Some of the
scripts are mission critical, they are used on several 100 workstations.
I'm NOT talking about code that is written now!
Open questions are:
# Which one of "these scripts have been broken before"?
# How many will have to be ported?
# How much time/money will it cost?
# How secure will the porting be?
# How many "bugs" (you call "broken") will be missed?
No one can answer these questions seriously, therefore no one will
approve the upgrade?
...
> Does the error message not find the buggy lines for you? Is the problematic
> pack/grid triggered at runtime?
Currently only the error messages at runtime have been used to make
some tests. Of cource it is not secured that all program parts will be
reached which include the investigated bugs when testing cursory.
But some of them are not easy to understand (like in my example where
the [winfo manager] does not provide the manager info), the pack/grid
lines have been located in different code parts, partially in other
files.
The real problem is the large code base.
Thank you,
Christian Gollwitzer
Nov 15, 2012, 6:11:42 AM11/15/12
to
Hi Gerhard,
Am 14.11.12 23:27, schrieb Gerhard Reithofer:
where you have pack/grid invocations for the same master in different
places is broken, as it can go wrong easily. After all, that's what is
causing you trouble.
Using pack and grid in the same master has always been an error, even if
it seemingly works in 8.5 (with the exception of pack propagate 0).
That's the same thing like "undefined behaviour" in C - it can work, but
will probably break when the implementation changes. For instance, this
pack/grid thing behaved differently in 8.5 between Win,X11 and OSX.
>
>>> Some companies have several 100 scripts which must be ported.
>>> At least I know a few departments which stopped testing 8.6 because of
>>> that incalculable fact. Many programs run without problems for years,
>>> but not with 8.6.
>>
> # How many will have to be ported?
All of them from #1, except if you simply stick to 8.5
> # How much time/money will it cost?
I have no insight into the codebase. That question can only be
answered/estimated with a serious look at the code.
> # How secure will the porting be?
In what sense "secure"? Do you mean that it doesn't break again? That
depends on the fix: If using Uwe's workaround, it is very fragile. If
redesignig in a way that all geometry operations are in one place, it
should be pretty safe.
> # How many "bugs" (you call "broken") will be missed?
??? You will always have more bugs than you can think of. There is only
very few masterpieces of software which is provably free of bugs. The
question you ask is provable unanswerable, since it reduces to the
halting problem.
> the pack/grid
> lines have been located in different code parts, partially in other
> files.
Well THAT is the design issue I'm talking about. As you mention BWidget,
have you seen Emilianos reply?
Quoting from:
http://wiki.tcl.tk/9924
package require BWidget
# Make a text-widget scrollable
set sw [ScrolledWindow .sw]
pack $sw -fill both -expand true
set txt [text $sw.txt -wrap none]
$sw setwidget $txt
Here, it would be an error to do
pack $txt
as you can't know how this is managed inside ScrolledWindow. Therefore,
there is the "setwidget" method which knows how to do it correctly. The
same thing applies, for instance, for ScrolledFrame - it has a
"getframe" method which gives you the place where you can freely
pack/place/grid.
Another example would be procedures that construct wigets *and*
pack/grid them. This is a bad idea, the solution would be to return the
widgets exactly like real Tk widgets (and megawidget frameworks) do it.
Then, all grid/pack commands for the same master are in one place and
it's evident what to use.
>
> The real problem is the large code base.
It boils down to either
A) live with the bug and stick to 8.5
B) Use ugly fragile workarounds if you desperately need some new 8.6
feature and live with a break in the future
C) Fix the buggy scripts
Christian
Am 14.11.12 23:27, schrieb Gerhard Reithofer:
> On Mon, 12 Nov 2012, Christian Gollwitzer wrote:
>> Then your program design is seriously broken. Are the pack/grid commands for
>> one master scattered through all the source code? As you mention megawidgets,
>> any reasonable megawidget framework does NOT grid/pack the topmost frame
>> itself, but simply returns it to the caller. If you have functions like this
>
> I'm just using an existing extension (from an external user) which is in
> productive use for many years - why is MY design broken?
>
Sorry, I didn't want to offend you. All I'm saying is that a design,
>> Then your program design is seriously broken. Are the pack/grid commands for
>> one master scattered through all the source code? As you mention megawidgets,
>> any reasonable megawidget framework does NOT grid/pack the topmost frame
>> itself, but simply returns it to the caller. If you have functions like this
>
> I'm just using an existing extension (from an external user) which is in
> productive use for many years - why is MY design broken?
>
where you have pack/grid invocations for the same master in different
places is broken, as it can go wrong easily. After all, that's what is
causing you trouble.
Using pack and grid in the same master has always been an error, even if
it seemingly works in 8.5 (with the exception of pack propagate 0).
That's the same thing like "undefined behaviour" in C - it can work, but
will probably break when the implementation changes. For instance, this
pack/grid thing behaved differently in 8.5 between Win,X11 and OSX.
>
>>> Some companies have several 100 scripts which must be ported.
>>> At least I know a few departments which stopped testing 8.6 because of
>>> that incalculable fact. Many programs run without problems for years,
>>> but not with 8.6.
>>
> More clearly:
> I'm talking about code written in a period of time of over 10 years, by
> different programmers, some of them are not present anymore. Some of the
> scripts are mission critical, they are used on several 100 workstations.
>
> I'm NOT talking about code that is written now!
>
> Open questions are:
> # Which one of "these scripts have been broken before"?
All that use pack and grid in the same master.
> I'm talking about code written in a period of time of over 10 years, by
> different programmers, some of them are not present anymore. Some of the
> scripts are mission critical, they are used on several 100 workstations.
>
> I'm NOT talking about code that is written now!
>
> Open questions are:
> # Which one of "these scripts have been broken before"?
> # How many will have to be ported?
> # How much time/money will it cost?
answered/estimated with a serious look at the code.
> # How secure will the porting be?
depends on the fix: If using Uwe's workaround, it is very fragile. If
redesignig in a way that all geometry operations are in one place, it
should be pretty safe.
> # How many "bugs" (you call "broken") will be missed?
very few masterpieces of software which is provably free of bugs. The
question you ask is provable unanswerable, since it reduces to the
halting problem.
> the pack/grid
> lines have been located in different code parts, partially in other
> files.
have you seen Emilianos reply?
Quoting from:
http://wiki.tcl.tk/9924
package require BWidget
# Make a text-widget scrollable
set sw [ScrolledWindow .sw]
pack $sw -fill both -expand true
set txt [text $sw.txt -wrap none]
$sw setwidget $txt
Here, it would be an error to do
pack $txt
as you can't know how this is managed inside ScrolledWindow. Therefore,
there is the "setwidget" method which knows how to do it correctly. The
same thing applies, for instance, for ScrolledFrame - it has a
"getframe" method which gives you the place where you can freely
pack/place/grid.
Another example would be procedures that construct wigets *and*
pack/grid them. This is a bad idea, the solution would be to return the
widgets exactly like real Tk widgets (and megawidget frameworks) do it.
Then, all grid/pack commands for the same master are in one place and
it's evident what to use.
>
> The real problem is the large code base.
A) live with the bug and stick to 8.5
B) Use ugly fragile workarounds if you desperately need some new 8.6
feature and live with a break in the future
C) Fix the buggy scripts
Christian
Gerhard Reithofer
Nov 15, 2012, 2:35:00 PM11/15/12
to
Hello Christian,
On Thu, 15 Nov 2012, Christian Gollwitzer wrote:
> Hi Gerhard,
>
> Am 14.11.12 23:27, schrieb Gerhard Reithofer:
> > On Mon, 12 Nov 2012, Christian Gollwitzer wrote:
> > > Then your program design is seriously broken. Are the pack/grid commands
...
Yes, I've read his reply - thank you Emiliano!
I don't need an explanation why the situation is so, I know the reason.
I need arguments why a company should invest time for porting old
scripts to avoid errors at runtime - if switching to 8.6.
...
> > The real problem is the large code base.
>
> It boils down to either
> A) live with the bug and stick to 8.5
>
> B) Use ugly fragile workarounds if you desperately need some new 8.6 feature
> and live with a break in the future
>
> C) Fix the buggy scripts
Clear answers, I'm afraid that A) will be chosen :(
Bye and thank you very much,
On Thu, 15 Nov 2012, Christian Gollwitzer wrote:
> Hi Gerhard,
>
> Am 14.11.12 23:27, schrieb Gerhard Reithofer:
> > On Mon, 12 Nov 2012, Christian Gollwitzer wrote:
> > > Then your program design is seriously broken. Are the pack/grid commands
I don't need an explanation why the situation is so, I know the reason.
I need arguments why a company should invest time for porting old
scripts to avoid errors at runtime - if switching to 8.6.
...
> > The real problem is the large code base.
>
> It boils down to either
> A) live with the bug and stick to 8.5
>
> B) Use ugly fragile workarounds if you desperately need some new 8.6 feature
> and live with a break in the future
>
> C) Fix the buggy scripts
Bye and thank you very much,
Don Porter
Nov 19, 2012, 10:57:45 AM11/19/12
to
>>> The real problem is the large code base.
>> It boils down to either
>> A) live with the bug and stick to 8.5
> Clear answers, I'm afraid that A) will be chosen :(
Please raise this issue in the Tk Tracker. Set Priority to 9.
Set Group to 8.6.0. Include as much detail from this thread as
you need to make it clear to maintainers that this would block
your migration to 8.6. Thanks.
https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Gerhard Reithofer
Nov 25, 2012, 3:59:24 PM11/25/12
to
Hi,
I forgot to publish my answer to Don's reply as I answered him directly
by mail.
Here's my answer again for this NG.
On Mon, 19 Nov 2012, Don Porter wrote:
>
> > > > The real problem is the large code base.
>
> > > It boils down to either
> > > A) live with the bug and stick to 8.5
>
> > Clear answers, I'm afraid that A) will be chosen :(
>
> Please raise this issue in the Tk Tracker. Set Priority to 9.
> Set Group to 8.6.0. Include as much detail from this thread as
> you need to make it clear to maintainers that this would block
> your migration to 8.6. Thanks.
>
> https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
I agreed in the discussion that this problem cannot be "solved".
There is no migration "planned", only investigations if a "silent
transition" to 8.6 is possible have been made. The effect with the
discussed refuse of existing running code was taken as argument to
discontinue the project - at least for the moment.
Furthermore I'm rather sure, that a short term switch to 8.6 is out of
discussion, because it is to new and the most departments do not install
real new products. Even I'm not convinced about the new version because
I noticed also other problems, which I'm analyzing currently. Multi
platform issues (32/64 bit Tcl), in conjunction with platform specific
drivers (like Oracle) or TWAPI etc. must be clarified and investigated
in detail, etc.
In that context the "geometry manage" problem is only one of many
reasons for delaying the upgrade.
Even waiting for Tcl 9 is an option, because larger changes can be
expected and the enforcement to invest time for migration can be better
reasoned.
Nevertheless this may lead to discussions how development for longterm
projects can be supported better.
As an example I really miss deprecation warnings as they are
conventional in compiler languages (Java, C/C++, ..) and also in
interfaces, e. g. I know runtime warnings of library functions (like in
Teamcenter) which inform the user about the fact, that a specific
function will be abandoned in future versions. Such warnings (which must
be suppressable of course by using ENV variables or command line
switches) would avoid many similar problems, because simple changes at
an early stage would be made to avoid this.
Where I'm more surprised is the fact that a bug - which I reported some
time ago - about a crashing wish on Linux, when drawing many dashed
lines seems not become repaired in near future, even not in 8.6.
Bye and thank you for your support,
I forgot to publish my answer to Don's reply as I answered him directly
by mail.
Here's my answer again for this NG.
On Mon, 19 Nov 2012, Don Porter wrote:
>
> > > > The real problem is the large code base.
>
> > > It boils down to either
> > > A) live with the bug and stick to 8.5
>
> > Clear answers, I'm afraid that A) will be chosen :(
>
> Please raise this issue in the Tk Tracker. Set Priority to 9.
> Set Group to 8.6.0. Include as much detail from this thread as
> you need to make it clear to maintainers that this would block
> your migration to 8.6. Thanks.
>
> https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
There is no migration "planned", only investigations if a "silent
transition" to 8.6 is possible have been made. The effect with the
discussed refuse of existing running code was taken as argument to
discontinue the project - at least for the moment.
Furthermore I'm rather sure, that a short term switch to 8.6 is out of
discussion, because it is to new and the most departments do not install
real new products. Even I'm not convinced about the new version because
I noticed also other problems, which I'm analyzing currently. Multi
platform issues (32/64 bit Tcl), in conjunction with platform specific
drivers (like Oracle) or TWAPI etc. must be clarified and investigated
in detail, etc.
In that context the "geometry manage" problem is only one of many
reasons for delaying the upgrade.
Even waiting for Tcl 9 is an option, because larger changes can be
expected and the enforcement to invest time for migration can be better
reasoned.
Nevertheless this may lead to discussions how development for longterm
projects can be supported better.
As an example I really miss deprecation warnings as they are
conventional in compiler languages (Java, C/C++, ..) and also in
interfaces, e. g. I know runtime warnings of library functions (like in
Teamcenter) which inform the user about the fact, that a specific
function will be abandoned in future versions. Such warnings (which must
be suppressable of course by using ENV variables or command line
switches) would avoid many similar problems, because simple changes at
an early stage would be made to avoid this.
Where I'm more surprised is the fact that a bug - which I reported some
time ago - about a crashing wish on Linux, when drawing many dashed
lines seems not become repaired in near future, even not in 8.6.
Bye and thank you for your support,
alm...@gmail.com
Nov 7, 2016, 12:38:46 AM11/7/16
to
Hi,
I am encountering this error running XCrysDen software (http://www.xcrysden.org/)
The error text begins with: "cannot use geometry manager pack inside .a4.sw which already has slaves managed by grid" full detil here: http://pastebin.com/AJvvx6s4
Python version 2.7.3, Tkinter.TkVersion 8.6. The error does not arise using Tkinter.TkVersion 8.5!
I am encountering this error running XCrysDen software (http://www.xcrysden.org/)
The error text begins with: "cannot use geometry manager pack inside .a4.sw which already has slaves managed by grid" full detil here: http://pastebin.com/AJvvx6s4
Python version 2.7.3, Tkinter.TkVersion 8.6. The error does not arise using Tkinter.TkVersion 8.5!
Gerald W. Lester
Nov 7, 2016, 3:32:19 PM11/7/16
to
On 11/6/16 11:38 PM, alm...@gmail.com wrote:
> Hi,
>
> I am encountering this error running XCrysDen software (http://www.xcrysden.org/)
>
> The error text begins with: "cannot use geometry manager pack inside .a4.sw which already has slaves
> managed by grid" full detil here: http://pastebin.com/AJvvx6s4
>
> Python version 2.7.3, Tkinter.TkVersion 8.6. The error does not arise using Tkinter.TkVersion 8.5!
That is because 8.6 has an explicit check for this and 8.5 did not.
> Hi,
>
> I am encountering this error running XCrysDen software (http://www.xcrysden.org/)
>
> The error text begins with: "cannot use geometry manager pack inside .a4.sw which already has slaves
> managed by grid" full detil here: http://pastebin.com/AJvvx6s4
>
> Python version 2.7.3, Tkinter.TkVersion 8.6. The error does not arise using Tkinter.TkVersion 8.5!
Depending on exactly what was going on, 8.5 could have went into an infinite
loop.
To put it bluntly -- this is not a Tk bug. This is your bug. Don't do it.
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
0 new messages