tktable-tile-dev — Discussion about tile development

[Tile-dev] treeview hidden columns

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

It seems impossible to create a treeview that has one invisible data 
column. Or am I missing something?

In other words, this gives me three columns, with two visible (the tree 
column and one data column)

   ttk::treeview .tv1 -columns {foo bar} -displaycolumns {foo}

but this gives me two columns with two visible (the tree column and one 
data column)

   ttk::treeview .tv2 -columns {foo} -displaycolumns {}

That is because a -displaycolumn that is the empty string is synonymous 
with "show all rows". It seems to be impossible to have a condition 
where you want none of the data columns visible.

I discovered that I can add an item and give it values for more columns 
than it  has configured, though I'm wondering if that's a feature or a bug:

    ttk::treeview .tv3 -columns {}
    .tv3 insert "" end -values {"hidden value"} -text "visible value"

Is it kosher to be able to supply more values than there are columns? I 
see no other way to get the desired effect.

RE: [Tile-dev] Tile Entry Validation

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

Joey Mukherjee wrote:
> Before we started converting programs to Tile, we were validating the  
> contents of our entry boxes by changing the label and the entry  
> contents to red.  With tile, we can no longer do this.  With the  
> button, this probably makes sense.  With the entry contents, I feel  
> like it might still be nice to change this to red.  Is it possible?

