tktable-tile-dev — Discussion about tile development

RE: [Tile-dev] Re: entry widget validation with textvariable "not right"

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

> > New patch 1302146 posted to SourceForge:
> > This changes how the [ttk::entry] widget uses the 'invalid' state bit 
> > as follows: [...]
> > Please try it out and let me know.
> 
> OK, so no feedback yet.  I'm going to go ahead and commit the 
> patch; it might not be right, but it's at least closer.

The patch changes appeared to satisfy one of the key problems,
but I didn't get a chance to apply the patch and test.  I will
certainly test after you apply.

> On a related note: what should [$e validate] return?

Whatever the result of the -validatecommand was, 1 if none?

> The core manpage entry(n) just says:
> 
> | pathName validate
> | 	This command is used to force an evaluation of the validateCommand
> | 	independent of the conditions specified by the validate
> | 	option. This is done by temporarily setting the validate option
> | 	to all. It returns 0 or 1.
> |               ^^^^^^^^^^^^^^^^^
> 
> Based on the manpage, the [ttk::entry] validate method is 
> compatible -- it does, in fact, always return 0 or 1 -- but 
> the conditions under which it does so might be different -- 
> see #1236979.

Hmmm, the extra cases for returning 0 seem odd, but
otherwise it looks OK.

> (Which brings up another minor incompatibility: -- The core 
> entry widget performs validation "by temporarily setting the 
> -validate option to 'all'". The ttk::entry widget performs 
> validation by performing validation. I don't think this is 
> too serious a problem ....)

I think that is not an issue.

Thanks,

Jeff

[Tile-dev] Universal binary of Tile: some progress

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

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

I've done a bit more investigating on building Tile as a universal
binary on OS X. It seems like an issue with TkAqua rather than Tile,
because I'm seeing the same issues trying to build another extension
(tktreectrl) as a universal binary.

Earlier, the build was dying after complaining that some defintions in
tkMacOSXInt.h had errors. Looking at the code in question, I noticed
that the lines began with the phrase "Module Scope," like this:

~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
enable);

Commenting out those lines and replacing them without the phrase "module
scope" allowed the build to proceed, and I built Tile and Tktreectrl
successfully in the standard fashion (not as universal binaries).

I'm not sure why commenting out the "module scope" bits worked; I'm sure
that is there for a reason, but it's not clear to me.

