tktable-tile-dev — Discussion about tile development

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

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

Vince Darley wrote:
>
> I've created a notebook widget, and made it's pages ttk::frames with
> -style Toolbar so they are the slightly lighter shade of aqua
> background.
>
> Now, what's the easiest way to make all nested widgets use the right
> styles so their backgrounds blend in with the lighter shading? The
> default obviously isn't good (all nested widgets have the darker aqua
> background).

This is The Background Problem, and there's no easy fix
on the horizon.

(The basic problem is that, in general, a widget's background
depends on the containing widget, but there's no good way yet
for the background element to locate this information.  There's
a similar issue with checkbuttons, radiobuttons, and labels inside
notebook widgets on Windows XP.)


--Joe English

  jen...@fl...

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

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

Can't seem to find any examples of this...

I've created a notebook widget, and made it's pages ttk::frames with
-style Toolbar so they are the slightly lighter shade of aqua
background.

Now, what's the easiest way to make all nested widgets use the right
styles so their backgrounds blend in with the lighter shading? The
default obviously isn't good (all nested widgets have the darker aqua
background).

thanks for any help,

Vince.

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

[Paul W. <wal...@gm...>]

I've fixed the problem.  Changing the focus ring images to a more reasonabl=
e
size like 10x10 did the trick.  I suppose Tk was just slow at stretching th=
e
images.  You could see it would take longer to display very wide buttons
than it would for smaller ones.

On 4/3/06, Paul Walton <wal...@gm...> wrote:
>
>  The theme I'm working on is a replica of Java Swing.  The highlight
> element would be perfect, except I need it be around the button label, as
> opposed to around the entire button.  As far as I can tell, this isn't
> possible with the highlight element.
>
> I was able to create the focus element using a 3x3 image with the middle
> pixel transparent.  The transparent part is stretched and so there is a o=
ne
> pixel border around the labels on buttons, checkbuttons, and radiobuttons=
.
> This works great except for one problem.  The problem is it is extremely
> slow to draw the widgets.  If I switch from a different theme to my theme=
,
> it takes 1-2 seconds to update all the widgets on the Tile demo.  The sam=
e
> thing happens if I just switch between windows.  This is on Windows XP wi=
th
> Tile 0.7.3.  Any idea why it is so slow?
>
> Here is the exact code I am using:
>
> style element create focus image $I(focusring-u) \
>   -border {1 1 1 1} \
>   -padding {1 1} \
>   -sticky nwse \
>   -map [list focus $I(focusring-f)]
>
> And here are the images:
> http://img448.imageshack.us/img448/5894/focusringu7tw.gif
> http://img448.imageshack.us/img448/4585/focusringf2uy.gif
>
> You should be able to just drop the code and images into the blue theme t=
o
> see the problem.
>
>
> >> Is there a way to change the focus ring to something different?  For
> >> instance, a solid blue ring?  I'm working on a theme that doesn't look
> right
> >> with the default dashed focus ring, so for now I've taken the ring out
> of
> >> all the buttons, but I'd like to implement a more appropiate focus
> indicator
> >> for this theme.  Is there any way to do it?
> >
> >Probably.  What theme is yours based on?
> >
> >The "highlight" element from the "classic" theme might do what
> >you want -- it just calls Tk_DrawFocusHighlight() with values
> >derived from the -highlightthickness and -highlightcolor
> >element options.
> >
> >You can import it into your theme with:
> >
> >    style element create highlight from classic
> >
> >and use it like:
> >
> >    style layout TButton {
> >    TButton.highlight -children { ... }
> >    }
> >    style default TButton -highlightthickness 1
> >    style map TButton -highlightcolor \
> >    [list focus $accentColor {} $frameColor]
> >
> >You could also change border colors (this is how
> >the 'clam' theme draws the focus ring for entry widgets,
> >for instance).  How to do this depends on which border
> >element you're using.
> >
> >
> >--JE
>
>

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

[Paul W. <wal...@gm...>]