# Ttk style mapping for invalid entry widgets
style map TEntry -fieldbackground {invalid \#FFFFE0} \
    -foreground {invalid \#FF0000}
style map TCombobox -fieldbackground {invalid \#FFFFE0} \
    -foreground {invalid \#FF0000}

The background won't change on most platforms, but the foreground should on
all.  The invalid state is handled by the entry widget on failed or valid
validation command.

Jeff

[Tile-dev] Tile Entry Validation

[Joey M. <jo...@sw...>]

Before we started converting programs to Tile, we were validating the  
contents of our entry boxes by changing the label and the entry  
contents to red.  With tile, we can no longer do this.  With the  
button, this probably makes sense.  With the entry contents, I feel  
like it might still be nice to change this to red.  Is it possible?

If not, how do you feel is the best non-intrusive way to let the user  
know there is something wrong.  Tooltips?

Thanks,
Joey

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> Brian Griffin wrote:
> 
>> Bryan Oakley wrote:
>>
>>> Brian Griffin wrote:
>>>
>>>> Huh?  You don't want keyboard traversal for a radio button in a 
>>>> toolbar on the main window, and that's what -takefocus 0 gives you.  
>>>> So what's the problem?
>>>
>>>
>>> I *do* want keyboard traversal on a toolbar. I just don't want a 
>>> click to set the focus to the toolbar. Thus, I can't use "-takefocus 
>>> 0" because that removes the ability to use keyboard traversal.
>>
>>
>> But why?  That, to me, is non-standard.
> 
> 
> To me, there's no difference between <Key-Tab> and <Button-1> as far as 
> setting focus.

Ha! That's a great question. I hate it when people make me think, 
especially during the work day!

I guess my only response is "because I've always done it that way". I've 
(almost) always tried to make my apps such that it's possible to 
traverse to and through the toolbar. Come to think of it, that's not 
strictly necessary since toolbar buttons should correspond to menu 
items, and menu items are keyboard-traversable.

You raise a good point.

<surfin'...>

Hmmm. I think this quote from MSDN validates click-to-focus for buttons 
(not that I put a whole lot of stock in documented Microsoft policies 
since they violate them at will...):

"Display the input focus when the mouse button is pressed and the cursor 
is over a control"

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14c.asp)

Interesting. I guess I stand corrected. Maybe click-to-focus on by 
default, and "-takefocus 0" for toolbar controls is the Right Thing To Do.

RE: [Tile-dev] setting focus on button clicks: on purpose?

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

Joe English wrote:
> Bryan Oakley wrote:
> > I noticed that with tile 0.7.2, if I click on a button the focus is 
> > set to that button. Investigating I see it is due to this:
> > 
> > % bind TRadiobutton <1>
> >   %W instate !disabled { tile::clickToFocus %W; %W state pressed }
> > 
> > Is this an intentional deviation from the standard widget behavior? 
> > The
> > normal tk widgets don't get focus when you click on them.
> 
> Yes, that's intentional; and thanks for bringing this up --
> 
> I checked the other major toolkits to see which ones use 
> click-to-focus: Gtk, Windows, Motif, Mozilla, and OpenOffice 
> all set focus-on-click for 
> radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac 
> do not.  

The Windows one is a little different, in that you don't see the focus ring
until you actually attempt to use keyboard traversal, although it does appear
to set focus to that widget.

> Tile buttons set focus-on-click by default, though this can 
> be disabled by setting '-takefocus 0' on the widget (see 
> tile::clickToFocus and tile::wantsFocus in library/utils.tcl). 

Shouldn't this be controllable without removing takefocus on the widget
totally?

Jeff

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> Bryan Oakley wrote:
>> Brian Griffin wrote:
>>> Huh?  You don't want keyboard traversal for a radio button in a 
>>> toolbar on the main window, and that's what -takefocus 0 gives you.  
>>> So what's the problem?
>>
>> I *do* want keyboard traversal on a toolbar. I just don't want a 
>> click to set the focus to the toolbar. Thus, I can't use "-takefocus 
>> 0" because that removes the ability to use keyboard traversal.
>
> But why?  That, to me, is non-standard.

To me, there's no difference between <Key-Tab> and <Button-1> as far as 
setting focus.

-Brian

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Bryan Oakley wrote:
> Brian Griffin wrote:
>> Huh?  You don't want keyboard traversal for a radio button in a 
>> toolbar on the main window, and that's what -takefocus 0 gives you.  
>> So what's the problem?
>
> I *do* want keyboard traversal on a toolbar. I just don't want a click 
> to set the focus to the toolbar. Thus, I can't use "-takefocus 0" 
> because that removes the ability to use keyboard traversal.

But why?  That, to me, is non-standard.

-Brian

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> Huh?  You don't want keyboard traversal for a radio button in a toolbar 
> on the main window, and that's what -takefocus 0 gives you.  So what's 
> the problem?

I *do* want keyboard traversal on a toolbar. I just don't want a click 
to set the focus to the toolbar. Thus, I can't use "-takefocus 0" 
because that removes the ability to use keyboard traversal.

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Bryan Oakley wrote:
> Joe English wrote:
>> [ Just catching up with the discussion ... ]
>>
>> Bryan Oakley wrote:
>>
>>
>>> I noticed that with tile 0.7.2, if I click on a button the focus is 
>>> set to that button. Investigating I see it is due to this:
>>>
>>> % bind TRadiobutton <1>
>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>>>
>>> Is this an intentional deviation from the standard widget behavior? 
>>> The normal tk widgets don't get focus when you click on them.
>>
>>
>> Yes, that's intentional; and thanks for bringing this up --
>>
>> I checked the other major toolkits to see which ones use click-to-focus:
>> Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click 
>> for radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do 
>> not. 
>> Tile buttons set focus-on-click by default, though this can be
>> disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
>> and tile::wantsFocus in library/utils.tcl). 
>
> Setting -takefocus to zero is definitely not the right solution. We 
> don't want to completely remove the ability to traverse the widgets 
> with the keyboard, which is what -takefocus 0 does. I just don't want 
> a click on a radiobutton, checkbutton or tool button on my toolbar to 
> steal focus away from the main data entry area of my application.

Huh?  You don't want keyboard traversal for a radio button in a toolbar 
on the main window, and that's what -takefocus 0 gives you.  So what's 
the problem?

-Brian

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Joe English wrote:
> [ Just catching up with the discussion ... ]
> 
> Bryan Oakley wrote:
> 
> 
>>I noticed that with tile 0.7.2, if I click on a button the focus is set 
>>to that button. Investigating I see it is due to this:
>>
>>% bind TRadiobutton <1>
>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>>
>>Is this an intentional deviation from the standard widget behavior? The 
>>normal tk widgets don't get focus when you click on them.
> 
> 
> Yes, that's intentional; and thanks for bringing this up --
> 
> I checked the other major toolkits to see which ones use click-to-focus:
> Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click for 
> radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do not.  
> 
> Tile buttons set focus-on-click by default, though this can be
> disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
> and tile::wantsFocus in library/utils.tcl). 

Setting -takefocus to zero is definitely not the right solution. We 
don't want to completely remove the ability to traverse the widgets with 
the keyboard, which is what -takefocus 0 does. I just don't want a click 
on a radiobutton, checkbutton or tool button on my toolbar to steal 
focus away from the main data entry area of my application.

As it stands today, the only way to get the behavior I want is to 
completely override the class bindings. This is not a particularly good 
solution either.

What we need is a separate option that specifies whether a click will 
give focus. Yet, we already have a mechanism to do that -- bind 
.whatever <1> {focus %W}.

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

[ Just catching up with the discussion ... ]

Bryan Oakley wrote:

> I noticed that with tile 0.7.2, if I click on a button the focus is set 
> to that button. Investigating I see it is due to this:
> 
> % bind TRadiobutton <1>
>   %W instate !disabled { tile::clickToFocus %W; %W state pressed }
> 
> Is this an intentional deviation from the standard widget behavior? The 
> normal tk widgets don't get focus when you click on them.

Yes, that's intentional; and thanks for bringing this up --

I checked the other major toolkits to see which ones use click-to-focus:
Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click for 
radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do not.  

Tile buttons set focus-on-click by default, though this can be
disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
and tile::wantsFocus in library/utils.tcl). 