Trying again as a universal binary (building against the 10.4 sdk, -arch
i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way
through the builds before dying with this error message:

ld: Undefined symbols:
_tclStubsPtr
_Tcl_InitStubs
_Tk_InitStubs
_tkStubsPtr
_tkIntXlibStubsPtr
_tkIntStubsPtr
_tkIntPlatStubsPtr
_tkPlatStubsPtr
/usr/bin/libtool: internal link edit command failed
lipo: can't figure out the architecture type of: /var/tmp//ccOMqrpA.out
make: *** [libtile0.6.dylib] Error 1

I'm not sure where these symbols are supposed to come in: perhaps
someone with more knowledge than me would find this error message useful?


- --
Cheers,

Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOyO8JmdQs+6YVcoRApRQAJ4kbS+SU/2G9+Kfnf7Ff1p1Xi60rgCdEotd
8FzsUwgQiZ+yvMbEdme+dR8=
=2iMU
-----END PGP SIGNATURE-----

Re: [Tile-dev] Re: entry widget validation with textvariable "not right"

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

Earlier, I wrote:
>
> New patch 1302146 posted to SourceForge:
> This changes how the [ttk::entry] widget uses the 'invalid'
> state bit as follows:
> [...]
> Please try it out and let me know.

OK, so no feedback yet.  I'm going to go ahead and commit the patch;
it might not be right, but it's at least closer.

On a related note: what should [$e validate] return?

The core manpage entry(n) just says:

| pathName validate
| 	This command is used to force an evaluation of the validateCommand
| 	independent of the conditions specified by the validate
| 	option. This is done by temporarily setting the validate option
| 	to all. It returns 0 or 1.
|               ^^^^^^^^^^^^^^^^^

Based on the manpage, the [ttk::entry] validate method is compatible --
it does, in fact, always return 0 or 1 -- but the conditions under which
it does so might be different -- see #1236979.

(Which brings up another minor incompatibility: -- The core entry widget
performs validation "by temporarily setting the -validate option to 'all'".
The ttk::entry widget performs validation by performing validation.
I don't think this is too serious a problem ....)


--Joe English

  jen...@fl...

Re: [Tile-dev] Problems building "universal binary" of Tile

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

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

Joe,

Daniel Steffen also mentioned on the Tcl-Mac list that he is preparing
some additional updates to Tcl-Mac to address things like byte swapping
in preparation for the transition to MacTel. After posting my earlier
message, I also noticed some similar errors when I tried to compile
tktreectrl as a universal binary. Perhaps once Daniel's new revisions
are committed, that might address the issue.

Cheers,

Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
sw at wordtech-software.com

Joe English wrote:
| Kevin Walzer wrote:
|
|
|>I'm trying to build a "universal binary" of Tile on Mac OS X, 10.4, with
|>gcc 4. I've successfully compiled Tk, but during make, Tile returns
|>these errors:
|>
|>In file included from ./macosx/aquaTheme.c:35:
|>/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before
|>'int'In file included from ./macosx/aquaTheme.c:35:
|>/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before 'int'
|>
|>[ ... gobs of errors elided ... ]
|
|
|
| macosx/aquaTheme.c currently includes the following headers:
|
| | #include <Carbon/Carbon.h>
| | #include <tk.h>
| | #include <tkInt.h>
| | #include <tkMacOSX.h>
| | #include <tkMacOSXInt.h>
| | #include "tkTheme.h"
|
|
| Now I'm pretty sure that's the Wrong Thing -- it was arrived at
| by trial and error, by adding, deleting, and reordering the #includes
| until the file finally compiled on the machine I was using at the time --
| but I don't know what the Right Thing is.
|
| Any advice from AquaTk gurus?  aquaTheme.c needs the Carbon API(s),
| plus a couple routines from the platform-specific public Tk API
| (TkMacOSXGetDrawablePort and TkMacOSXWinBounds).  What headers
| should be included, and in which order?
|
|
|
| --Joe English
|
|   jen...@fl...
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by:
| Power Architecture Resource Center: Free content, downloads, discussions,
| and more. http://solutions.newsforge.com/ibmarch.tmpl
| _______________________________________________
| Tktable-tile-dev mailing list
| Tkt...@li...
| https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOgPOJmdQs+6YVcoRAnj0AJwN5SKApCdp0ZMz/V6nEHl/KtnFpACeMpr0
KttMqWY8lW/FXdJ31lacIoE=
=E6eX
-----END PGP SIGNATURE-----

Re: [Tile-dev] Problems building "universal binary" of Tile

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

Kevin Walzer wrote:

> I'm trying to build a "universal binary" of Tile on Mac OS X, 10.4, with
> gcc 4. I've successfully compiled Tk, but during make, Tile returns
> these errors:
>
> In file included from ./macosx/aquaTheme.c:35:
> /Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before
> 'int'In file included from ./macosx/aquaTheme.c:35:
> /Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before 'int'
>
> [ ... gobs of errors elided ... ]


macosx/aquaTheme.c currently includes the following headers:

| #include <Carbon/Carbon.h>
| #include <tk.h>
| #include <tkInt.h>
| #include <tkMacOSX.h>
| #include <tkMacOSXInt.h>
| #include "tkTheme.h"


Now I'm pretty sure that's the Wrong Thing -- it was arrived at
by trial and error, by adding, deleting, and reordering the #includes
until the file finally compiled on the machine I was using at the time --
but I don't know what the Right Thing is.

Any advice from AquaTk gurus?  aquaTheme.c needs the Carbon API(s),
plus a couple routines from the platform-specific public Tk API
(TkMacOSXGetDrawablePort and TkMacOSXWinBounds).  What headers
should be included, and in which order?



--Joe English

  jen...@fl...

[Tile-dev] Stippling images in disabled buttons

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

Tile widgets with an -image (buttons, labels, etc.) currently
draw the image stippled when they are in the disabled state,
like the core widgets do.

Would anyone complain if this feature went away?  

This behavior is disabled on OSX to work around an AquaTk bug (#1100117);
according to a recent post on comp.lang.tcl [*] it doesn't work all 
that well under X11 either (specifically, when the image has an 
alpha channel); and even when it does work it doesn't look very
good (common practice nowadays is to use a desaturated, darkened,
or grayscale image instead of stippling).

Note that the Tile widgets allow the program to specify state-dependent
auxilliary images, so this effect is still possible; it just takes
some extra work on the programmer's part.  We could provide a utility
routine to automatically generate "grayed-out" versions of icon
images to ease the pain.

Anyway, unless somebody objects, I plan to nuke this part of the code. 


--Joe English

  jen...@fl...

[*] <URL: http://groups.google.com/groups?selm=Kzg_e.3703$zQ...@ne... >

[Tile-dev] Problems building "universal binary" of Tile

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

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

I'm trying to build a "universal binary" of Tile on Mac OS X, 10.4, with
gcc 4. I've successfully compiled Tk, but during make, Tile returns
these errors:

In file included from ./macosx/aquaTheme.c:35:
/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before
'int'In file included from ./macosx/aquaTheme.c:35:
/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before 'int'
/Users/kevin/tk/macosx/tkMacOSXInt.h:155: error: syntax error before 'void'
/Users/kevin/tk/macosx/tkMacOSXInt.h:156: error: syntax error before 'int'
/Users/kevin/tk/macosx/tkMacOSXInt.h:157: error: syntax error before 'void'
/Users/kevin/tk/macosx/tkMacOSXInt.h:158: error: syntax error before 'int'
/Users/kevin/tk/macosx/tkMacOSXInt.h:159: error: syntax error before
'WindowClass'

/Users/kevin/tk/macosx/tkMacOSXInt.h:155: error: syntax error before 'void'
/Users/kevin/tk/macosx/tkMacOSXInt.h:156: error: syntax error before 'int'
/Users/kevin/tk/macosx/tkMacOSXInt.h:157: error: syntax error before 'void'
/Users/kevin/tk/macosx/tkMacOSXInt.h:158: error: syntax error before 'int'
/Users/kevin/tk/macosx/tkMacOSXInt.h:159: error: syntax error before
'WindowClass'
./macosx/aquaTheme.c: In function 'ButtonElementDraw':
./macosx/aquaTheme.c:199: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
./macosx/aquaTheme.c: In function 'ButtonElementDraw':
./macosx/aquaTheme.c:199: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
./macosx/aquaTheme.c: In function 'PopupArrowElementDraw':
./macosx/aquaTheme.c:423: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
./macosx/aquaTheme.c:436: warning: passing argument 6 of
'DrawThemePopupArrow' makes integer from pointer without a cast
./macosx/aquaTheme.c: In function 'PopupArrowElementDraw':
./macosx/aquaTheme.c:423: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
./macosx/aquaTheme.c:436: warning: passing argument 6 of
'DrawThemePopupArrow' makes integer from pointer without a cast
./macosx/aquaTheme.c: In function 'TreeHeaderElementDraw':
./macosx/aquaTheme.c:827: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
./macosx/aquaTheme.c: In function 'TreeHeaderElementDraw':
./macosx/aquaTheme.c:827: warning: passing argument 7 of
'DrawThemeButton' makes integer from pointer without a cast
lipo: can't open input file: /var/tmp//ccCejjQ3.out (No such file or
directory)
make: *** [aquaTheme.o] Error 1

Any idea what the problem might be?

- --
Cheers,

Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOap+JmdQs+6YVcoRArUeAJ4iTt5v6Nti8m3wyu/08t2acIGPvgCfZLKF
WabT0jCJzpLBVYSy7MyXqm4=
=lq4z
-----END PGP SIGNATURE-----

RE: [Tile-dev] possible to detect click on image in a notebook tab?

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

> Jeff Hobbs wrote:
> >>>>If that's not possible or planned, is there any way to add a clickable
> >>>>image in the right of the blank area reserved for tabs (ala firefox) 
> >>>>other than by placing it with place, which sounds decidedly difficult 
> >>>>to make work in a cross platform way?
> > 
> > 
> >>I'd like to suggest something like this:
> >>
> >>     ttk::button .nb.dismiss ....
> >>     .nb addwidget .nb.dismiss
> >>
> >>This would let you add widgets to appear in the trough. They would
> >>appear right-aligned, and you could potentially add more than one. 
> > 
> > Is this possible an instance where place is appropriate?
> 
> If I understand what you're suggesting I say no, because if one had a 
> sufficiently large number of tabs, the thing placed in the 
> trough would overlay the tabs and look rather sloppy.

I asked because it looks like that's what Firefox does ... IFF
you have enough tabs.  It does appear to respect the [X] corner
space until you really cram the tabs in.

Jeff

RE: [Tile-dev] possible to detect click on image in a notebook tab?

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

> >>If that's not possible or planned, is there any way to add a clickable 
> >>image in the right of the blank area reserved for tabs (ala firefox) 
> >>other than by placing it with place, which sounds decidedly difficult 
> >>to make work in a cross platform way?

> I'd like to suggest something like this:
> 
>      ttk::button .nb.dismiss ....
>      .nb addwidget .nb.dismiss
> 
> This would let you add widgets to appear in the trough. They would 
> appear right-aligned, and you could potentially add more than one. 

Is this possible an instance where place is appropriate?

Jeff

Re: [Tile-dev] Default look vs custom-made look

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

Sori Schwimmer wrote:
> Didn't realised that Tile is a replacement for Tk, but
> now is clear. I need one more piece of advice though:

It is not a replacement, it is an ... addendum.  It provides
themed replacements for most of the classic Tk widgets, along
with some new common controls, but the old ones will remain.
There are many cases where the classic controls still find
themselves more appropriate in a UI than a themed one.

> # let's manipulate the look of bt2:
> bt2.grid() # place it on the screen
> bt2.tk.call('style','map','-background {active
> #0000ff}') # to make it green
> 
> Nothing happens on the screen. Any hint how should I
> proceed?

OK, the correct call would be:

bt2.tk.call('style', 'map', 'TButton',
             '-background', '{active green}')

You require the named style, and in this case you want to
apply it to TButton (the class of the themed button).  Note
that it really affects the background drawn, not the
highlight element.

-- 
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos

RE: [Tile-dev] Default look vs custom-made look

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

Sori Schwimmer wrote:
> --- Jeff Hobbs <je...@Ac...> wrote:
> > OK, the correct call would be:
> > 
> > bt2.tk.call('style', 'map', 'TButton',
> >              '-background', '{active green}')
> > 
> > You require the named style, and in this case you want to
> > apply it to TButton (the class of the themed button).  Note
> > that it really affects the background drawn, not the highlight 
> > element.
> 
> Thanks for your answer. That's not it though; I end up
> with:
> 
> _tkinter.TclError: State map must have an even number
> of elements
> 
> which is odd...

My bad, that should be 'active green' (no {}).

Jeff

Re: [Tile-dev] Default look vs custom-made look

[Sori S. <sx...@ya...>]

--- Jeff Hobbs <je...@Ac...> wrote:

> 
> OK, the correct call would be:
> 
> bt2.tk.call('style', 'map', 'TButton',
>              '-background', '{active green}')
> 
> You require the named style, and in this case you
> want to
> apply it to TButton (the class of the themed
> button).  Note
> that it really affects the background drawn, not the
> highlight element.

Thanks for your answer. That's not it though; I end up
with:

_tkinter.TclError: State map must have an even number
of elements

which is odd...

Sorin Schwimmer


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: [Tile-dev] Default look vs custom-made look

[Donal K. F. <don...@ma...>]

Sori Schwimmer wrote:
> Didn't realised that Tile is a replacement for Tk, but
> now is clear. I need one more piece of advice though:

It isn't exactly a replacement. It's an alternate set of widgets that
happen to be better at theming, but some widgets remain Tk only (e.g.
the canvas widget) and others are indeed Tile only (e.g. the tabnotebook).

(I'm leaving your query to someone who understands the details of things
better. ;-) )

Donal.

Re: Re: [Tile-dev] Default look vs custom-made look

[Sori S. <sx...@ya...>]

Didn't realised that Tile is a replacement for Tk, but
now is clear. I need one more piece of advice though:
I am comming from Python, and am trying to manipulate
the widgets with Python syntax, and, maybe, a few Tk
calls.
For instance:

from Tkinter import *
r=Tk()
bt=Button(r,text='Something') # that's a Tk button
# here is the proof:
bt.keys()
['activebackground', 'activeforeground', 'anchor',
'background', 'bd', 'bg', 'bitmap', 'borderwidth',
'command', 'compound', 'cursor', 'default',
'disabledforeground', 'fg', 'font', 'foreground',
'height', 'highlightbackground', 'highlightcolor',
'highlightthickness', 'image', 'justify',
'overrelief', 'padx', 'pady', 'relief', 'repeatdelay',
'repeatinterval', 'state', 'takefocus', 'text',
'textvariable', 'underline', 'width', 'wraplength']
# loading the Tile environment:
r.tk.call('package','require','tile')
r.tk.call('namespace','import','-force','ttk::*')
r.tk.call('tile::setTheme','blue')
bt2=Button(r,text='Something blue') # that's a Tile
button
# here is the proof:
bt2.keys()
['activebackground', 'activeforeground', 'anchor',
'background', 'bd', 'bg', 'bitmap', 'borderwidth',
'disabledforeground', 'fg', 'font', 'foreground',
'height', 'highlightbackground', 'highlightcolor',
'highlightthickness', 'justify', 'overrelief', 'padx',
'pady', 'relief', 'repeatdelay', 'repeatinterval',
'wraplength', 'takefocus', 'command', 'default',
'text', 'textvariable', 'underline', 'width', 'image',
'compound', 'padding', 'state', 'takefocus', 'cursor',
'style', 'class']
# bt2 has style and class ;-) and padding

# let's manipulate the look of bt2:
bt2.grid() # place it on the screen
bt2.tk.call('style','map','-background {active
#0000ff}') # to make it green

Nothing happens on the screen. Any hint how should I
proceed?

Thanks agains,
Sorin Schwimmer

--- Joe English <jen...@fl...> wrote:

> 
> In most cases, the Tile widgets are actually much
> more
> customizable than their core counterparts -- just
> not
> through widget options.
> 
> As a rule of thumb, tile widgets only include the
> "essential"
> options relating to the function of the widget,
> while everything
> appearance-related is handled by the style. 
> (Deciding which
> options are "essential" and which aren't generally
> comes down
> to a judgment call -- my tendency has been to leave
> options
> out when in doubt.)
> 
> But each widget has a '-style' option that can be
> used to select
> a custom style, by which nearly every aspect of the
> appearance
> can be specified.  The process of defining custom
> styles isn't
> very well documented, but the Tcl'2004 presentation
> on Tile
> is a good place to start:
> 
>     <URL:
> http://tktable.sourceforge.net/tile/tile-tcl2004.pdf
> >
> 
> 
> --Joe English
> 
>   jen...@fl...
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's
> Geronimo App Server. 
> Download it for free - -and be entered to win a 42"
> plasma tv or your very
> own Sony(tm)PSP.  Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
>
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: [Tile-dev] possible to detect click on image in a notebook tab?

[Bryan O. <oa...@ba...>]

Jeff Hobbs wrote:
>>>>If that's not possible or planned, is there any way to add a clickable 
>>>>image in the right of the blank area reserved for tabs (ala firefox) 
>>>>other than by placing it with place, which sounds decidedly difficult 
>>>>to make work in a cross platform way?
> 
> 
>>I'd like to suggest something like this:
>>
>>     ttk::button .nb.dismiss ....
>>     .nb addwidget .nb.dismiss
>>
>>This would let you add widgets to appear in the trough. They would 
>>appear right-aligned, and you could potentially add more than one. 
> 
> 
> Is this possible an instance where place is appropriate?
> 

If I understand what you're suggesting I say no, because if one had a 
sufficiently large number of tabs, the thing placed in the trough would 
overlay the tabs and look rather sloppy.

Re: [Tile-dev] Default look vs custom-made look

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

Sori Schwimmer wrote:
>
> I installed recently Tiles, and found them an
> excellent idea - change consistently the look and feel
> of a whole application in only three lines of code.
> Then I stumbled over the following problem: sometime I
> want to overwrite the default theme's look and
> enforce, say, a yellow background on a label when
> using, say, the blue theme. Not always possible:
> Tkinter, Tix and Pmw label won't bulge, while BWidget
> labels will. Same for bg in entries - none will let me
> do it. Pmw is offering some bg themes for validating
> data or marking it read-only - it's not working
> anymore. Now, there is to much consistency.
>
> Everything takes the values given by the Tile theme.
> Is it possible to enforce Tile theme's graphical
> values only for defaults, and let the programmer
> change things at will? Or is it to late relative to
> where the package is going?


In most cases, the Tile widgets are actually much more
customizable than their core counterparts -- just not
through widget options.

As a rule of thumb, tile widgets only include the "essential"
options relating to the function of the widget, while everything
appearance-related is handled by the style.  (Deciding which
options are "essential" and which aren't generally comes down
to a judgment call -- my tendency has been to leave options
out when in doubt.)

But each widget has a '-style' option that can be used to select
a custom style, by which nearly every aspect of the appearance
can be specified.  The process of defining custom styles isn't
very well documented, but the Tcl'2004 presentation on Tile
is a good place to start:

    <URL: http://tktable.sourceforge.net/tile/tile-tcl2004.pdf >


--Joe English

  jen...@fl...

Re: [Tile-dev] possible to detect click on image in a notebook tab?

[Bryan O. <oa...@ba...>]

Joe English wrote:
> Bryan Oakley wrote:
> 
> 
>>Is it possible to detect a click over the image of a ttk::notebook tab?
>>I'm wanting to put a graphical (x) on each tab (ala safari) for
>>dismissing the tab. I can display the image but I'm not sure how to go
>>about making it active.
> 
> 
> Not at present; one possibility would be to add an [$nb identify $x $y]
> command that would return the tab index and element at position $x,$y.
> 

It only took me three weeks to get back to this issue... darn work is 
getting in the way of my playing around with tile! :-)

Yes, I agree that [$nb identify $x $y] seems like the right solution. It 
could, for instance, return "image 0" if you click on the image for tab 
0, "tab 0" if you click on any other part of the tab, "trough" if you 
click in the trough (unoccupied area where tabs appear).

>>If that's not possible or planned, is there any way to add a clickable
>>image in the right of the blank area reserved for tabs (ala firefox)
>>other than by placing it with place, which sounds decidedly difficult to
>>make work in a cross platform way?
> 
> 
> I'd like to be able to support this UI idiom as well, but haven't
> thought of a good way to specify it yet.  Ideas?

I'd like to suggest something like this:

     ttk::button .nb.dismiss ....
     .nb addwidget .nb.dismiss

This would let you add widgets to appear in the trough. They would 
appear right-aligned, and you could potentially add more than one. 
Normally you'd just add buttons, but labels or progressbars might be 
other choices. This could easily be abused to put all kind of cruft in 
there, but hopefully most people would limit themselves to a bare 
minimum (read: firefox-like "close the current tab" button)

[Tile-dev] tile treeview column heading alignment...

[Bryan O. <oa...@ba...>]

In the tile treeview it doesn't seem possible to change the anchor of 
the text in a column heading. Is this an intentional design decision 
either at the widget or style level? It seems like either the heading 
ought to have the same anchor as the column, or there should be a 
'heading $column -anchor' option.

Re: [Tile-dev] Re: entry widget validation with textvariable "not right"

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

New patch 1302146 posted to SourceForge:

    <URL: http://sourceforge.net/tracker/index.php?func=detail&aid=1302146&group_id=11464&atid=311464 >

This changes how the [ttk::entry] widget uses the 'invalid'
state bit as follows:

    + In prevalidation (-validate key), the result of
    -validatecommand only determines whether the edit
    should be accepted or rejected. It no longer clears
    the 'invalid' bit, and will reject edits on validation
    failure even if the widget is currently invalid.

    + In revalidation (-validate focus/focusin/focusout, or
    calling [$e validate]), the result of -validatecommand
    is used to set or clear the 'invalid' bit.

This is simpler and more orthogonal than the current logic;
whether it's more useful remains to be seen :-) Please try it
out and let me know.

Other things I'm considering: possibly, allow -validatecommand to
return the empty string to indicate "Don't do anything, I'm being
used for side effects only".

Another possibility is to split '-validatecommand' into two options,
one for prevalidation and another for revalidation.  This would
clear up a lot of ambiguities with the current API, but would add
another incompatibility with the core [entry] widget.


--Joe English

  jen...@fl...

Re: [Tile-dev] Random treeview suggestion

[<ke...@cr...>]

je...@ac... said:
> I'll take a trip to Hawaii - it's much closer.

Here I thought Vancouver *was* the Hawaii of Canada?  ;)
--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tile-dev] Random treeview suggestion

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

