tktable-tile-dev Mailing List for TkTable / Tile / Vu (Page 32)

Quoting tkt...@li...:
> Of course you don't need the namespace force in their,
> but I think what we really need is an interim step that
> does the opposite for all Tk widgets, like:
> 
> namespace move $tkWidgetCommands tk::*
..
> I think this separation from old Tk_ tk::* is
> actually a good thing, rather than thinking these should
> become the tk::* in the future.  We are talking about 1
> char, and I don't really think that I'm ready to screw over
> every existing Tk app in Tk 9 by making our life hard over
> a single extra t or not.

I think I can be flexible regarding any interim steps
that turn out to be necessary for a smooth migration,
even if that means gobbling up another toplevel namespace.

I hope, though, that we can keep our "eyes on the prize,"
so the finished result holds together coherently, without
too much historical inconsistency visible to the user.

I think the end product should be a package "Tk" that
provides many public commands, all exported from the
namespace "::tk".

I don't want users to forever have to know that it's
[namespace import ::tk::button], but it's 
[namespace import ::ttk::notebook], all because of
the development history of Tk.  Let all commands
that come to be part of Tk also come to 
be [namespace import]-able from ::tk .

Note that there's no issue with "breaking every existing
Tk app in Tk 9" either, because currently *no* Tk
commands are exported from ::tk ; they're all created
in :: (for the sake of not breaking those Tk apps
written for Tk 4 (!) ).  

DGP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, this helps a lot. Thank you!

Joe English wrote:

| Hello,
|
|
|>I'm trying to build a project on Tk/Aqua using the tile toolkit. I'm
|>having some trouble with the notebook widget, and am unsure how to
proceed.
|> [...]
|
|
| I just posted a followup to a similar question on comp.lang.tcl;
| reply below.  Does this help?
|
| [ ... copied from <UR: news:cha...@ne... > ]
|
|
| Kevin Walzer wrote:
|
|>I'm trying to create a GUI using the Tile theming system and I'm having
|>problems with the notebook widget. Here's my code:
|>[... see below ...]
|>I want the two tframe widgets (.notebookholder.nb.stuff and
|>.notebookholder.nb.f1) to be the tabs, and the two tlabel widgets
|>(.notebookholder.nb.label1 and .notebookholder.nb.label2) to be the
|>child widgets, i.e. the windows that are displayed beneath the tabs.
|
|
| The notebook doesn't work that way -- the tabs are part
| of the notebook widget itself, they aren't subwidgets.
|
|
|>But this code only gets me the tabs with no windows underneath.
|
|
| The notebook actually is displaying the subwidgets you've
| added in the pane area, but since you haven't packed anything
| into the frames or given the labels anything to display,
| the pane looks empty.  Try:
|
|     .notebookholder.nb.label1 configure -text "Hello!"
|
| to see.
|
| --Joe English
|
| [ original code: ]
|
|
|>#make notebook
|>tframe .notebookholder
|>pack .notebookholder -side top -fill x
|>
|>tnotebook .notebookholder.nb -padding 6
|>.notebookholder.nb add [tframe .notebookholder.nb.stuff] -text "The real
|>deal"
|>.notebookholder.nb add [tlabel .notbookholder.nb.label1] -text "Not much
|>going on here..."
|>
|>.notebookholder.nb add [tframe .notebookholder.nb.f1] -text "First tab"
|>- -underline 4
|>.notebookholder.nb add [tlabel .notebookholder.nb.label2] -text
|>"TkDarwinPorts rules!"
|>
|>pack .notebookholder.nb -side bottom -fill y
|
|
|
|
|
|


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBOJZdF6m9qPmThLQRApMhAJ46eS/5PjwTVjmmbp+K4ROjA6ZmqgCZAUOx
AABo6dbHtpy+DHwIFmcANKg=
=OLoi
-----END PGP SIGNATURE-----

Jeff Hobbs wrote:

> As I work with tile, I realize that the need for both Tk
> and tile widgets existing in an interface is a necessity,
> at least for 8.5 (until the individual management of tile
> based widgets becomes better and more established).
>
> So that leads me to the problem of the standard way in
> which tile is added as an augmentation:
>
> package require tile
> namespace import -force tile::*
>
> Of course you don't need the namespace force in their,