The theme I'm working on is a replica of Java Swing.  The highlight element
would be perfect, except I need it be around the button label, as opposed t=
o
around the entire button.  As far as I can tell, this isn't possible with
the highlight element.

I was able to create the focus element using a 3x3 image with the middle
pixel transparent.  The transparent part is stretched and so there is a one
pixel border around the labels on buttons, checkbuttons, and radiobuttons.
This works great except for one problem.  The problem is it is extremely
slow to draw the widgets.  If I switch from a different theme to my theme,
it takes 1-2 seconds to update all the widgets on the Tile demo.  The same
thing happens if I just switch between windows.  This is on Windows XP with
Tile 0.7.3.  Any idea why it is so slow?

Here is the exact code I am using:

style element create focus image $I(focusring-u) \
  -border {1 1 1 1} \
  -padding {1 1} \
  -sticky nwse \
  -map [list focus $I(focusring-f)]

And here are the images:
http://img448.imageshack.us/img448/5894/focusringu7tw.gif
http://img448.imageshack.us/img448/4585/focusringf2uy.gif

You should be able to just drop the code and images into the blue theme to
see the problem.


>> Is there a way to change the focus ring to something different?  For
>> instance, a solid blue ring?  I'm working on a theme that doesn't look
right
>> with the default dashed focus ring, so for now I've taken the ring out o=
f
>> all the buttons, but I'd like to implement a more appropiate focus
indicator
>> for this theme.  Is there any way to do it?
>
>Probably.  What theme is yours based on?
>
>The "highlight" element from the "classic" theme might do what
>you want -- it just calls Tk_DrawFocusHighlight() with values
>derived from the -highlightthickness and -highlightcolor
>element options.
>
>You can import it into your theme with:
>
>    style element create highlight from classic
>
>and use it like:
>
>    style layout TButton {
>    TButton.highlight -children { ... }
>    }
>    style default TButton -highlightthickness 1
>    style map TButton -highlightcolor \
>    [list focus $accentColor {} $frameColor]
>
>You could also change border colors (this is how
>the 'clam' theme draws the focus ring for entry widgets,
>for instance).  How to do this depends on which border
>element you're using.
>
>
>--JE

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

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

Paul Walton wrote:

> Is there a way to change the focus ring to something different?  For
> instance, a solid blue ring?  I'm working on a theme that doesn't look right
> with the default dashed focus ring, so for now I've taken the ring out of
> all the buttons, but I'd like to implement a more appropiate focus indicator
> for this theme.  Is there any way to do it?

Probably.  What theme is yours based on?

The "highlight" element from the "classic" theme might do what
you want -- it just calls Tk_DrawFocusHighlight() with values 
derived from the -highlightthickness and -highlightcolor 
element options.

You can import it into your theme with:

    style element create highlight from classic

and use it like:

    style layout TButton { 
    	TButton.highlight -children { ... } 
    }
    style default TButton -highlightthickness 1 
    style map TButton -highlightcolor \
    	[list focus $accentColor {} $frameColor]

You could also change border colors (this is how
the 'clam' theme draws the focus ring for entry widgets,
for instance).  How to do this depends on which border
element you're using.


--JE

[Tile-dev] Changing default focus ring?

[Paul W. <wal...@gm...>]

Hi,

Is there a way to change the focus ring to something different?  For
instance, a solid blue ring?  I'm working on a theme that doesn't look righ=
t
with the default dashed focus ring, so for now I've taken the ring out of
all the buttons, but I'd like to implement a more appropiate focus indicato=
r
for this theme.  Is there any way to do it?

Paul

Re: [Tile-dev] OS X button layout too much space to left?

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

Vince Darley wrote:

> [Joe English]
> > This is probably coming from the focus ring.
> 
> Ah, that makes sense - I just wondered where it was coming from. But I
> thought Aqua buttons don't have focus rings? They just pulsate if they
> have the focus... Maybe I'm missing something.

The blue pulstating feedback indicates the default button,
not the one with keyboard focus.  

