Why is top dot not top? Design flaw? 
Author Message
 Why is top dot not top? Design flaw?

Hello!

    There is a very irritating design feature in Tk which does
not seem to make much sense, and makes Tk programming harder
than it should be.

    Why is the top-level window called '.', rather than '.top'?
There are several {*filter*} things about having . as the toplevel
window:

    - It is not obvious whether an arbitrary widget .fred is
      a toplevel or a child of .

    - Given an arbitrary frame/toplevel $x, you cannot say both
          frame $x.newframe
          $x cget -background
      because this code breaks when passed '.'
      You need to resort to horrible hacks such as
        if {(![string compare $top "."])||(![string length $top])} {
            set root ""
            set top "."
        }

    - It is not possible to get the children of ., as
        winfo children .
      gives you both the children of . and all toplevels

All these problems would go away if the default toplevel was .top and
. was the parent of all toplevels?

I guess it is far too late to change something like this, but it
does seem like a pretty ugly design.

-peter.



Sat, 12 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?

Quote:

>     Why is the top-level window called '.', rather than '.top'?
> There are several {*filter*} things about having . as the toplevel
> window:
>     - It is not obvious whether an arbitrary widget .fred is
>       a toplevel or a child of .

Requiring the first window to be called '.top' wouldn't solve
this problem.  You *still* wouldn't be able to tell from the
name whether a window is a toplevel or not.  To do this reliably,
you need to do:

  if {[winfo toplevel $windowname] == $windowname} {
    puts "I'm a toplevel"
  } else {
    puts "I'm not a toplevel."
  }

Quote:
>     - Given an arbitrary frame/toplevel $x, you cannot say both
>           frame $x.newframe
>           $x cget -background
>       because this code breaks when passed '.'
>       You need to resort to horrible hacks such as
>         if {(![string compare $top "."])||(![string length $top])} {
>             set root ""
>             set top "."
>    }

It does require an extra if statement at the top of your program,
but I've done this many times in my code, with the added benefit
that I can decide what window I want to code executed in:

  proc foo {w} {
    if {$w == "."} {
      set base ""
    } else {
      set base $w
    }

    frame $base.newframe
    $base.newframe config -bg blue
       .
       .
       .
  }

Quote:
>     - It is not possible to get the children of ., as
>         winfo children .
>       gives you both the children of . and all toplevels

Hrm...when I type in:
% button .b
.b
% toplevel .t
.t
% toplevel .b.t
.b.t
% pack .b
% winfo children .
.b .t
%

You can see that the toplevel .b.t wasn't returned.  All windows
that are children of '.' are returned.  Being a child window and
being a toplevel are not mutually exclusive.

Quote:
> All these problems would go away if the default toplevel was .top and
> . was the parent of all toplevels?

I don't see how '.top' could fix two of these problems, and the
third can be worked around with just a little work.

Quote:
> I guess it is far too late to change something like this, but it
> does seem like a pretty ugly design.

Yes, it's far too late.

--



Sun, 13 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?

:     Why is the top-level window called '.', rather than '.top'?
[snip]
: All these problems would go away if the default toplevel was .top and
: . was the parent of all toplevels?

Just do it yourself at the beginning of your script:
        wm withdraw .
        toplevel .top
and then never use . anymore!
and later:
        toplevel .another




Mon, 14 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?
Quote:

> Requiring the first window to be called '.top' wouldn't solve
> this problem.  You *still* wouldn't be able to tell from the

                             ^^^^^^^^^^^^^^^^        
Quote:
> name whether a window is a toplevel or not.  To do this reliably,

                                                          ^^^^^^^^

Quote:
> you need to do:

>   if {[winfo toplevel $windowname] == $windowname} {
>     puts "I'm a toplevel"
>   } else {
>     puts "I'm not a toplevel."
>   }

Hmmm... How about :

  windowname cget -class

?

It should return "Toplevel".
The class of . is "Wish", because . is not a real toplevel.

Just try :

  toplevel .t1
  toplevel .t2

  bind Toplevel <ButtonPress-1> {puts "button pressed !"}

Then click in ., .t1 and .t2.

. is (supposed to be) the main window of your application. Thus,
when it is destroyed, the app is supposed to quit. This is not the
case for toplevels (from a look&feel point of view). IMHO this is
the reason why .'s class is (and must be) Wish and not Toplevel.

Regards,
--
Frederic BONNET



Mon, 14 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?
|>
|> Hmmm... How about :
|>
|>   windowname cget -class
|>
|> ?
|>
|> It should return "Toplevel".

    No  it  shouldn't!   It should return the class of the window.  Just
because it is a toplevel does *not* mean that its class is Toplevel (and
neither  is  the  reverse true - see what happens after "frame .x -class
Toplevel").

   I  put  all  of  my  toplevel  windows into specific classes, as that
allows me to use the options database to control  their  appearance  and
also use the class of a widgets toplevel to control its actions.

--

The contents of this message *may* reflect my personal opinion.  They are
*not* intended to reflect those of my employer, or anyone else.



Tue, 15 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?

Quote:

>Hmmm... How about :

>  windowname cget -class

>?

>It should return "Toplevel".
>The class of . is "Wish", because . is not a real toplevel.

Except that "toplevel -class TopOfThe .top" doesn't have "TopLevel" as its
class name.  "." is a toplevel window whose class name is implicitly set from
the application name (hence all the problems of calling executables things like
"menu" or "button" that have been mentioned recently).

Quote:
>. is (supposed to be) the main window of your application. Thus,
>when it is destroyed, the app is supposed to quit. This is not the
>case for toplevels (from a look&feel point of view). IMHO this is
>the reason why .'s class is (and must be) Wish and not Toplevel.

Actually, there is no good reason why wish shouldn't exit when (a) there
are no windows and (b) when there is nothing left to evaluate.  Actually,
(a) should be when there are no more events to process and no more sources
of events (like the event driven Tcl would be).

Well, OK, there is good reason, historical accident, and I'm sure JO has
mentioned this before ...

--
John Haxby
These are my opinions, not my employer's.



Tue, 15 Sep 1998 03:00:00 GMT  
 Why is top dot not top? Design flaw?
Quote:

> >     Why is the top-level window called '.', rather than '.top'?
> > There are several {*filter*} things about having . as the toplevel
> > window:
> >     - It is not obvious whether an arbitrary widget .fred is
> >       a toplevel or a child of .
> >     - It is not possible to get the children of ., as
> >         winfo children .
> >       gives you both the children of . and all toplevels

                                               ^^^^^^^^^^^^^

don't limit your thinking to "Toplevels have to be at the
top of the hierarchy".

myself, i don't want toplevels so restricted.
if i want a dialogue A and a subdialogue B,
and B's existence only makes sense with A's, it is convenient
to have B as a descendant of A.  then B is destroyed along with
A.  further, if there could be several instances of dialogue A,
it is easier to keep separate the possible instances of B:
i can have two pairs of dialogues
        .A1   and  .A1.B
        .A2   and  .A2.B
and i don't have to try to remember, say in an array, which
B goes with which A.
--



Fri, 18 Sep 1998 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Desk top vs lap top

2. lap top vs desk top

3. Keeping top level on top.

4. Eiffel flaw? was: Why not Eiffel

5. Top UK ASIC design jobs

6. top colleges in VLSI Design education

7. Qualis Top-Down Design With Verilog Course: July 17-21

8. LAST CALL -- Upcoming Verilog and Top-Down Design Course, Beaverton, OR

9. top-down design

10. top colleges in VLSI Design education

11. Problem with top level design

12. Simulation flow for top-down design with VHDL

 

 
Powered by phpBB® Forum Software