[ It's not necessary inside a namespace, which is the
  recommended approach to use Tile on a per-module basis,
  but -force is needed if you do this in the global scope ]

> but I think what we really need is an interim step that
> does the opposite for all Tk widgets, like:
>
> namespace move $tkWidgetCommands tk::*
>
> There is no such command now, but I think that tile should
> be providing it.

That's a good idea -- how would we implement it?

One approach is to [rename] all the Tk widget commands
into the tk namespace, [namespace export] them, then
[namespace import] them back into ::.  (I don't _think_
this will break anything, but parts of Tk have been known
to do some jiggery-pokery with command internals...)

Another approach is to change this in the core; have Tk
define all the widget commands in the tk::* namespace to
begin with (sort of a followup to TIP #44).  Naturally
it should also [namespace import] them into :: to avoid
breaking every script ever written...  This might be
a better approach.

> Also, I think we should be reconsidering
> the 'tile' name *right now*, and I think that ttk is still
> useful.  The tile code is already full of TTK_* APIs, for
> themed Tk.  I think this separation from old Tk_ tk::* is
> actually a good thing, rather than thinking these should
> become the tk::* in the future.

Sounds reasonable.  Although I think we should still use
the name "tile" for stuff like the package name and maybe
a few other places.  'ttk::*' could be used for the public
script-level API.


--Joe English

  jen...@fl...

Hello,

> I'm trying to build a project on Tk/Aqua using the tile toolkit. I'm
> having some trouble with the notebook widget, and am unsure how to proceed.
>  [...]

I just posted a followup to a similar question on comp.lang.tcl;
reply below.  Does this help?

[ ... copied from <UR: news:cha...@ne... > ]


Kevin Walzer wrote:
>
>I'm trying to create a GUI using the Tile theming system and I'm having
>problems with the notebook widget. Here's my code: 
> [... see below ...]
>I want the two tframe widgets (.notebookholder.nb.stuff and
>.notebookholder.nb.f1) to be the tabs, and the two tlabel widgets
>(.notebookholder.nb.label1 and .notebookholder.nb.label2) to be the
>child widgets, i.e. the windows that are displayed beneath the tabs.

The notebook doesn't work that way -- the tabs are part
of the notebook widget itself, they aren't subwidgets.

> But this code only gets me the tabs with no windows underneath.

The notebook actually is displaying the subwidgets you've
added in the pane area, but since you haven't packed anything
into the frames or given the labels anything to display,
the pane looks empty.  Try:

    .notebookholder.nb.label1 configure -text "Hello!"

to see.

--Joe English

[ original code: ] 

>#make notebook
>tframe .notebookholder
>pack .notebookholder -side top -fill x
>
>tnotebook .notebookholder.nb -padding 6
>.notebookholder.nb add [tframe .notebookholder.nb.stuff] -text "The real
>deal"
>.notebookholder.nb add [tlabel .notbookholder.nb.label1] -text "Not much
>going on here..."
>
>.notebookholder.nb add [tframe .notebookholder.nb.f1] -text "First tab"
>- -underline 4
>.notebookholder.nb add [tlabel .notebookholder.nb.label2] -text
>"TkDarwinPorts rules!"
>
>pack .notebookholder.nb -side bottom -fill y

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I'm trying to build a project on Tk/Aqua using the tile toolkit. I'm
having some trouble with the notebook widget, and am unsure how to proceed.

I have set up the notebook with two tabs, and both tabs display
correctly, but I'm not able to select any pages *under* the tabs. Here's
my code:

#make notebook
tframe .notebookholder
pack .notebookholder -side top -fill x

tnotebook .notebookholder.nb
pack .notebookholder.nb -side top -fill x

.notebookholder.nb add [tlabel .notebookholder.nb.stuff] -text "The real
deal"
.notebookholder.nb add [tlabel .notebookholder.nb.label1] -text "Not
much going on here..."

.notebookholder.nb.stuff add [tlabel
.notebookholder.nb.stuff.stufflabel] -text "Will this work?"

pack .notebookholder.nb.stuff .notebookholder.nb.label1 -side bottom -fill x

When I run the script, here's the error message I get:

Error in startup script: bad command "add": must be configure, cget,
instate, or state
~    while executing
".notebookholder.nb.stuff add [tlabel
.notebookholder.nb.stuff.stufflabel] -text "Will this work?""