--Joe English

  jen...@fl...

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> Jeff Hobbs wrote:

>>
>> I think you are arguing a slightly orthogonal point.  Bryan noted that 
>> the buttons receive focus when you click on them - not that they can 
>> possibly receive focus at all (like via the Tab key).  I'm not 
>> advocating removing the ability to receive focus, just that clicking 
>> on them doesn't automatically add focus (thus negating the current 
>> "clickToFocus" behavior).  This should not alter keyboard traversal 
>> behavior.
> 
> 
> I'm not so sure they are completely orthogonal.  When using a mix of 
> mouse and keyboard, it seems reasonable that the last mouse click sets 
> the starting point of the next key stroke, whether it's an invoke or 
> Tab-Next key, especially in dialog boxes.

I'll agree with Jeff. No, Brian. No, Jeff!

I think there's no universal truth for when clicking on a button moves 
focus there, though I think way more often than not we do _not_ want 
focus to go to a button when it is clicked.

Dialogs are a likely exception, though I'm not sure I can think of any 
other exceptions.

The other point is, it's much easier for a programmer to add 
click-to-focus than it is to remove it. To add it I just do "bind 
.whatever <1> {focus %W}". If focus is set automatically by the class 
bindings I either have to replace the class bindings (something I'm 
generally loathe to do), or do something gross like "bind .whatever 
<ButtonPress-1> {rememberFocus}; bind .whatever <ButtonRelease-1> 
{restoreFocus}"

I vote for removing the default click-to-focus of buttons and letting 
the programmer easily choose when they want a button to have focus.

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> I'm not so sure they are completely orthogonal.  When using a mix of 
> mouse and keyboard, it seems reasonable that the last mouse click sets 
> the starting point of the next key stroke, whether it's an invoke or 
> Tab-Next key, especially in dialog boxes.

Having read the discussion so far, it sounds to me like whether a button
(or related widget) takes focus on being clicked is really a feature of
the style. Dialog box buttons probably should because it makes keyboard
navigation much easier, toolbar buttons probably shouldn't since they'd
steal the focus from the main widget of the window and there ought to be
at least two alternate mechanisms for invoking them anyway (menus and
keyboard shortcuts).