Jeff Hobbs wrote:
> Larry McVoy wrote:
> 
>>For those of you on windows, try downloading process explorer 
>>from www.sysinternals.com (it's like top and ps -axf rolled 
>>into one; and filemon from the same place is a lot like a 
>>graphical lsof).
>>
>>If someone could take the treeview widget and dummy up 
>>something that worked liked this on Unix I think that would 
>>be an excellent test of emulating a working, useful, polished 
>>Windows app.  Assuming that's of any interest.
> 
> 
> This already exists in the tktreectrl:
> 	http://tktreectrl.sourceforge.net/
> 
> The latest version does themed header buttons as well.  We use
> it in the TDK VFS Explorer.

BTW, Joe and I have talked about this, and the reason he
moves forward with treeview is that tktreectrl is ...
complex.  It is like the canvas, plus more.  We have had
good success layering snidgets over it though, reducing
the complexity that way.  For all-out functionality though,
it is already there, you just need to be ready to dig in.

Jeff

Re: [Tile-dev] Random treeview suggestion

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

Larry McVoy wrote:
> We reserve the right to define "good things".  It doesn't include a 
> trip to Tahiti :)  

I'll take a trip to Hawaii - it's much closer.  ;)

Jeff

[Tile-dev] Default look vs custom-made look