(The default button is the one that gets activated when 
you press <Return> in a dialog box, regardless of which 
widget has the focus.  In Tile and Tk, visual feedback 
for the default button is controlled by the "-default" 
option; and in Tile, 'keynav::defaultButton $b' adds
bindings to handle accelerators and traversal as well.)


--Joe

Re: [Tile-dev] os-X styling

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

Vince Darley wrote:
> > Here's how that feature works:
> > [snip]
> >
> >         style map My.TLabel -foreground [list #a3a3a3]
> >
> > (if you want the label to show 'disabled' feedback).
> 
> That gives me an error "State map must have an even number of
> elements".

Sorry, that should have been: '-foreground [list disabled #a3a3a3]'

[style map] takes an alternating list of option/statemap pairs;
each statemap is an alternating list of statespec/value pairs; 
and each statespec is a list of state flags optionally prefixed
with an exclamation point (see widget(n), section "WIDGET STATES").


--Joe English

Re: [Tile-dev] os-X styling

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

In my Coccinella I have got a couple of styles etc which perhaps can be useful:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/coccinella/coccinella/contrib/tileutils.tcl

Mats

Re: [Tile-dev] OS X button layout too much space to left?

[<gil...@gm...>]

Hello,

On 3/28/06, Vince Darley <vin...@gm...> wrote:
> > This is probably coming from the focus ring.
>
> Ah, that makes sense - I just wondered where it was coming from. But I
> thought Aqua buttons don't have focus rings? They just pulsate if they
> have the focus... Maybe I'm missing something.

When you enable full keyboard access to every UI element (through
Keyboard & Mouse in System Preferences if I remember correctly), the
focus ring also applies to buttons.

Gilles.

Re: [Tile-dev] os-X styling

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

By the way, I noticed a bug with the auto-dimming/enabling in a dialog
window (created with tk::unsupported::MacWindowStyle style $w
moveableDBoxProc). All the tile widgets dim nicely when the dialog
loses the focus, but then they never ever re-enable themselves when it
gets the focus back.

Vince.

RE: [Tile-dev] os-X styling

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

Vince Darley wrote:
> On 3/27/06, Jeff Hobbs <je...@ac...> wrote:
> > What you actually want is:
> >
> > style map Active.TLabel -foreground [list disabled #a3a3a3]
> 
> Ah, yes! That works wonderfully!
> 
> It seems I'm going to have to try to learn these magic 
> incantations. I'm guessing that the demos and library (and 
> this list) are the places to look, given the current lack of 
> documentation?

Yes, that's the best place to start.  Things like the Slim.Toolbutton
are pulled from my own code.  I do plan to update some docs, wiki
pages or other appropriate medium with lots of these tidbits before
we go beta with ttk, but I haven't had the time for it yet.

Jeff

Re: [Tile-dev] os-X styling

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

On 3/27/06, Jeff Hobbs <je...@ac...> wrote:
> What you actually want is:
>
> style map Active.TLabel -foreground [list disabled #a3a3a3]

Ah, yes! That works wonderfully!

It seems I'm going to have to try to learn these magic incantations.
I'm guessing that the demos and library (and this list) are the places
to look, given the current lack of documentation?

Thanks,

Vince.

Re: [Tile-dev] OS X button layout too much space to left?

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

On 3/27/06, Joe English <jen...@fl...> wrote:
> Depends on what you're really trying to do -- would a "small"
> or "mini" size Aqua button work (if it were available in Tile?)

In this case it wouldn't help (but it would in some others).

> In general, if you force a widget to be smaller than it wants to be,
> it's not going to look right.

Oh, I agree. This is a poor case really, but needed in some areas of
this application.

> You could try specifying a large negative padding, to allow the
> button text to extend outside the margins.

Ah, didn't know that was possible -- it works perfectly!

> > I also note that both buttons have a couple of pixels spare above the
> > button, which is surprising since the configuration options in this
> > artificial example aim to get rid of it!
>
> This is probably coming from the focus ring.

Ah, that makes sense - I just wondered where it was coming from. But I
thought Aqua buttons don't have focus rings? They just pulsate if they
have the focus... Maybe I'm missing something.

Thanks for the help -- definitely improving things here!

Vince.

Re: [Tile-dev] os-X styling

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

On 3/27/06, Joe English <jen...@fl...> wrote:
> Here's how that feature works:
> [snip]
>
>         style map My.TLabel -foreground [list #a3a3a3]
>
> (if you want the label to show 'disabled' feedback).

That gives me an error "State map must have an even number of
elements". If I use {-foreground #a3a3a3} I get no error, but I still
have a dimmed label.  All my playing around with the above options
fails to create a label which won't dim!

> Another approach (which might be more appropriate for your
> application, don't know) is to select one of the MacWindowStyles
> or window attributes that doesn't receive <Activate>/<Deactivate>
> events.

That sounds like a good approach in some instances, but not this one,
since under some circumstances the status bar in question needs to
become active for user input, so would need to accept events.

> > Second Q: is it possible to create the smaller, toolbar style
> > menubuttons in the Aqua style?
>
> You mean like these? http://developer.apple.com/documentation/UserExperie=
nce/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_3.html#//app=
le_ref/doc/uid/TP30000359-BAADHEBI [*]

Yes!

Vince.

RE: [Tile-dev] os-X styling

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

Vince Darley wrote:
> On 3/27/06, Jeff Hobbs <je...@ac...> wrote:
> > or to have a label that is
> > always black (on a case-by-base), do:
> >
> > style default Active.TLabel -foreground black
> > ttk::label -style Active.TLabel ...
> 
> That doesn't work for me -- the label still goes grey in the 
> background. Does it work for you?

My bad, this is unfortunately undocumented right now, and I was
fiddling with several things.  What you actually want is:

style map Active.TLabel -foreground [list disabled #a3a3a3]

You can actually find the defaults Joe referred to (if you want
to not guess the remainder above) with:

set defs [style map . -foreground]

> Wow! Magic.. that indeed is what I was after.  One minor 
> detail, the menubuttons I was after (as opposed to buttons) 
> on OS X have a little black triangle in the corner to 
> indicate that a menu will popup when you click on them.

Passing this on to Joe ... I think tile is just not drawing this,
and I'm not sure it should be a style config bit or what.

Jeff

Re: [Tile-dev] os-X styling

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

Thanks for the help -- few followup issues below!

On 3/27/06, Jeff Hobbs <je...@ac...> wrote:
> or to have a label that is
> always black (on a case-by-base), do:
>
> style default Active.TLabel -foreground black
> ttk::label -style Active.TLabel ...

That doesn't work for me -- the label still goes grey in the
background. Does it work for you?

> > Second Q: is it possible to create the smaller, toolbar style
> > menubuttons in the Aqua style?
>
> Like so?
>
> style default Slim.Toolbutton -padding 1
> ttk::button $w -style Slim.Toolbutton ...

Wow! Magic.. that indeed is what I was after.  One minor detail, the
menubuttons I was after (as opposed to buttons) on OS X have a little
black triangle in the corner to indicate that a menu will popup when
you click on them.

In fact I've just noticed in the Tile demo that this little triangle
is there for the non-tile menubutton and (delving into tk's source
code) the toolbar style is generated automatically in plain old TkAqua
(no tile) when a menubutton is compound.

One last question on this: each such Tile Toolbutton has an empty
margin outside the thin black border. In some MacOS X applications,
small toolbar buttons are arranged right next to each other, with
their black borders touching, and hence one would not want this empty
margin to appear. Is this possible with Tile?

regards,

Vince.

Re: [Tile-dev] OS X button layout too much space to left?

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

Vince Darley wrote:

> This simple script creates two buttons (one tk, one Tile), on TkAqua:
> 
> package require tile
> toplevel .tt -bg red
> button .tt.b -text "Cancel" -padx 0 -pady 0 -bd 0 -highlightthickness 0
> ttk::button .tt.b2 -text "Cancel" -padding {0 1 0 1}
> place .tt.b -x 50 -y 20 -width 63 -height 21
> place .tt.b2 -x 50 -y 50 -width 63 -height 21
>
> Despite both being the same size, the tile one leaves so much space to
> the left of the 'C' that there isn't enough room to fit in the whole
> text, and so the 'l' isn't drawn.
> 
> Any suggestions on how to fix this?

Depends on what you're really trying to do -- would a "small"
or "mini" size Aqua button work (if it were available in Tile?)

In general, if you force a widget to be smaller than it wants to be,
it's not going to look right.

In this case: the button element internal padding is derived by calling
GetThemeButtonContentBounds(), so that (hopefully!) the button text
doesn't extend outside the alloted area.

You could try specifying a large negative padding, to allow the
button text to extend outside the margins. 

> I also note that both buttons have a couple of pixels spare above the
> button, which is surprising since the configuration options in this
> artificial example aim to get rid of it!

This is probably coming from the focus ring.

Aqua "full-size" buttons are 20 pixels high, and the ttk::button
also includes space for the focus ring (by experimentation, an
extra two pixels on all sides).


--Joe English

  jen...@fl...

Re: [Tile-dev] os-X styling

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

Vince Darley wrote:

> I notice that the default bindings/style for a ttk::label have the
> text go grey when it is in the background. How can I create a new
> style to apply to a specific label to *not* have this happen just for
> the one label (it's a kind of status-bar with messages the user should
> always be able to read, even if a different window is frontmost).

Here's how that feature works:

    + When a toplevel is "activated" resp. "deactivated"
      (OSX terms -- roughly, "becomes frontmost" or "becomes not
      frontmost"), Tk sends an <Activate> resp. <Deactivate>
      pseudo-event to every subwindow of the toplevel.

    + Tile widgets respond to these events by toggling the
      TTK_STATE_BACKGROUND state flag.  (This is built into
      the widget framework, it's not controlled from scripted
      bindings).

    + aquaTheme.tcl defines a root style map:

    	style map "." \
	    -foreground [list  disabled "#a3a3a3"  background "#a3a3a3"]

      that applies to all styles in the absense of a more explicit
      style map.

The easiest way to turn it off is to override the map:

	style map My.TLabel -foreground [list]

or

	style map My.TLabel -foreground [list #a3a3a3]

(if you want the label to show 'disabled' feedback).

Another approach (which might be more appropriate for your
application, don't know) is to select one of the MacWindowStyles
or window attributes that doesn't receive <Activate>/<Deactivate>
events.

> Second Q: is it possible to create the smaller, toolbar style
> menubuttons in the Aqua style?

You mean like these?

    http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_3.html#//apple_ref/doc/uid/TP30000359-BAADHEBI [*]


Possible in 0.7 (I think), but not easy (I'm sure).

I'd planned to include support for many of the Aqua-specific
UI gizmos (bevel buttons, round buttons, small/medium/large variants
of various widget styles, etc. ...) sometime in the 0.8 release
timeframe.


--Joe English

  jen...@fl...

[*] That's "Apple Human Interface Guidelines", Part III "The
Aqua Interface", section "Controls", subsection "Selection
Controls", topic "Icon Buttons and Bevel Buttons With Pop-Up
Menus", in case the URL has gone stale.

RE: [Tile-dev] os-X styling

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

Vince Darley wrote:
> I notice that the default bindings/style for a ttk::label 
> have the text go grey when it is in the background. How can I 
> create a new style to apply to a specific label to *not* have 
> this happen just for the one label (it's a kind of status-bar 
> with messages the user should always be able to read, even if 
> a different window is frontmost).

This is something that only happens on Aqua, and what you are
working with is this:

style map . \
   -foreground [list  disabled "#a3a3a3"  background "#a3a3a3"] \
   -selectbackground [list background "#c3c3c3"  !focus "#c3c3c3"] \
   -selectforeground [list background "#a3a3a3"  !focus "#000000"] \
   ;

To get around this for your entire app, do:

style map . -foreground [list background black]

or just labels, replace '.' with TLabel, or to have a label that is
always black (on a case-by-base), do:

style default Active.TLabel -foreground black
ttk::label -style Active.TLabel ...

> Second Q: is it possible to create the smaller, toolbar style 
> menubuttons in the Aqua style?

Like so?

style default Slim.Toolbutton -padding 1
ttk::button $w -style Slim.Toolbutton ...

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

[Tile-dev] small winxp buttons

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

Here's a similar example to the TkAqua one, but where height is treated wei=
rdly:

toplevel .tt -bg red
button .tt.b -text "Cancel" -padx 0 -pady 0 -bd 0 -highlightthickness 0
ttk::button .tt.b2 -text Cancel -padding {0 0 0 0}

place .tt.b -x 50 -y 20 -width 63 -height 25
place .tt.b2 -x 50 -y 50 -width 63 -height 25
# all looks fine, with text vertically centered in the button,
# but, now reduce the height...

place .tt.b -x 50 -y 20 -width 63 -height 15
place .tt.b2 -x 50 -y 50 -width 63 -height 15

-

and the tile button no longer vertically centers its text. The text
has slipped towards the bottom of the widget even though there are a
few spare pixels above. Again this is an artificially extreme example,
but I do have an application where this occurs.

Vince.

[Tile-dev] OS X button layout too much space to left?

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

This simple script creates two buttons (one tk, one Tile), on TkAqua:

package require tile
toplevel .tt -bg red
button .tt.b -text "Cancel" -padx 0 -pady 0 -bd 0 -highlightthickness 0
ttk::button .tt.b2 -text "Cancel" -padding {0 1 0 1}
place .tt.b -x 50 -y 20 -width 63 -height 21
place .tt.b2 -x 50 -y 50 -width 63 -height 21

Despite both being the same size, the tile one leaves so much space to
the left of the 'C' that there isn't enough room to fit in the whole
text, and so the 'l' isn't drawn.

Any suggestions on how to fix this?

I also note that both buttons have a couple of pixels spare above the
button, which is surprising since the configuration options in this
artificial example aim to get rid of it!

cheers,

Vince.

[Tile-dev] os-X styling

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

I notice that the default bindings/style for a ttk::label have the
text go grey when it is in the background. How can I create a new
style to apply to a specific label to *not* have this happen just for
the one label (it's a kind of status-bar with messages the user should
always be able to read, even if a different window is frontmost).

Second Q: is it possible to create the smaller, toolbar style
menubuttons in the Aqua style?

thanks for any help,

Vince.

[Tile-dev] Call For Papers: 13th Annual Tcl/Tk Conference, Oct. 9-13, 2006

[<aku...@sh...>]

Tcl/Tk
 - radically simple
 - radically flexible
 - radically powerful

Announcing the 13th Annual Tcl/Tk Conference

October 9-13, 2006
Naperville, Illinois USA

Learn from the experts, share your experience - the annual Tcl/Tk
conference is your opportunity to engage with the Tcl/Tk core team and
your fellow peers.

The conference program will include:
  * Presentations and tutorials
  * The (Active)State of Tcl talk by Tcl/Tk release manager Jeff Hobbs
  * Birds of a Feather (BOF) sessions
  * Invited key-note talks
  * Discussion forums with the Tcl/Tk core team

Call For Papers

You are invited and indeed encouraged to submit proposals for
presentations and tutorials. The conference schedule will consist of two
days of tutorials (Monday - Tuesday) and 3 days for the main
conference (Wednesday - Friday).

The conference provides you an opportunity to report on original
research and applications of Tcl/Tk and related technology. The
audience will consist of practitioners and researchers who are
intermediate or experienced users of Tcl/Tk.  For this reason, reports
on experiences and applications should draw out lessons for other
Tcl/Tk developers.

Topics will include, but are not limited to:

  * Application of Tcl/Tk in industries as diverse as engineering,
      industrial controls, broadcasting, financial services,
      medical and electronic design
  * Networking with Tcl/Tk, including distributed applications and network
      management
  * New widgets and techniques for GUI design with Tk
  * Simulation and application steering with Tcl/Tk
  * Tcl/Tk on handheld and embedded devices
  * New Tcl extensions and add-ons, including Tcllib and Tklib
  * Tcl/Tk centric operating environments

Submission Guidelines

If you are interested in submitting a paper you should send an
abstract of about 100 words and a summary of maximum two pages. Omit
extraneous or redundant information. Length is not a direct factor in
judging the quality of the submission.

If submitting a tutorial proposal you should send an outline of the
tutorial and a brief biography, and clearly indicate whether the
tutorial is of half-day or full-day duration.

Send submissions as plain text to <tc...@tc...> no later than May
31, 2006.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

The program committee will review and evaluate papers according to
the following criteria:
  * Quantity and quality of novel content
  * Relevance and interest to the Tcl/Tk community
  * Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application.  Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread.  All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

Registration Information

More information on the conference will be available in Spring 2006 at
the conference web site (http://www.tcl.tk/community/tcl2006/) and
published on various Tcl/Tk related information channels.

To keep in touch with conference announcements and Tcl events in
general, subscribe to the tcl-announce list at:

   http://listserv.activestate.com/mailman/mysubs?show=announce

by entering your email and selecting Tcl-announce.

Conference Committee

Cyndy Lilagan     Eolas Technologies              Facilities Coordination
Clif Flynt        Noumena Corp                    General Chair
Steve Redler IV   SR Technology                   Program Chair
Steve Landers     Digital Smarties                Program Co-chair
Kevin Kenny       GE Global Research Center
Jeffrey Hobbs     ActiveState
Andreas Kupries   ActiveState
Mike Doyle        Eolas Technologies
Ron Fox           NSCL Michigan State University
Donal Fellows     University of Manchester
Gerald Lester     HMS Software
Larry Virden      Tcl FAQ Maintainer

Contact Information

tc...@tc...
http://www.tcl.tk/community/tcl2006/


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [Tile-dev] Editable Tree Widget?

[Brett S. <bre...@ya...>]

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

> 
> Joey Mukherjee asked:
> >
> > Is it possible to have a Tile tree widget where
> one could edit the
> > fields within it?   If Tile doesn't currently have
> this, is it planned?
> 
> Not at present.  Brett Schwarz recently mentioned on
> c.l.t. that he
> had some code to do this (Brett?  Is this publically
> available?),
> but Tile doesn't support it out-of-the-box right
> now.
> 

Sorry, I was going to follow up to this earlier, but
got side tracked.

I just posted some more earlier today on CLT:
http://tinyurl.com/f7som

its a brief outline of what I had to do.

> I don't have any immediate plans to add it, either,
> but here's
> how I see it working: first, a general-purpose
> "edit-in-place"
> utility that would create an entry widget, [place]
> it in
> an existing widget at a programmer-specified
> location, and
> eventually pass the edited value to a user-supplied
> callback
> (on <KeyPress-Return>, <FocusOut>, etc.)  Second,
> the ttk::treeview
> will need a [$tv bbox $item $column] method, to
> figure out where
> to place the entry widget.  And third, a new utility
> procedure like
> [ttk::treeview::editCell $tv $item $cell] that would
> glue the first
> two pieces together.  (This should probably have a
> callback option
> too; not sure yet.)  The application programmer can
> call this
> routine from widget bindings as appropriate for the
> application
> 

Actually, for now, I would be happy to take the bbox
method, to identify coords of the item in question
(per column too). If this was there, then the code I
worked up would be half the size most likely. Of
course I would rather have a full solution :) but
having the bbox would go a long way.

HTH,

    --brett

--brett

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com