tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] ANN: VuMan, a Man Page Viewer for OS X: written with TclTkAqua and Tile

[Steve L. <st...@Di...>]

On 30/01/2005, at 3:28 PM, Kevin Walzer wrote:

> I'm pleased to announce the release of v. 0.1 of VuMan, a Mac OS X
> graphical user interface to the main system of Unix software
> documentation, the man page.

Cool - nice work!

> As always, feedback, comments and suggestions are welcome

I might have missed something obvious, but is there a way of specifying 
the section of the manual that a command comes from.

For example, to get the Tcl string command I'd use

$ man n string

Regards

Steve

[Tile-dev] ANN: VuMan, a Man Page Viewer for OS X: written with TclTkAqua and Tile

[Kevin W. <sw...@wo...>]

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

I'm pleased to announce the release of v. 0.1 of VuMan, a Mac OS X
graphical user interface to the main system of Unix software
documentation, the man page. VuMan provides a friendlier interface to
the Unix man page system than typing in "man foo" into the terminal. It
links together a number of Unix command-line tools to make searching,
reading, and printing man page documentation a simple task.

Apart from being a useful little tool, this application is notable for a
couple of reasons:

1. It is, to my knowledge, the first widely-released and announced
application using the Tk Tile extension.

2. It is, to my knowledge, one of the first Tcl/Tk applications
developed on, and for, the Mac OS X platform, with the specific goal of
being a fully native, Aqua-compliant Mac application (as opposed to a
port from another platform).

VuMan is open source, available under the Tcl license.


VuMan can be downloaded at this site:
http://www.wordtech-software.com/vuman.html

You can find out more about the development techniques and design of
VuMan here:

http://www.kevin-walzer.com/pivot/entry.php?id=18

VuMan is an offshoot of the work I'm doing on a much more complicated
project, my DarwinPorts GUI. It gave me a chance to take a portion of
the code from that project and test some design and coding approaches to
optimize the interface for OS X. I'll be folding what I've learned from
this project back into the DarwinPorts GUI application.

As always, feedback, comments and suggestions are welcome.

Cheers,

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

iD8DBQFB/IypJmdQs+6YVcoRAiPXAJ4ifjmmnafUbCXpANBlc+VpnYWV3wCeO8lY
pFAjpMRpdwn2rOSXws273lg=
=v6HX
-----END PGP SIGNATURE-----

RE: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Donald G P. <dg...@ni...>]

> I don't like it because you are forcing an error situation
> every time that pkgIndex.tcl is hit. 

Agreed.  Here's the improved index script:

if {![package vsatisfies [package provide Tcl] 8.5]} {return}
if {[package provide Tk] eq ""} {return}
if {![package vsatisfies [package provide Tk] 8.5]} {return}
if {[tk windowingsystem] ne "x11"} {return}
package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]


I'd like it better if [package present] had a more sensible
interface.  But it doesn't.  A [package vsatisfies] that
didn't error on a "" argument might help out as well.

| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Steve L. <st...@Di...>]

On 25/01/2005, at 8:32 AM, Jeff Hobbs wrote:

>> You also shouldn't use floating point number comparison on a
>> string that isn't really a floating point number.
>>
>>     if {![string equal [info tclversion] "8.4"]} ...
>
> Agreed ... but better change that to 'string compare' to work
> with Tcl <=8.1.  ;)

Cool - I'll take that as a commitment that you'll backport Tile to <= 
8.1 :)

Steve

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Joe E. <jen...@fl...>]

Steve Landers wrote:
> Donald G Porter wrote:
> > My preference would be an index script that looks like this:
> >
> > if {![package vsatisfies [package provide Tcl] 8.5]} {return}
> > if {[catch {package present Tk 8.5}] != 0} {return}
> > if {[tk windowingsystem] ne "x11"} {return}
> > package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]
>
> Is that going to address the issue - how to selectively load the shared
> library depending on the windowing system when Tk hasn't necessarily
> been "package required" when the Tile pkgIndex.tcl runs?

If you install two copies of Tile, one built against Tk/X11
and with a pkgIndex.tcl that looks like the above, and the other
built against Tk/Aqua and with a similar pkgIndex.tcl except
that it bails out early if [tk windowingsystem] ne "aqua" instead,
that should have the desired effect, subject to the constraint that
applications must [package require Tk] before [package require tile].