[Sori S. <sx...@ya...>]

Hi,

I'm new to this forum, so I hope I won't ask something
that was already asked.

My platform: Gentoo 2005, KDE, Tcl/Tk 8.4, Python
2.4.1. I'm working in Python.

I installed recently Tiles, and found them an
excellent idea - change consistently the look and feel
of a whole application in only three lines of code.
Then I stumbled over the following problem: sometime I
want to overwrite the default theme's look and
enforce, say, a yellow background on a label when
using, say, the blue theme. Not always possible:
Tkinter, Tix and Pmw label won't bulge, while BWidget
labels will. Same for bg in entries - none will let me
do it. Pmw is offering some bg themes for validating
data or marking it read-only - it's not working
anymore. Now, there is to much consistency.

Everything takes the values given by the Tile theme.
Is it possible to enforce Tile theme's graphical
values only for defaults, and let the programmer
change things at will? Or is it to late relative to
where the package is going?

Thanks for a great package,
Sorin Schwimmer


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: [Tile-dev] Random treeview suggestion

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

On Wed, Sep 21, 2005 at 08:41:13AM +0800, Steve Landers wrote:
> 
> On 21/09/2005, at 8:25 AM, Larry McVoy wrote:
> 
> >On Tue, Sep 20, 2005 at 05:20:27PM -0700, Larry McVoy wrote:
> >
> >>For those of you on windows, try downloading process explorer from
> >>www.sysinternals.com (it's like top and ps -axf rolled into one;
> >>and filemon from the same place is a lot like a graphical lsof).
> >>
> >>If someone could take the treeview widget and dummy up something that
> >>worked liked this on Unix I think that would be an excellent test of
> >>emulating a working, useful, polished Windows app.  Assuming that's
> >>of any interest.
> >>
> >
> >Oy, that last sentence probably came off in classic Larry McVoy snotty
> >style.  Sorry about that, that wasn't the intent.  What I was trying
> >to say is that it's a good app to emulate, if tcl/tk could do that  
> >look
> >and feel and functionality easily that would be a good thing for  
> >tcl/tk.
> 
> And here's me thinking of replying "Sarcasm becomes you" :)
> 
> Cheers Larry - that's a good reference point.