Donal.

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Jeff Hobbs wrote:
> Brian Griffin wrote:
>> Jeff Hobbs wrote:
>>>>>> I noticed that with tile 0.7.2, if I click on a button the focus 
>>>>>> is set to that button. Investigating I see it is due to this:
>>>>>>
>>>>>> % bind TRadiobutton <1>
>>>>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>
>>> Don't take my word for it, because you are right.  I usually go to 
>>> the Display Properties on XP for reference.  Lacking radiobuttons 
>>> there, I went to Firefox - which is itself using an emulated native 
>>> widget set. Firefox does set focus on radio click, but you are right 
>>> that native XP widgets don't seem to by default.  I can't find this 
>>> behavior on OS X either, even when fiddling with various 
>>> focus/keypad handling preferences.
>>>
>>> I would argue that this feature should be controlled by some master 
>>> switch, off by default (or perhaps only on on unix?).
>
>> I think it's more complicated then that.  In a dialog box, you want 
>> focus to go to buttons so that keyboard traversal is possible 
>> (consider mouse-less operations).  When it comes to toolbars; these 
>> are just a short hand way to access menus, and because of the 
>> plethora of buttons there, including them in keyboard traversal would 
>> just add too much to the window.  Because of the organization of the 
>> menus, it's easier to invoke stuff from them when using the 
>> keyboard.  Things like scrollbars (should) have independent keyboard 
>> controls, so there's no need for them to ever take focus.
>>
>> So the question to ask is: can I control the take-focus of a button 
>> when I need to, based on where and how the button is used?
>
> I think you are arguing a slightly orthogonal point.  Bryan noted that 
> the buttons receive focus when you click on them - not that they can 
> possibly receive focus at all (like via the Tab key).  I'm not 
> advocating removing the ability to receive focus, just that clicking 
> on them doesn't automatically add focus (thus negating the current 
> "clickToFocus" behavior).  This should not alter keyboard traversal 
> behavior.

I'm not so sure they are completely orthogonal.  When using a mix of 
mouse and keyboard, it seems reasonable that the last mouse click sets 
the starting point of the next key stroke, whether it's an invoke or 
Tab-Next key, especially in dialog boxes.

-Brian

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Brian Griffin wrote:
> Jeff Hobbs wrote:
>>>>> I noticed that with tile 0.7.2, if I click on a button the focus is 
>>>>> set to that button. Investigating I see it is due to this:
>>>>>
>>>>> % bind TRadiobutton <1>
>>>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }

>> Don't take my word for it, because you are right.  I usually go to the 
>> Display Properties on XP for reference.  Lacking radiobuttons there, I 
>> went to Firefox - which is itself using an emulated native widget set. 
>> Firefox does set focus on radio click, but you are right that native 
>> XP widgets don't seem to by default.  I can't find this behavior on OS 
>> X either, even when fiddling with various focus/keypad handling 
>> preferences.
>>
>> I would argue that this feature should be controlled by some master 
>> switch, off by default (or perhaps only on on unix?).

> I think it's more complicated then that.  In a dialog box, you want 
> focus to go to buttons so that keyboard traversal is possible (consider 
> mouse-less operations).  When it comes to toolbars; these are just a 
> short hand way to access menus, and because of the plethora of buttons 
> there, including them in keyboard traversal would just add too much to 
> the window.  Because of the organization of the menus, it's easier to 
> invoke stuff from them when using the keyboard.  Things like scrollbars 
> (should) have independent keyboard controls, so there's no need for them 
> to ever take focus.
> 
> So the question to ask is: can I control the take-focus of a button when 
> I need to, based on where and how the button is used?

I think you are arguing a slightly orthogonal point.  Bryan noted that 
the buttons receive focus when you click on them - not that they can 
possibly receive focus at all (like via the Tab key).  I'm not 
advocating removing the ability to receive focus, just that clicking on 
them doesn't automatically add focus (thus negating the current 
"clickToFocus" behavior).  This should not alter keyboard traversal 
behavior.

