tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] require Tk before Tile

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

Christian Surlykke wrote:
>
> I'm running tcl8.5b3, tk8.5b3, tile-0.7.8 and tileqt0.4b1, compiled from
> sources.
>
> If I do:
>
>   package require Tk
>   package require tile
>   package require "tile::theme::tileqt"
>
> I get:
>
>   couldn't load
> file "/usr/local/lib/tileqt0.4/libtileqt0.4.so": /usr/local/lib/tileqt0.4/libtileqt0.4.so:
> undefined symbol: Ttk_RegisterElement

The Tcl API and C ABI for third-party themes
suffered a number of incompatible changes from
Tile 0.7.8 when it was integrated into the core.

>From the error message, it would appear that your copy
of Tile-QT was compiled without -DUSE_TTK_STUBS.
Try adding that, and compile against Tk 8.5 headers
instead of Tile 0.7.8 headers.

I'm sorry I don't have any further suggestions.
This aspect of TIP#248 was not well thought out.


--Joe English

  jen...@fl...

[Tile-dev] require Tk before Tile

[Christian S. <chr...@su...>]

Hi

I'm running tcl8.5b3, tk8.5b3, tile-0.7.8 and tileqt0.4b1, compiled from 
sources. 

If I do:

  package require Tk 
  package require tile
  package require "tile::theme::tileqt"

I get: 

  couldn't load 
file "/usr/local/lib/tileqt0.4/libtileqt0.4.so": /usr/local/lib/tileqt0.4/libtileqt0.4.so: 
undefined symbol: Ttk_RegisterElement

But if I do:

  package require tile
  package require Tk 
  package require "tile::theme::tileqt"

It works ok. 

Is this a bug or intentional?

(It's a bit of a problem for me because I use Tk from Ruby, and Ruby seems to 
load Tk before tile)

thanks

Christian Surlykke 
    

Re: [Tile-dev] Proposed ttk::dialog callback change

[Kevin P. <Kev...@Ap...>]

Yes, that will do nicely. Thanks for the post.

Kevin

On Sat, 2007-12-01 at 10:12 -0800, Joe English wrote:
> Kevin Partin wrote:
> 
> > Currently when the user presses a button on a ttk::dialog widget, the
> > widget is destroyed regardless of which button was invoked, and the
> > return status of the callback command.
> >
> > In terms of user feedback and interaction with the dialog widget,
> > wouldn't it be better if the command where executed before the dialog
> > widget is destroyed? The dialog widget could check the return status of
> > the command, and if it was zero, destroy the dialog. This way the
> > programmer has some control over when the dialog is destroyed.
> 
> The dialog will stay posted if the -command script returns
> a TCL_BREAK or TCL_CONTINUE return code.  Does that do
> what you want?
> 
> 
> --Joe English
> 
>   jen...@fl...
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
-- 
Kevin Partin
Applied Structural Dynamics, Inc.
(281) 286-8959

Re: [Tile-dev] Proposed ttk::dialog callback change

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

Kevin Partin wrote:

> Currently when the user presses a button on a ttk::dialog widget, the
> widget is destroyed regardless of which button was invoked, and the
> return status of the callback command.
>
> In terms of user feedback and interaction with the dialog widget,
> wouldn't it be better if the command where executed before the dialog
> widget is destroyed? The dialog widget could check the return status of
> the command, and if it was zero, destroy the dialog. This way the
> programmer has some control over when the dialog is destroyed.

The dialog will stay posted if the -command script returns
a TCL_BREAK or TCL_CONTINUE return code.  Does that do
what you want?


--Joe English

  jen...@fl...

Re: [Tile-dev] Proposed ttk::dialog callback change

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

Kevin Partin wrote:
> Currently when the user presses a button on a ttk::dialog widget, the
> widget is destroyed regardless of which button was invoked, and the
> return status of the callback command.
> 
> In terms of user feedback and interaction with the dialog widget,
> wouldn't it be better if the command where executed before the dialog
> widget is destroyed? The dialog widget could check the return status of
> the command, and if it was zero, destroy the dialog. This way the
> programmer has some control over when the dialog is destroyed. 
> 
> To accomplish this task now, I don't specify a '-command' option when I
> create the dialog, and configure the dialog button commands after the
> dialog is created.
> 
> Just a thought. I don't know if this topic has been previously
> discussed.