But here's how I would do it:

    # pkgIndex.tcl
    #
    package ifneeded tile 0.5 [subst {
	package require Tk 8.4
	if {\[tk windowingsystem\] eq "aqua"} {
	    load "[file join $dir tile-aqua.dylib]"
	} else {
	    load "[file join $dir tile-x11.dylib]"
	}
    }]


Alternately -- and this is how I would do things if
it were my machine -- arrange things so that Tk/X11
and Tk/Aqua have different search paths, and install
the appropriate version of tile in the appropriate
place.


--Joe English

  jen...@fl...

RE: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Jeff H. <je...@Ac...>]

> You also shouldn't use floating point number comparison on a 
> string that isn't really a floating point number.
> 
>     if {![string equal [info tclversion] "8.4"]} ...

Agreed ... but better change that to 'string compare' to work
with Tcl <=8.1.  ;)

Jeff

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:

> I don't like it because you are forcing an error situation
>
>every time that pkgIndex.tcl is hit.  catch'es with errors
>are actually expensive.  I think it should avoid those
>situations, instead being a bit more refined to not error
>as much (same general code-path, just slightly different).
>I'm not sure exactly what was intended from the original
>design, but something more like:
>
>if {[info tclversion] != 8.4} { return }
>if {[package provide Tk] eq ""} { return }
> ....
>
>Note that you can't use 'eq' in an expr before checking 8.4+
>compatability.
>  
>

You also shouldn't use floating point number comparison on a string that 
isn't really a floating point number.

    if {![string equal [info tclversion] "8.4"]} ...

-Brian

-- 
-------------------------------------------------------------
--                 Model Technology Inc.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-- AIM ........................................ bgriffin42 --
-------------------------------------------------------------

RE: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Jeff H. <je...@Ac...>]

> > If package Tk is not present at the time of [package require Tile 
> > 0.5], then the Tile package will not be found.  The index script(s) 
> > above require the application to do:
> >
> >     package require Tk 8.5
> >     package require Tile 0.5
> >
> > in order.  Since I cannot imagine any application that will use Tile 
> > commands that would not also use Tk commands, I don't think this 
> > limitation imposes any burden.
> 
> OK, that answers my question. You are assuming that Tk is present.
> 
> No problems - I agree that it isn't an undue burden. But it is a change 
> from the current situation.
> 
> What do others think?

I don't like it because you are forcing an error situation
every time that pkgIndex.tcl is hit.  catch'es with errors
are actually expensive.  I think it should avoid those
situations, instead being a bit more refined to not error
as much (same general code-path, just slightly different).
I'm not sure exactly what was intended from the original
design, but something more like:

if {[info tclversion] != 8.4} { return }
if {[package provide Tk] eq ""} { return }
 ....

Note that you can't use 'eq' in an expr before checking 8.4+
compatability.

Jeff

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Steve L. <st...@Di...>]

On 25/01/2005, at 2:07 AM, Donald G Porter wrote:

>
>>> if {![package vsatisfies [package provide Tcl] 8.5]} {return}
>>> if {[catch {package present Tk 8.5}] != 0} {return}
>>> if {[tk windowingsystem] ne "x11"} {return}
>>> package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]
>>
>> Is that going to address the issue - how to selectively load the 
>> shared
>> library depending on the windowing system when Tk hasn't necessarily
>> been "package required" when the Tile pkgIndex.tcl runs?

....

> This scheme allows either one or both variants of the package to
> be installed independently.  If both are installed, [tclPkgUnknown]
> will run both index scripts and the proper [package ifneeded] command
> will be evaluated.
>
> If package Tk is not present at the time of [package require Tile 0.5],
> then the Tile package will not be found.  The index script(s) above
> require the application to do:
>
>     package require Tk 8.5
>     package require Tile 0.5
>
> in order.  Since I cannot imagine any application that will use
> Tile commands that would not also use Tk commands, I don't think
> this limitation imposes any burden.

OK, that answers my question. You are assuming that Tk is present.

No problems - I agree that it isn't an undue burden. But it is a change 
from the current situation.

What do others think?

Steve

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Donald G P. <dg...@ni...>]