Jeff

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Jeff Hobbs wrote:
> Bryan Oakley wrote:
>> Jeff Hobbs wrote:
>>> Bryan Oakley wrote:
>>>
>>>> I noticed that with tile 0.7.2, if I click on a button the focus is 
>>>> set to that button. Investigating I see it is due to this:
>>>>
>>>> % bind TRadiobutton <1>
>>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>>>>
>>>> Is this an intentional deviation from the standard widget behavior? 
>>>> The normal tk widgets don't get focus when you click on them.
>>>
>>>
>>> But normal Windows widgets do (and likely true for other native 
>>> widget sets).
>>> Themed widgets should first follow platform style, and only 2nd (in 
>>> lieu of
>>> clear platform style) follow traditional Tk style.
>>
>> I guess I'll take your word for it. Wordpad on my machine, for 
>> example, doesn't set the focus to a button. I click on the clipboard 
>> button on the toolbar and the focus is still in the main part of the UI.
>>
>> On the Mac, run textedit and click on an alignment button on the 
>> toolbar and the focus stays in the main part of the UI. Likewise with 
>> mail.app, type in a name and click on the "Save as Draft" button on 
>> the toolbar and focus seems to stay where it was.
>
> Don't take my word for it, because you are right.  I usually go to the 
> Display Properties on XP for reference.  Lacking radiobuttons there, I 
> went to Firefox - which is itself using an emulated native widget set. 
> Firefox does set focus on radio click, but you are right that native 
> XP widgets don't seem to by default.  I can't find this behavior on OS 
> X either, even when fiddling with various focus/keypad handling 
> preferences.
>
> I would argue that this feature should be controlled by some master 
> switch, off by default (or perhaps only on on unix?).
I think it's more complicated then that.  In a dialog box, you want 
focus to go to buttons so that keyboard traversal is possible (consider 
mouse-less operations).  When it comes to toolbars; these are just a 
short hand way to access menus, and because of the plethora of buttons 
there, including them in keyboard traversal would just add too much to 
the window.  Because of the organization of the menus, it's easier to 
invoke stuff from them when using the keyboard.  Things like scrollbars 
(should) have independent keyboard controls, so there's no need for them 
to ever take focus.

So the question to ask is: can I control the take-focus of a button when 
I need to, based on where and how the button is used?

-Brian

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Bryan Oakley wrote:
> Jeff Hobbs wrote:
>> Bryan Oakley wrote:
>>
>>> I noticed that with tile 0.7.2, if I click on a button the focus is 
>>> set to that button. Investigating I see it is due to this:
>>>
>>> % bind TRadiobutton <1>
>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>>>
>>> Is this an intentional deviation from the standard widget behavior? 
>>> The normal tk widgets don't get focus when you click on them.
>>
>>
>> But normal Windows widgets do (and likely true for other native widget 
>> sets).
>> Themed widgets should first follow platform style, and only 2nd (in 
>> lieu of
>> clear platform style) follow traditional Tk style.
> 
> I guess I'll take your word for it. Wordpad on my machine, for example, 
> doesn't set the focus to a button. I click on the clipboard button on 
> the toolbar and the focus is still in the main part of the UI.
> 
> On the Mac, run textedit and click on an alignment button on the toolbar 
> and the focus stays in the main part of the UI. Likewise with mail.app, 
> type in a name and click on the "Save as Draft" button on the toolbar 
> and focus seems to stay where it was.

Don't take my word for it, because you are right.  I usually go to the 
Display Properties on XP for reference.  Lacking radiobuttons there, I 
went to Firefox - which is itself using an emulated native widget set. 
Firefox does set focus on radio click, but you are right that native XP 
widgets don't seem to by default.  I can't find this behavior on OS X 
either, even when fiddling with various focus/keypad handling preferences.

I would argue that this feature should be controlled by some master 
switch, off by default (or perhaps only on on unix?).

Jeff

Re: [Tile-dev] setting focus on button clicks: on purpose?

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

Jeff Hobbs wrote:
> Bryan Oakley wrote:
> 
>>I noticed that with tile 0.7.2, if I click on a button the 
>>focus is set to that button. Investigating I see it is due to this:
>>
>>% bind TRadiobutton <1>
>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>>
>>Is this an intentional deviation from the standard widget behavior? The 
>>normal tk widgets don't get focus when you click on them.
> 
> 
> But normal Windows widgets do (and likely true for other native widget sets).
> Themed widgets should first follow platform style, and only 2nd (in lieu of
> clear platform style) follow traditional Tk style.