I agree, but this and other points is why ttk::dialog is not in 8.5 
core.  You can look at widget::dialog for ideas on how to handle the 
richer possible interactions with a dialog.  It is more of a replacement 
for a general dialog shell, whereas ttk::dialog tries to be a richer 
tk_dialog.

Jeff

[Tile-dev] Proposed ttk::dialog callback change

[Kevin P. <Kev...@Ap...>]

Currently when the user presses a button on a ttk::dialog widget, the
widget is destroyed regardless of which button was invoked, and the
return status of the callback command.

In terms of user feedback and interaction with the dialog widget,
wouldn't it be better if the command where executed before the dialog
widget is destroyed? The dialog widget could check the return status of
the command, and if it was zero, destroy the dialog. This way the
programmer has some control over when the dialog is destroyed. 

To accomplish this task now, I don't specify a '-command' option when I
create the dialog, and configure the dialog button commands after the
dialog is created.

Just a thought. I don't know if this topic has been previously
discussed.
-- 
Kevin Partin
Applied Structural Dynamics, Inc.
(281) 286-8959

Re: [Tile-dev] Standard Tk Widgets

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

Jeff Hobbs wrote:
>
> What is the latest status of border-draw handling specialization support
> in tile?  This would alleviate issues that users see on the text and
> listbox widgets related to specialized borders (like on the mac), when
> the widget has focus.  There was some hackery on the wiki, but it had
> some "issues" iirc.

Can't find the wiki page in question, but the basic approach --
use a ttk::frame configured to look like an entry widget and
arrange to keep the frame's 'focus' state bit in sync with
that of the wrapped widget -- mostly works.

The main problems with that technique that I'm aware of are
(in order of importance):

(1) The application has to ensure that the frame's -borderwidth
and/or -padding matches the size of the focus border for the
current theme.  There is no easy way to find out what this is,
so apps have to either choose an upper bound (3 pixels is appropriate)
or hardcode different values for each platform.

(2) Keeping the frame's focus bit in sync isn't terribly difficult,
but it would be better if Tile just made this happen automatically.

(3) "-style TEntry" isn't necessarily the right thing to use.
That happens to look OK under the current supported themes,
but that's by accident and not by design.


--Joe English

Re: [Tile-dev] Standard Tk Widgets

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

Jeff Hobbs wrote:
> What is the latest status of border-draw handling specialization support 
> in tile?  This would alleviate issues that users see on the text and 
> listbox widgets related to specialized borders (like on the mac), when 
> the widget has focus.  There was some hackery on the wiki, but it had 
> some "issues" iirc.

Curiously, Tk has some stuff relating to making borders work right (with
a canvas inside) for the Unix tk_getOpenFile implementation[*]. I've no
idea whether it's "right" (probably not actually) but it looks good with
themes like clam and xpnative. If the code's good enough, maybe it can
be split out and used more generally?

Donal.
[* The graphical file selector is a highly non-trivial megawidget, and
    it's going to be seen by a lot of people so putting effort in to make
    it look right and good is worthwhile. ]

Re: [Tile-dev] Standard Tk Widgets

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

Jeff Hobbs wrote:
> Joe English wrote:
>> There are no plans for a ttk::text widget.  The text widget
>> is massively complicated and would not benefit much from the
>> Tile framework: the only themable part is the border, and
>> it's mostly an "owner-draw" widget (which the framework isn't
>> very good at handling).  Reimplementing it doesn't seem
>> worth the effort.
> 
> What is the latest status of border-draw handling specialization support 
> in tile?  This would alleviate issues that users see on the text and 
> listbox widgets related to specialized borders (like on the mac), when 
> the widget has focus.  There was some hackery on the wiki, but it had 
> some "issues" iirc.
> 

I use the following which seems to work well...

# UI::Text --
# 
#       Faking Aqua text widget. Note that the container frame is returned.
#       From comp.lang.tcl Thank You!