I really do apologize, I'm well known for having the world's worst user
interface in email.  Linus once told someone "If you need to talk to 
Larry then call him on the phone - you'll find, much to your surprise,
he's actually a very reasonable person when you talk to him live".

Or something like that, I cc-ed Linus so he can deny he ever said anything
like that.

I will admit that I've pissed off virtually everyone in email.  I don't
mean to, it just happens.  Someone needs to come take the keyboard away
from me.  Sigh.

OK, Mea Culpas aside, I have been living on Windows for the last couple of
months and have learned a lot about how things are supposed to work there.
And I'd really like to see tcl/tk so native that nobody could tell the 
difference.  And we have (some) money.  So if people are looking for work
and think they can help and the tile folks want that help then maybe we 
can help make that happen.  If Joe and Jeff say "please give XYZ some 
bucks, good things will happen" then we're pretty likely to do so.

We reserve the right to define "good things".  It doesn't include a 
trip to Tahiti :)  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] Random treeview suggestion

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

On 21/09/2005, at 8:25 AM, Larry McVoy wrote:

> On Tue, Sep 20, 2005 at 05:20:27PM -0700, Larry McVoy wrote:
>
>> For those of you on windows, try downloading process explorer from
>> www.sysinternals.com (it's like top and ps -axf rolled into one;
>> and filemon from the same place is a lot like a graphical lsof).
>>
>> If someone could take the treeview widget and dummy up something that
>> worked liked this on Unix I think that would be an excellent test of
>> emulating a working, useful, polished Windows app.  Assuming that's
>> of any interest.
>>
>
> Oy, that last sentence probably came off in classic Larry McVoy snotty
> style.  Sorry about that, that wasn't the intent.  What I was trying
> to say is that it's a good app to emulate, if tcl/tk could do that  
> look
> and feel and functionality easily that would be a good thing for  
> tcl/tk.

And here's me thinking of replying "Sarcasm becomes you" :)

Cheers Larry - that's a good reference point.

Steve

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