I guess I'll take your word for it. Wordpad on my machine, for example, 
doesn't set the focus to a button. I click on the clipboard button on 
the toolbar and the focus is still in the main part of the UI.

On the Mac, run textedit and click on an alignment button on the toolbar 
and the focus stays in the main part of the UI. Likewise with mail.app, 
type in a name and click on the "Save as Draft" button on the toolbar 
and focus seems to stay where it was.

<shrug>

One mans bug is another mans feature. Its easy enough to work around.

RE: [Tile-dev] setting focus on button clicks: on purpose?

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

Bryan Oakley wrote:
> I noticed that with tile 0.7.2, if I click on a button the 
> focus is set to that button. Investigating I see it is due to this:
> 
> % bind TRadiobutton <1>
>   %W instate !disabled { tile::clickToFocus %W; %W state pressed }
> 
> Is this an intentional deviation from the standard widget behavior? The 
> normal tk widgets don't get focus when you click on them.

But normal Windows widgets do (and likely true for other native widget sets).
Themed widgets should first follow platform style, and only 2nd (in lieu of
clear platform style) follow traditional Tk style.

Jeff

[Tile-dev] setting focus on button clicks: on purpose?

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

I noticed that with tile 0.7.2, if I click on a button the focus is set 
to that button. Investigating I see it is due to this:

% bind TRadiobutton <1>
  %W instate !disabled { tile::clickToFocus %W; %W state pressed }

Is this an intentional deviation from the standard widget behavior? The 
normal tk widgets don't get focus when you click on them.

Re: [Tile-dev] ANNOUNCE: Tile Widget Set, version 0.7.6

[Mats B. <ma...@pr...>]

Joe English wrote:
> 
> In conjunction with this, I'd like to define a set of predefined 
> custom styles that users can count on being present in 
> every theme.  Right now there's just one -- Toolbutton --
> but there are many others that would be useful.  Suggestions
> welcome.
> 

Url style buttons perhaps (from coccinella.sf.net and coccinella/contrib/tileutils.tcl):

	# Url clickable link:
	style layout Url {
	    Url.background -children {
		Url.padding -children {
		    Url.label
		}
	    }
	}	    
	style configure Url  \
	  -padding 2 -relief flat -font $fonts(underlineDefault) -foreground blue
	style map Url -foreground [list active red]
	style configure Small.Url -font $fonts(underlineSmall)

More examples:

Headlabel---
	style layout Headlabel {
	    Headlabel.border -children {
		Headlabel.padding -children {
		    Headlabel.label -side left
		}
	    }
	}
	style configure Headlabel \
	  -font CociLargeFont -padding {20 6 20 6} -anchor w -space 12

Popupbutton---
	style layout Popupbutton {
	    Popupbutton.border -children {
		Popupbutton.padding -children {
		    Popupbutton.Combobox.downarrow
		}
	    }
	}
	style configure Popupbutton -padding 6

Minimenubutton---
	# This is a toolbutton style menubutton with a small downarrow.
	style layout MiniMenubutton {
	    Toolbutton.border -sticky nswe -children {
		Toolbutton.padding -sticky nswe -children {
		    MiniMenubutton.indicator -side right
		    Toolbutton.label -sticky nswe
		}
	    }
	}
	style element create MiniMenubutton.indicator image $tiles(downArrow) \
	  -sticky e -padding {6 2}
	style configure MiniMenubutton -padding 6


Mats

[Tile-dev] Ping?

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

Just checking if the mailing list is still working --
the 0.7.6 release announcement hasn't seemed to have gone out yet.

[Tile-dev] ANNOUNCE: Tile Widget Set, version 0.7.6

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

In honor of a month of SourceForge CVS outages,
the recent ActiveTcl release, and just to let everyone
know that the project hasn't totally stagnated,
it's time to release 0.7.6.  Announcement below.