proc ::UI::Text {w args} {
    
    if {[tk windowingsystem] eq "aqua"} {	
	set wcont [string range $w 0 [string last "." $w]]_cont
	ttk::frame $wcont -style TEntry
	eval {text $w -borderwidth 0 -highlightthickness 0} $args
	
	bind $w <FocusIn>  [list $wcont state focus]
	bind $w <FocusOut> [list $wcont state {!focus}]

	pack $w -in $wcont -padx 5 -pady 5 -fill both -expand 1
	return $wcont
    } else {
	eval $w $args
	return $w
    }
}

Re: [Tile-dev] Standard Tk Widgets

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

Joe English wrote:
> There are no plans for a ttk::text widget.  The text widget
> is massively complicated and would not benefit much from the
> Tile framework: the only themable part is the border, and
> it's mostly an "owner-draw" widget (which the framework isn't
> very good at handling).  Reimplementing it doesn't seem
> worth the effort.

What is the latest status of border-draw handling specialization support 
in tile?  This would alleviate issues that users see on the text and 
listbox widgets related to specialized borders (like on the mac), when 
the widget has focus.  There was some hackery on the wiki, but it had 
some "issues" iirc.

Jeff

Re: [Tile-dev] Standard Tk Widgets

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

Kevin Partin wrote:

> Are there any plans to add the remaining standard Tk widgets to Tile?
> Specifically, I'm interested in the text and spinbox widgets.

A ttk::spinbox is on the long-term TODO list.  Rough
plan is to try implementing it as a snidget first
(SNIT-based megawidget), since this would be a good
test case for other entry-like megawidgets.  Not
any time soon though; maybe in the Tk 8.6 / Tile 0.9
timeframe.

There are no plans for a ttk::text widget.  The text widget
is massively complicated and would not benefit much from the
Tile framework: the only themable part is the border, and
it's mostly an "owner-draw" widget (which the framework isn't
very good at handling).  Reimplementing it doesn't seem
worth the effort.


--Joe English

  jen...@fl...

[Tile-dev] Standard Tk Widgets

[Kevin P. <Kev...@Ap...>]

Are there any plans to add the remaining standard Tk widgets to Tile?
Specifically, I'm interested in the text and spinbox widgets. 

Kevin
-- 
Kevin Partin
Applied Structural Dynamics, Inc.
(281) 286-8959

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

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

Kevin Walzer wrote:

> Joe English wrote:
> > I finally managed to figure out how to draw 2003-era
> > "Panther"-style tabs on OSX.
> [...]
> I just updated to CVS HEAD of Tk and didn't see the new notebook
> tabs...has this been committed yet? I'm on 10.4.10.

No, I've been busy shaving yaks.  There's still a ways to go
before this works properly.

Some updates: Safari-style tabs don't appear to be available in
HITheme / Carbon, so Tile won't be able to do those.  However,
HIThemeDrawTab() still supports 10.2-style tabs, so those will
be available for the foreseeable future if you need them.



--Joe English

Re: [Tile-dev] Tree/tableview: box around highlighted item

[Kevin W. <kw...@co...>]

Joe English wrote:
> A couple of weeks ago, Kevin Walzer wrote:
>> Joe English wrote:
>>> That's the focus ring, and it's supposed to be a dotted line.
>>> Did something change in the OSX XLib emulation layer recently?
>>> I'm almost sure that this used to draw correctly.
>> It might be dotted--it's actually hard to tell when it's also surrounded
>> by the dark gray/blue selectbackground.
>>
>> However, it really shouldn't be there at all, at least on the Mac. I
>> can't speak to how Windows or X handles things, but native table and
>> treeviews under Aqua don't use focus rings. Focus is indicated by the
>> column header being highlighted in the Aqua-blue style.
> 
> 
> Argh, sorry, forgot all about this.  Anyway: (1) yes, that's
> the focus ring, (2) it is indeed drawn as a solid line on OSX
> instead of a dotted line as intended; and (3) it doesn't 
> belong there in the Aqua theme at all.
> 
> #3 fixed in CVS now; in the meantime you can use:
> 
>     style theme settings aqua {
> 	style layout Item {
> 	    Treeitem.padding -children {
> 	    	Treeitem.indicator -side left -sticky {}
> 		Treeitem.image -side left -sticky {}
> 		Treeitem.text -side left -sticky {}
> 	    }
> 	}
>     }
> 
> in your app to fix this for Tile 0.7.8 and earlier.
> 
> #2 still affects the other themes.  It's an Xlib emulation 
> layer glitch, not much can be done about it.  A similar
> problem is present on Windows, where the root theme "focus"
> element is drawn with dashed lines instead of dotted.
> 
> 
> --Joe English
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> 
> 
Just updated to HEAD 8.5--the widget now looks correct on OS X 10.4.10! 
Thank you.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