It's the fourth-level widget
here--.notebookholder.nb.stuff.stufflabel--that I want to display when I
~  select the .notebookholder.nb.stuff tab. I've read the documentation
at the tile sourceforge site and I thought "add" was the correct command
to use. But, it's not working.

Can anyone tell me what I'm doing wrong?

By the way--I think the Tile project is terrific. The Aqua theme makes
my script look absolutely native; the pinstripe background, especially,
is what's missing from the core Tk widgets, and the notebook and
progress bar widgets are a very nice touch. Thanks for making this
available.



- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBOI1SF6m9qPmThLQRAg3dAJ42+DWsF/Vc8AeabDjHZO8knqw0ngCdFYGc
MyuOKfoo61i9zMXYPWGYwdc=
=vCkd
-----END PGP SIGNATURE-----

As I work with tile, I realize that the need for both Tk
and tile widgets existing in an interface is a necessity,
at least for 8.5 (until the individual management of tile
based widgets becomes better and more established).

So that leads me to the problem of the standard way in
which tile is added as an augmentation:

package require tile
namespace import -force tile::*

Of course you don't need the namespace force in their,
but I think what we really need is an interim step that
does the opposite for all Tk widgets, like:

namespace move $tkWidgetCommands tk::*

There is no such command now, but I think that tile should
be providing it.  Also, I think we should be reconsidering
the 'tile' name *right now*, and I think that ttk is still
useful.  The tile code is already full of TTK_* APIs, for
themed Tk.  I think this separation from old Tk_ tk::* is
actually a good thing, rather than thinking these should
become the tk::* in the future.  We are talking about 1
char, and I don't really think that I'm ready to screw over
every existing Tk app in Tk 9 by making our life hard over
a single extra t or not.

So, comments?

Jeff

Jeff Hobbs wrote:
> [Joe English]:
> > The new formulation may have a small performance boost in
> > the common case where the -command is a pure list, but
> > it's not fully backwards-compatible, since there are
> > valid script prefixes that aren't lists.
>
> No there aren't.

They're tricky to construct and unlikely to appear in the real world,
but they do exist.  Example:

    text .left
    text .right
    set left 1
    set cmd {[expr {$left ? ".left" : ".right"}] yview}

    uplevel #0 [concat $cmd moveto 0.0]
	# ==> works
    llength $cmd
	# ==> error "list element in braces followed by "]" instead of space"


> The real trick is "script prefix" vs "command prefix".  I guess
> for most of Tk it's a script prefix, and that remains that way
> as long as we use uplevel.  It really matters at the C level,
> as there we can force it to be one command, vs a script.  I'm
> inclined to say "script" just because that's Tk-ish, but I'm
> sure I could be convinced otherwise.

I'm leaning that way also; consistency with "what Tk does"
instead of "what (I think) Tk ought to do".


--Joe English

  jen...@fl...

>      set cmd [$w cget -command]
> -    if {$cmd ne ""} {
> -       uplevel #0 "$cmd scroll $n $units"
> -    }
> +    if {[llength $cmd]} {
> +       uplevel #0 [concat $cmd scroll $n $units]
> +    }

> This forces the -command option to be a list ([llength 
> $cmd]), but still treats it as a string ([concat] instead of 
> [linsert _ end ...])

I should have used [linsert $cmd end ...] to be better
behaved, but I figured the above was "safer".

> The new formulation may have a small performance boost in
> the common case where the -command is a pure list, but
> it's not fully backwards-compatible, since there are 
> valid script prefixes that aren't lists.

No there aren't.  You couldn't pass it to eval or uplevel
in that case:

(Tcl) 49 % set cmd "echo \{ c"
echo { c
(Tcl) 50 % llength $cmd
unmatched open brace in list
(Tcl) 51 % eval $cmd
missing close-brace
(Tcl) 52 % uplevel #0 $cmd
missing close-brace

> We had discussed earlier interpreting callback options
> that append arguments as command prefixes instead of script 
> prefixes; is this something we want to do?  (Callback options 
> that don't append arguments would still be interpreted as
> scripts.)  Personally, I think it's a good idea, but there
> are backwards-compatibility issues.

The real trick is "script prefix" vs "command prefix".  I guess
for most of Tk it's a script prefix, and that remains that way
as long as we use uplevel.  It really matters at the C level,
as there we can force it to be one command, vs a script.  I'm
inclined to say "script" just because that's Tk-ish, but I'm
sure I could be convinced otherwise.

Jeff

In the latest change to scrollbar.tcl (r1.12 -> 1.13):

 proc tile::scrollbar::Scroll {w n units} {
     set cmd [$w cget -command]
-    if {$cmd ne ""} {
-       uplevel #0 "$cmd scroll $n $units"
-    }
+    if {[llength $cmd]} {
+       uplevel #0 [concat $cmd scroll $n $units]
+    }
 }

This forces the -command option to be a list ([llength $cmd]),
but still treats it as a string ([concat] instead of [linsert _ end ...])

The new formulation may have a small performance boost in
the common case where the -command is a pure list, but
it's not fully backwards-compatible, since there are 
valid script prefixes that aren't lists.

We had discussed earlier interpreting callback options
that append arguments as command prefixes instead of script
prefixes; is this something we want to do?  (Callback options
that don't append arguments would still be interpreted as
scripts.)  Personally, I think it's a good idea, but there
are backwards-compatibility issues.


--Joe English

  jen...@fl...

Jeff Hobbs wrote:

> So I was playing with trying to just -style one item (or one
> class of items ... no matter).  IOW, one button, entry or
> label that just has its own bg.
>
> I looked at the Toolbutton stuff, which is really trying to
> change the behavior,

[ An aside: the Toolbutton actually *doesn't* change the behavior,
  only the dynamic appearance.  This is pretty cool, IMHO -- the exact
  same set of class bindings works for normal and toolbar-style
  buttons, on all platforms, plus checkbuttons and radiobuttons too.
  For these widgets the look is completely decoupled from the feel.
  But anyway ... ]

> but seems to be the only example.  It is
> overly complex for my situation, but seems to be the only
> solution.  You can't seem to create another style without
> creating a full layout for it.

The theme engine has some fallback rules that might help with this.
For example, you could say:

    style default Blue.TButton -background blue
    tbutton .bluebutton -style Blue.TButton

".bluebutton" will inherit all of the defaults and dynamic
settings from the "TButton" style, with default -background blue
overriding.  This won't work at present since layouts aren't
inherited (they probably should be...), so as you noted you'll
also need to define a layout for "Blue.TButton".

Also note that in some themes, XP and Aqua in particular,
the (elements used in the) TButton style don't even have
a -background option, so this wouldn't have an effect there.
It might be useful to define a CustomButton widget, possibly
with "real" -background, -foreground, -borderwidth, etc., options
to support UIs with lots of one-off button styles.

A related issue: there are a few widgets (basically all of the
ones with an "-orient" option) that don't support custom -styles,
since they pick a layout/style dynamically based on other widget
options.  Not sure what to do about that -- probably the right
solution is to let "-style" override the default as usual,
with the caveat to the user that the layout had better match
the selected orientation.

> At first I thought 'style theme create ... -parent' was what
> I wanted, until it set in that "theme create" really means
> theme create, not style create.  I think that tile will need
> to support inherited styles where you just change a few
> elements, or it will be hard to introduce to a number of
> applications that styled one or two widgets slightly
> different from the standard options to get just the right
> effect for their app.


I think the current fallback scheme is basically on the right track,
but it's not well-documented, not completely thought-out, and not
very consistent right now.  Element names, layouts, defaults, and
dynamic settings all have their own fallback chaining rules,
which can follow the name hierarchy ("a.b.c" -> "b.c" -> "c"),
the theme -parent hierarchy (xpnative -> winnative -> alt -> default),
or both.  Pat and I have changed the fallback rules three or four
times already and they're still Not Quite Right.  This use case
in particular isn't supported very well.


--Joe English