> > if {![package vsatisfies [package provide Tcl] 8.5]} {return}
> > if {[catch {package present Tk 8.5}] != 0} {return}
> > if {[tk windowingsystem] ne "x11"} {return}
> > package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]
> 
> Is that going to address the issue - how to selectively load the shared 
> library depending on the windowing system when Tk hasn't necessarily 
> been "package required" when the Tile pkgIndex.tcl runs?

The index script above is for the Tile 0.5 shared library that is
configured to work with X11.

There could be another Tile 0.5 shared library configured to work
with Aqua.  It would have its own index script, nearly the same
as above, but with "aqua" appearing where "x11" appears above.

This scheme allows either one or both variants of the package to
be installed independently.  If both are installed, [tclPkgUnknown]
will run both index scripts and the proper [package ifneeded] command
will be evaluated.

If package Tk is not present at the time of [package require Tile 0.5],
then the Tile package will not be found.  The index script(s) above
require the application to do:

    package require Tk 8.5
    package require Tile 0.5
    
in order.  Since I cannot imagine any application that will use
Tile commands that would not also use Tk commands, I don't think
this limitation imposes any burden.

| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Steve L. <st...@Di...>]

On 22/01/2005, at 2:06 AM, Donald G Porter wrote:

>> Not sure of the best way forward - perhaps just "package require Tk" 
>> on
>> OSX before invoking [tk windowingsystem] ?
>
> My preference would be an index script that looks like this:
>
> if {![package vsatisfies [package provide Tcl] 8.5]} {return}
> if {[catch {package present Tk 8.5}] != 0} {return}
> if {[tk windowingsystem] ne "x11"} {return}
> package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]

Is that going to address the issue - how to selectively load the shared 
library depending on the windowing system when Tk hasn't necessarily 
been "package required" when the Tile pkgIndex.tcl runs?

Or am I missing something?

Steve

[Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Donald G P. <dg...@ni...>]

> Not sure of the best way forward - perhaps just "package require Tk" on 
> OSX before invoking [tk windowingsystem] ?

My preference would be an index script that looks like this:

if {![package vsatisfies [package provide Tcl] 8.5]} {return}
if {[catch {package present Tk 8.5}] != 0} {return}
if {[tk windowingsystem] ne "x11"} {return}
package ifneeded Tile 0.5 [list load [file join $dir libtile.so]]

| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[Tile-dev] Re: tile 0.5 binary for MacOSX X11

[Steve L. <st...@Di...>]

I wrote ...

On 19/01/2005, at 4:41 PM, Steve Landers wrote:

> - updated lib/tile0.5/pkgIndex.tcl to add [tk windowingsystem] to the 
> directory on OSX

and I didn't do it correctly, because Tk isn't loaded at that point in 
time :(

Not sure of the best way forward - perhaps just "package require Tk" on 
OSX before invoking [tk windowingsystem] ?

Steve

--
Steve Landers                     Software Design Solutions
Digital Smarties                  st...@Di...
Perth, Western Australia          DigitalSmarties.com

[Tile-dev] tile 0.5 binary for MacOSX X11

[Steve L. <st...@Di...>]

Folks,

I've built tile 0.5 for OSX X11 (the existing tile05.kit contained the 
Aqua library only).

To accommodate this I've done the following ...
- moved the lib/tile0.5/Darwin-ppc directory to  
lib/tile0.5/Darwin-ppc-aqua
- created a new lib/tile0.5/Darwin-ppc-x11 directory to hold the X11 
binary
- updated lib/tile0.5/pkgIndex.tcl to add [tk windowingsystem] to the 
directory on OSX

I've updated a copy of the tile05.kit Starkit and uploaded it to 
http://www.digitalsmarties.com/pub/tile05.kit - feel free to 
incorporate or ignore as you see appropriate :)

Cheers

Steve

Re: [Tile-dev] Screenshot of real app using Tile

[Michael K. <mi...@mu...>]

Looks pretty nice.  I think the colors might be slightly off on the 
alternating list lines, but I can't be sure at the moment. :)

I started converting MIB Smithy to use Tile yesterday.  Here's how it 
looks so far:

http://www.muonics.com/extimgs/smithy-tile.tiff

Got a ways to go yet, but it's coming along..

On Tue, 4 Jan 2005, Kevin Walzer wrote:

> Date: Tue, 04 Jan 2005 16:12:00 -0500
> From: Kevin Walzer <sw...@wo...>
> To: tkt...@li...
> Subject: [Tile-dev] Screenshot of real app using Tile
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone,
>
> Since I haven't seen much discussion/documentation of actual programs
> that are currently using Tile, I thought I'd post a screenshot of the
> application I'm developing (for Mac OS X).
>
> http://www.wordtech-software.com/tkdarwinports-0.2-screenshot.html
>
> This makes use of a mix of Tile and regular Tk widgets (since the
> scrollbar looks native under TkAqua, but the Tile scrollbar doesn't).
> It's easy to mix the two using regular names and the ttk:: namespace.
> I'm using Tile 0.6, which was packaged from CVS by Daniel Steffen as
> part of his TkAqua BI distro.
>
> This app, TkDarwinPorts, is a GUI for the DarwinPorts package management
> system, which is written in Tcl. The original design of the program was
> strictly as a command-line wrapper, but I'm rewriting the code to hook
> directly into DarwinPorts' API, which should make this app portable
> across all platforms that DarwinPorts runs on.
>
> I think this is good evidence of how cool Tile is. TkDarwinPorts makes
> use of some other nice extensions, such as tablelist, but Tile gives
> this real Aqua-compliant look-and-feel.
>
> - --
> Cheers,
>
> 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
>
> iD8DBQFB2wagJmdQs+6YVcoRAi5kAJ0YX2CyO/eE7xePu9IXDpzuJ8z3bACfRikn
> 5Bj/dYtUleFfhGeI2xhKeJM=
> =E/sA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Screenshot of real app using Tile

[Kevin W. <sw...@wo...>]

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

Looks terrific!

Michael Kirkham wrote:
|
| Looks pretty nice.  I think the colors might be slightly off on the
| alternating list lines, but I can't be sure at the moment. :)
|
| I started converting MIB Smithy to use Tile yesterday.  Here's how it
| looks so far:
|
| http://www.muonics.com/extimgs/smithy-tile.tiff
|
| Got a ways to go yet, but it's coming along..
|
| On Tue, 4 Jan 2005, Kevin Walzer wrote:
|
|> Date: Tue, 04 Jan 2005 16:12:00 -0500
|> From: Kevin Walzer <sw...@wo...>
|> To: tkt...@li...
|> Subject: [Tile-dev] Screenshot of real app using Tile
|>
| Hi everyone,
|
| Since I haven't seen much discussion/documentation of actual programs
| that are currently using Tile, I thought I'd post a screenshot of the
| application I'm developing (for Mac OS X).
|
| http://www.wordtech-software.com/tkdarwinports-0.2-screenshot.html
|
| This makes use of a mix of Tile and regular Tk widgets (since the
| scrollbar looks native under TkAqua, but the Tile scrollbar doesn't).
| It's easy to mix the two using regular names and the ttk:: namespace.
| I'm using Tile 0.6, which was packaged from CVS by Daniel Steffen as
| part of his TkAqua BI distro.
|
| This app, TkDarwinPorts, is a GUI for the DarwinPorts package management
| system, which is written in Tcl. The original design of the program was
| strictly as a command-line wrapper, but I'm rewriting the code to hook
| directly into DarwinPorts' API, which should make this app portable
| across all platforms that DarwinPorts runs on.
|
| I think this is good evidence of how cool Tile is. TkDarwinPorts makes
| use of some other nice extensions, such as tablelist, but Tile gives
| this real Aqua-compliant look-and-feel.
|
|>
|>
- -------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Tktable-tile-dev mailing list
Tkt...@li...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|>

| --
| Michael Kirkham
| www.muonics.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB4WyJJmdQs+6YVcoRAlbHAJ9/pqmVaSW0v2D7FoA5pqx6CU1UrQCfWe0K
cjL5vhvdLnZZW6D6ZLxiAnY=
=BlbL
-----END PGP SIGNATURE-----

[Tile-dev] Screenshot of real app using Tile

[Kevin W. <sw...@wo...>]

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

Hi everyone,

Since I haven't seen much discussion/documentation of actual programs
that are currently using Tile, I thought I'd post a screenshot of the
application I'm developing (for Mac OS X).

http://www.wordtech-software.com/tkdarwinports-0.2-screenshot.html

This makes use of a mix of Tile and regular Tk widgets (since the
scrollbar looks native under TkAqua, but the Tile scrollbar doesn't).
It's easy to mix the two using regular names and the ttk:: namespace.
I'm using Tile 0.6, which was packaged from CVS by Daniel Steffen as
part of his TkAqua BI distro.

This app, TkDarwinPorts, is a GUI for the DarwinPorts package management
system, which is written in Tcl. The original design of the program was
strictly as a command-line wrapper, but I'm rewriting the code to hook
directly into DarwinPorts' API, which should make this app portable
across all platforms that DarwinPorts runs on.

I think this is good evidence of how cool Tile is. TkDarwinPorts makes
use of some other nice extensions, such as tablelist, but Tile gives
this real Aqua-compliant look-and-feel.

- --
Cheers,

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

iD8DBQFB2wagJmdQs+6YVcoRAi5kAJ0YX2CyO/eE7xePu9IXDpzuJ8z3bACfRikn
5Bj/dYtUleFfhGeI2xhKeJM=
=E/sA
-----END PGP SIGNATURE-----

Re: [Tile-dev] -width option for tile label widgets

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:
> [JE]:
> > With this usage, it's preferable that the "-width" option
> > always mean the same thing, instead of sometimes being in
> > pixels and sometimes being in characters depending on the
> > values of other options.
>
> While I would agree with this, the core evidently decided that
> the same consistency should be held ... for images.  In any
> case, how do you handle the addition of an image to the mix?
> Does that calculate into the whole, added separately, ???

The requested width and height of the image part of the label
is taken from the width and height of the image.

Longer answer: the "label" element is a combination of the
"text" and "image" elements, with additional options "-compound",
"-anchor", and "-space" that specify how the two parts
should be arranged.

For "-compound top" and "-compound bottom", the requested
height is the height of the image, plus "-space", plus the
height of the text element, and the requested width is the
maximum of the widths of the two subelements.  Similarly for
"-compound left" and "-compound right", except width and
height are swapped.  For "-compound text" and "-compound image",
only the appropriate subelement is used.

If -width >= 0, the requested width of the text element
is -width characters.  Otherwise, it's the the larger of
the width of the string and the absolute value of -width
(i.e., negative -widths specify a minimum size for the
text element).



--Joe English

  jen...@fl...

RE: [Tile-dev] -width option for tile label widgets

[Jeff H. <je...@Ac...>]

> Part of the rationale for why Tile labels and buttons work 
> differently in this regard is to support customizable 
> toolbars, where the user can select "Pictures and text", 
> "pictures only", or "text only", as found in most web 
> browsers.  To support this use case, Tile added  "-compound 
> text" and "-compound image"; this makes it easier to switch 
> back and forth (with Tk buttons, to get the effect of 
> "-compound text" you need to set "-image {}"; and you have to 
> remember what the original image was in order to change it back).
> 
> With this usage, it's preferable that the "-width" option 
> always mean the same thing, instead of sometimes being in 
> pixels and sometimes being in characters depending on the 
> values of other options.

While I would agree with this, the core evidently decided that
the same consistency should be held ... for images.  In any
case, how do you handle the addition of an image to the mix?
Does that calculate into the whole, added separately, ???

Jeff

Re: [Tile-dev] -width option for tile label widgets

[Larry M. <lm...@bi...>]

On Mon, Dec 27, 2004 at 01:36:36PM -0800, Joe English wrote:
> 
> Jeff Hobbs wrote:
> 
> > The core actually interprets -width in pixels if any image is
> > associated with the widget.  I'm not sure this is the right
> > thing to do for compound widgets, but that's what it does.
> 
> I'm pretty sure that's not the right thing at all.
> 
> Part of the rationale for why Tile labels and buttons work
> differently in this regard is to support customizable toolbars,
> where the user can select "Pictures and text", "pictures only",
> or "text only", as found in most web browsers.  

Do you mean like this: http://www.bitkeeper.com/newdifftool.gif ?
So you can have a toolbar and a menubar on the same "line"?  We'd
love that.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] -width option for tile label widgets

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> The core actually interprets -width in pixels if any image is
> associated with the widget.  I'm not sure this is the right
> thing to do for compound widgets, but that's what it does.

I'm pretty sure that's not the right thing at all.

Part of the rationale for why Tile labels and buttons work
differently in this regard is to support customizable toolbars,
where the user can select "Pictures and text", "pictures only",
or "text only", as found in most web browsers.  To support
this use case, Tile added  "-compound text" and "-compound image";
this makes it easier to switch back and forth (with Tk buttons,
to get the effect of "-compound text" you need to set "-image {}";
and you have to remember what the original image was in order
to change it back).

With this usage, it's preferable that the "-width" option always
mean the same thing, instead of sometimes being in pixels and
sometimes being in characters depending on the values of other
options.


--Joe English

  jen...@fl...

RE: [Tile-dev] -width option for tile label widgets

[Jeff H. <je...@Ac...>]

> > The -width option for tile labels is always in characters, even if the 
> > widget contains an image (in this case, the value of the 

> It should only be ignored if the text label is not displayed 
> at all, i.e., if '-compound image' or '-compound none -image 
> $someImage' is specified.

The core actually interprets -width in pixels if any image is
associated with the widget.  I'm not sure this is the right
thing to do for compound widgets, but that's what it does.

> ... at least that's what's supposed to happen; looks like
> it isn't implemented correctly.  But the intended behavior
> is that '-width' always specifies the width in characters
> of the text part of the label, regardless of the value of 
> '-compound' and '-image'.

That sounds more reasonable ... but isn't what Tk label does.
Test:

package require Tk
image create photo logo -file $tk_library/images/logo64.gif
pack [label .l -image logo -text "1234567" -font Courier -bg pink]
.l configure -compound left
.l configure -width 5
.l configure -width 50

Jeff

Re: [Tile-dev] -width option for tile label widgets

[Joe E. <jen...@fl...>]

Csaba Nemethi wrote:

> The -width option for tile labels is always in characters, even if the
> widget contains an image (in this case, the value of the -width option
> is silently ignored).

It should only be ignored if the text label is not displayed at all,
i.e., if '-compound image' or '-compound none -image $someImage'
is specified.

... at least that's what's supposed to happen; looks like
it isn't implemented correctly.  But the intended behavior
is that '-width' always specifies the width in characters
of the text part of the label, regardless of the value of
'-compound' and '-image'.

> Another question:  Why do tile label widgets have no -height option?

Historical accident, mostly.  An early assumption was that label
widgets would only support single-line text, and that message widgets
would be used for multi-line text.


--Joe English

  jen...@fl...

[Tile-dev] -width option for tile label widgets

[<Csa...@t-...>]

The -width option for tile labels is always in characters, even if the
widget contains an image (in this case, the value of the -width option
is silently ignored).  In the case of the core label widgets containing
an image the width is interpreted in pixels and is not ignored.  This
makes it possible to hide part of an image by just embedding it in a
label and setting the latter's width to an appropriate value.  Moreover,
by using the -anchor option, one can also specify which part of the
image should get hidden.  Unfortunately, all this is not possible with
tile labels.

Can anybody tell me the reason for this change?  There are cases where
the "trick" described above is of vital importance.  I know, there are
various workarounds, but they all consume far more resources than the
simple solution using a core label widget.

I would like to suggest that the width of tile label widgets containg
an image is interpreted in pixels, just like that of the Tk labels with
images.

Another question:  Why do tile label widgets have no -height option?

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

Re: [Tile-dev] Stubs table

[Joe E. <jen...@fl...>]

More departures from convention:

The stub initialization routine is

    const char *Ttk_InitStubs(Tcl_Interp *);

which is actually a macro that expands to

    TtkInitializeStubs(interp, TILE_VERSION, TTK_EPOCH, TTK_REVISION);

Note that the package version is hardcoded in the macro.
This way the caller doesn't have the opportunity to make
a mistake like

	Ttk_InitStubs(interp, "0.6");

which is likely to do the wrong thing if you compile against
a later version of the header files.

The name of the stub library shall not include a version number.
That is, on Unix and Unix-like systems it's called libttkstub.a,
and on Windows it's TTKSTUB.LIB.  This way dependant packages
can just specify -lttkstub; there's no need to grub around
for a *Config.sh file to decide whether to use -lttkstub06,
-lttkstub0.6, -lttkstub06g, or -lttkstub0.6.g.  Since the
stub library is not expected to change from release to release,
there's no reason for it to be versioned.  (And including ${DBGX}
in the library name is just perverse.)

Since the stub library name is fixed, there will not be a *Config.sh 
file.  There *might* be a *.pc file, for use with pkg-config, but 
no *Config.sh.


--Joe English

  jen...@fl...