[Kevin W. <kw...@co...>]

Joe English wrote:
> I finally managed to figure out how to draw 2003-era
> "Panther"-style tabs on OSX.  See here for a snapshot
> of what's in my sandbox:
> 
>     http://tktable.sourceforge.net/tile/screenshots/new-tile-screenshot.png
> 
> The notebook widget still needs one more change to
> get the layout right (I thought I'd done this already,
> but apparently not...); this should end up in CVS
> in a couple of days, in time for the 8.5b3 release.
> 
> In related news, the ttk::combobox almost doesn't suck
> anymore on OSX either.  Those changes are already committed.
> 
> 
> --Joe English
>

I just updated to CVS HEAD of Tk and didn't see the new notebook 
tabs...has this been committed yet? I'm on 10.4.10.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [Tile-dev] Tree/tableview: box around highlighted item

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

A couple of weeks ago, Kevin Walzer wrote:
> Joe English wrote:
> > That's the focus ring, and it's supposed to be a dotted line.
> > Did something change in the OSX XLib emulation layer recently?
> > I'm almost sure that this used to draw correctly.
>
> It might be dotted--it's actually hard to tell when it's also surrounded
> by the dark gray/blue selectbackground.
>
> However, it really shouldn't be there at all, at least on the Mac. I
> can't speak to how Windows or X handles things, but native table and
> treeviews under Aqua don't use focus rings. Focus is indicated by the
> column header being highlighted in the Aqua-blue style.


Argh, sorry, forgot all about this.  Anyway: (1) yes, that's
the focus ring, (2) it is indeed drawn as a solid line on OSX
instead of a dotted line as intended; and (3) it doesn't 
belong there in the Aqua theme at all.

#3 fixed in CVS now; in the meantime you can use:

    style theme settings aqua {
	style layout Item {
	    Treeitem.padding -children {
	    	Treeitem.indicator -side left -sticky {}
		Treeitem.image -side left -sticky {}
		Treeitem.text -side left -sticky {}
	    }
	}
    }

in your app to fix this for Tile 0.7.8 and earlier.

#2 still affects the other themes.  It's an Xlib emulation 
layer glitch, not much can be done about it.  A similar
problem is present on Windows, where the root theme "focus"
element is drawn with dashed lines instead of dotted.


--Joe English

Re: [Tile-dev] Scrollbar with grip

[Schelte B. <sb...@wa...>]

On Wednesday 31 October 2007 01:34, Joe English wrote:
> Schelte Bron wrote:
> > I'm trying to create a scrollbar with a grip in the middle
> > of the thumb element. It looks exactly like I want when I
> > do: [... see below ...]
> > The problem however is that the grip part of the thumb does
> > not respond to thumb events, like dragging it with the
> > mouse. Is there any way of applying the thumb bindings to
> > the grip as well (something similar to bindtags)?
>
> That's what the (undocumented) "-unit" flag is for.
> (It was added to handle Windows XP scrollbar grips,
> which work the same way.)
>
Excellent! That provides exactly the behavior I was looking for.


Thanks,
Schelte.

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

[Will D. <Wil...@jp...>]

Cool!

Will

On Oct 30, 2007, at 5:02 PM, Joe English wrote:

>
> Will Duquette wrote:
>>
>> When you implement variant notebook styles, please include
>> an option of no tabs at all, like the BWidget PagesManager.
>> It's a need I run into regularly, and though the PagesManager
>> works OK it's annoying to have to use a megawidget when
>> ttk::notebook does everything right.  Also, with PagesManager
>> there's a call you have to make after all of the pages are
>> defined so that it can compute the maximum size of any page;
>> ttk::notebook just does this right, with no fuss.
>>
>> I asked for this once before, and you declined, saying it
>> was easy enough to do in Tcl, which it is; but it's one of
>> those things that has to be done exactly right.  I think
>> we'd get better GOOBE if ttk::notebook simply provided the
>> behavior.
>
> BTW, ttk::notebook has been able to do this since around 0.7.6:
> you can now say:
>
>     style theme settings default {
> 	style layout Plain.TNotebook.Tab null
>     }
>
> and a [ttk::notebook] with -style Plain.TNotebook won't
> show any tabs.
>
> See also:
>
>     <URL: http://www.flightlab.com/~joe/repos/themebag/groupbox.tcl >
>
> for a Snit megawidget that implements an Aqua-style "group box"
> (that's like a notebook controlled by a menubutton), which uses
> this technique.
>
> --Joe English
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

------------------------------------------------------------------------
Will Duquette, JPL  | Wil...@jp...
JNEM Dev Lead       | http://eis.jpl.nasa.gov/~will (JPL Use Only)
                     | It's amazing what you can do with the right  
tools.

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

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

Kevin Walzer wrote:

> Will these changes allow Tk to be built for 64-bit on OS X?  I know that
> Carbon's GUI bits are 32-bit only, but I'm not sure about CG (its
> connection to Carbon is a bit hazy to me).

I don't know, but probably not.

The relevant interface is "HITheme", which AIUI is part of "Carbon".

--JE

Re: [Tile-dev] Scrollbar with grip

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

Schelte Bron wrote:

> I'm trying to create a scrollbar with a grip in the middle of
> the thumb element. It looks exactly like I want when I do:
> [... see below ...]
> The problem however is that the grip part of the thumb does not
> respond to thumb events, like dragging it with the mouse. Is
> there any way of applying the thumb bindings to the grip as
> well (something similar to bindtags)?

That's what the (undocumented) "-unit" flag is for.
(It was added to handle Windows XP scrollbar grips,
which work the same way.)

A node with this flag set and all its descendants
are treated as a single element by [$w identify] and
the internal state-tracking logic.  So:

> ttk::style layout Vertical.TScrollbar {
>   Vertical.Scrollbar.uparrow -side top -sticky {}
>   Vertical.Scrollbar.downarrow -side bottom -sticky {}
>   Vertical.Scrollbar.trough -sticky ns -children {
>     Vertical.Scrollbar.thumb -expand 1 -sticky nswe -unit 1 -children {
                                                      ^^^^^^^ add this
>       Vertical.Scrollbar.grip -sticky {}
>     }
>   }
> }

should do the trick.

> I think such a feature would (or could
> be used to) solve the problem reported in bug #1574874 too.

The current semantics of "-unit" aren't quite right to
fix that problem, but I think with a small change they
might be.


--JE

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

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

Michael Kirkham wrote:
> > [Joe English]
> > Out-of-the-box, not initially, but if you want an old-style
> > notebook it will be possible to assemble one yourself by
> > importing elements from other themes (e.g., [style element
> > create Oldstyle.TNotebook.tab from aqua Notebook.tab] --
> > at least, that is, until Apple kills off QuickDraw).
>
> I guess we won't be upgrading until it is, then.  This style is definitely
> not the right thing in many cases whereas the old style is at least
> passable for static tab sets.

The old style will still be available, just not as a predefined, 
built-in style.  It won't be hard to get it back if you need it.

I'm reluctant to add *any* predefined custom styles right now:
any design mistakes that get into Tk 8.5 are essentially carved
in stone due to the core's backward-compatibility policies,
and this is an area of Tile that's still beta-bordering-on-alpha.


--Joe English

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

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

Will Duquette wrote:
>
> When you implement variant notebook styles, please include
> an option of no tabs at all, like the BWidget PagesManager.
> It's a need I run into regularly, and though the PagesManager
> works OK it's annoying to have to use a megawidget when
> ttk::notebook does everything right.  Also, with PagesManager
> there's a call you have to make after all of the pages are
> defined so that it can compute the maximum size of any page;
> ttk::notebook just does this right, with no fuss.
>
> I asked for this once before, and you declined, saying it
> was easy enough to do in Tcl, which it is; but it's one of
> those things that has to be done exactly right.  I think
> we'd get better GOOBE if ttk::notebook simply provided the
> behavior.

BTW, ttk::notebook has been able to do this since around 0.7.6:
you can now say:

    style theme settings default {
	style layout Plain.TNotebook.Tab null
    }

and a [ttk::notebook] with -style Plain.TNotebook won't
show any tabs.

See also:

    <URL: http://www.flightlab.com/~joe/repos/themebag/groupbox.tcl >

for a Snit megawidget that implements an Aqua-style "group box"
(that's like a notebook controlled by a menubutton), which uses
this technique.

--Joe English

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

[Kevin W. <kw...@co...>]

Joe English wrote:
> 
> Tile will use "hitheme" as the default theme if it's available,
> otherwise fall back to "aqua" (which should only happen on OSX 10.2).
> 
> The current plan is to keep all the QuickDraw/Appearance Manager
> code in the "aqua" theme and use (only) Quartz/HITheme APIs in
> "hitheme".  Initially "hitheme" will just contain elements that
> can *only* be implemented with CG, and inherit the rest from "aqua".
> We can reimplement the other elements at leisure, and hopefully end up
> with a self-contained, all-CG native theme by the time Apple
> decides to kill off QuickDraw entirely.
>

Will these changes allow Tk to be built for 64-bit on OS X? I know that 
Carbon's GUI bits are 32-bit only, but I'm not sure about CG (its 
connection to Carbon is a bit hazy to me).
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Tile-dev] Scrollbar with grip

[Schelte B. <sb...@wa...>]

I'm trying to create a scrollbar with a grip in the middle of 
the thumb element. It looks exactly like I want when I do:

ttk::style layout Vertical.TScrollbar {
  Vertical.Scrollbar.uparrow -side top -sticky {}
  Vertical.Scrollbar.downarrow -side bottom -sticky {}
  Vertical.Scrollbar.trough -sticky ns -children {
    Vertical.Scrollbar.thumb -expand 1 -sticky nswe -children {
      Vertical.Scrollbar.grip -sticky {}
    }
  }
}

The problem however is that the grip part of the thumb does not 
respond to thumb events, like dragging it with the mouse. Is 
there any way of applying the thumb bindings to the grip as 
well (something similar to bindtags)?

I don't know anything about the inner workings of the code that 
builds the widgets, but would it cause problems in any area if 
children would not mask the bindings of their parents (or would 
inherit their bindings)? I think such a feature would (or could 
be used to) solve the problem reported in bug #1574874 too.


Schelte.

Re: [Tile-dev] Breakthrough! Proper tabs on OSX!

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

On Tue, 30 Oct 2007, Joe English wrote:

> Date: Tue, 30 Oct 2007 09:35:44 -0700
> From: Joe English <jen...@fl...>
> To: tkt...@li...
> Subject: Re: [Tile-dev] Breakthrough! Proper tabs on OSX!
> 
>
> Michael Kirkham wrote:
>>
>> Will that be optional?  IMHO I see the styles being useful for different
>> things (i.e., the old format where tabs are not static, new style for
>> static tabs--think web browser vs. options dialog).
>
> Out-of-the-box, not initially, but if you want an old-style
> notebook it will be possible to assemble one yourself by
> importing elements from other themes (e.g., [style element
> create Oldstyle.TNotebook.tab from aqua Notebook.tab] --
> at least, that is, until Apple kills off QuickDraw).

I guess we won't be upgrading until it is, then.  This style is definitely 
not the right thing in many cases whereas the old style is at least 
passable for static tab sets.

>
> Built-in variant notebook styles are on the TODO list
> for Tile 0.9.*; this should include general-purpose styles
> like left/right/bottom tabs, and platform-specific styles
> like the Safari-style tabs Gerald mentioned.
>
>
> --Joe English
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>