For the 0.8 series, I'd like to focus on sorting out theme
definitions.  The current set of elements and default layouts
evolved in a somewhat ad-hoc fashion.  I plan to to go through
all the themes and rationalize some of the design decisions
(e.g., "checkbox" and "radiobutton" elements instead of
"Checkbutton.indicator" and "Radiobutton.indicator", use
a consistent color scheme scheme so people can get a reliable
answer to questions like "what's the default background color",
that sort of thing.)

In conjunction with this, I'd like to define a set of predefined 
custom styles that users can count on being present in 
every theme.  Right now there's just one -- Toolbutton --
but there are many others that would be useful.  Suggestions
welcome.


--Joe English 

[ announcement follows ]


[6 May 2006]

ANNOUNCE: Tile Widget Set, version 0.7.6.

~ What is it?

The Tile widget set is an experimental reimplementation
of some of the standard Tk widgets.  The main features are:

    + Native look and feel under Windows (XP, NT, 2K, 98 and 95)
    + Nearly-native look and feel under Mac OSX
    + "Revitalized" look and feel under X11
    + Appearance controlled by a theme engine, providing
      greater flexibility for custom widgets
    + New widgets, including notebook, progressbar, combobox,
      and separator.

~ What's New in 0.7.6

Tile 0.7.6 corresponds roughly to the CVS snapshot labelled '0.7.5'
which was included in the recently-released ActiveTcl 8.4.13.

+ ttk::entry widgets now support an 'identify' method,
  to support entry-based megawidgets.

+ ttk::notebook widgets have an 'insert' method, which allows
  new panes to be added at any position (not just the end).

+ The ttk::notebook 'select' method with no arguments now
  returns the currently-selected tab.

+ ttk::treeview 'identify' method interface has been revised
  to be easier to use.

+ ttk::treeview 'bbox' method added.

+ ttk::notebook and ttk::labelframe widgets have more flexible
  layout policies; better support for pixmap themes.

+ Keyboard navigation for ttk::notebooks now works when there
  are multiple notebooks in a single toplevel, including
  nested notebooks.

+ [style lookup] command added, for querying theme option values.

+ Several bugs have been fixed; see ChangeLog for details.

~ Stability

The script-level API for widgets may be considered stable at
this point, with the exception of procedures in the 'tile::*'
namespace.  Theme definitions are still subject to change:
user-defined themes will need to be revised in the 0.8 series.

~ A note on version numbers

To help distinguish formal releases from CVS snapshots,
the subminor version number will be incremented immediately before
and immediately after making a release.  Thus odd-numbered subminor
versions indicate a CVS snapshot, and even-numbered ones indicate
a known release.

~ Availability

The tile widget set is hosted under the tktable project
at SourceForge:

    <URL: http://tktable.sourceforge.net/tile/ >
    <URL: http://sourceforge.net/projects/tktable/ >

Sources are available under the 'tile' module in CVS.
A prebundled tarball is available in the file release area:

    <URL: http://sourceforge.net/project/showfiles.php?group_id=11464 >

Documentation is available here:

    <URL: http://tktable.sourceforge.net/tile/doc/ >

Precompiled libraries for Windows may also be present;
check for availability.

Re: [Tile-dev] Aqua 'Toolbar' frame style and nested widget background shading

[Vince D. <vin...@gm...>]

I suppose having transparent backgrounds as a default for all except
perhaps ttk::frames would be one solution.

On 4/7/06, Joe English <jen...@fl...> wrote:
> This is The Background Problem, and there's no easy fix
> on the horizon.

Is there any suggestion on the most palatable non-easy fix for the moment?

thanks,

Vince.

Re: [Tile-dev] Re: Changing default focus ring?

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

Paul Walton wrote:
> I suppose Tk was just slow at stretching the images.

I know of bugs in this area, one of which (in complexity recomputation)
ought to be fixed by the upcoming releases, and one of which (in
validity region recomputation) is still open, largely because the
changes needed are more complex than I've had time to tackle recently.
But you shouldn't hit that second problem as long as your images don't
have "holes" in them (i.e. no fully-transparent parts).

Donal.