tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Editable Tree Widget?

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

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.

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

If there's a one-size-fits-all solution that works for all use
cases, this might be promoted to a treeview widget instance method
like the BWidget Tree widget has, but probably not.

--JE

[Tile-dev] Editable Tree Widget?

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

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?

Ideally, I'd like to set up a tree widget the way Qt Designer has a 
tree widget for editing each of the option in their GUI if anyone is 
familiar with that.  It has a tree where you can click on the field and 
start typing, or click on the button next to it where a specialized 
editor appears.

Thanks for any ideas!

Joey

Re: [Tile-dev] Solid border frame

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

Joe English wrote:
> Mats Bengtsson wrote:
>> I'm trying to make a solid border frame that is so frequently used on Aqua
>>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> but it always get black. [...]
> 
> Do you have any screenshots demonstrating the border style you're
> looking for?  (Or better yet, the name of the Appearance Manager
> API routine used to draw them? :-)
> 

Just found two candidates. Not tested what they do though.

extern OSStatus
DrawThemeEditTextFrame(
   const Rect *     inRect,
   ThemeDrawState   inState)

extern OSStatus
DrawThemeListBoxFrame(
   const Rect *     inRect,
   ThemeDrawState   inState)

Mats

Re: [Tile-dev] Solid border frame

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

Joe English wrote:
> Mats Bengtsson wrote:
>> I'm trying to make a solid border frame that is so frequently used on Aqua
>>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> but it always get black. [...]
> 
> Do you have any screenshots demonstrating the border style you're
> looking for?  (Or better yet, the name of the Appearance Manager
> API routine used to draw them? :-)
> 

Attached a few shots from various apps. Hope they make it to the mail list.
There is a further problem since they are usually not drawn on all four 
sides.
Perhaps a -borderwidth using the same syntax as -padding.
If you zoom in on Apples own list widget you see the lines overlap in 
the corners.

I guess that many of these borders belong to the widgets itself. 
Appearence.h:

   /*
    * The number of pixels that the list box frame is outset from the
    * content of the list box.
    */
   kThemeMetricListBoxFrameOutset = 6,

> I can't find any Aqua apps or controls that have "solid"
> (in the Tk/Motif sense) borders; most use rounded corners,
> or in some cases solid horizontal separators.
> 
I don't believe that separators are used.

> 
>> What is wrong with:
>> 	style layout BorderFrame {
>> 	    BorderFrame.border -sticky nswe
>> 	}
>> 	style configure BorderFrame  \
>> 	  -relief solid -borderwidth 1 -background gray50
> 
> The Tile Aqua theme inherits the default *.border element,
> which in turn just calls Tk_Draw3DBorder, where the border color
> for TK_RELIEF_SOLID is hardcoded to black.  But I've got more border 
> styles than you can shake a stick at over in the half-bakery [*], 
> one of them will probably work.
> 

Idioms wont be understood by non native speaking...
I hope it was funny ;-)

Mats

Re: [Tile-dev] Solid border frame

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

Mats Bengtsson wrote:
>
> I'm trying to make a solid border frame that is so frequently used on Aqua
>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
> but it always get black. [...]

Do you have any screenshots demonstrating the border style you're
looking for?  (Or better yet, the name of the Appearance Manager
API routine used to draw them? :-)

I can't find any Aqua apps or controls that have "solid"
(in the Tk/Motif sense) borders; most use rounded corners,
or in some cases solid horizontal separators.


> What is wrong with:
> 	style layout BorderFrame {
> 	    BorderFrame.border -sticky nswe
> 	}
> 	style configure BorderFrame  \
> 	  -relief solid -borderwidth 1 -background gray50

The Tile Aqua theme inherits the default *.border element,
which in turn just calls Tk_Draw3DBorder, where the border color
for TK_RELIEF_SOLID is hardcoded to black.  But I've got more border 
styles than you can shake a stick at over in the half-bakery [*], 
one of them will probably work.



--Joe English

  jen...@fl...

[*] <URL: http://www.flightlab.com/~joe/repos/themebag/ >

[Tile-dev] Solid border frame

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

I'm trying to make a solid border frame that is so frequently used on Aqua
but it always get black. What is wrong with:

	style layout BorderFrame {
	    BorderFrame.border -sticky nswe
	}
	style configure BorderFrame  \
	  -relief solid -borderwidth 1 -background gray50

TkAqua 8.4.9 and tile 0.7.5
On my linux box (clam theme) it doesn't draw any border at all,
but if specify -padding it draws the padded area gray.

Mats

Re: [Tile-dev] RE: scrolledw + :ttk::frame

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

Joe English wrote:
> Just checked in some code that handles -relief solid on Windows,
> this works better now.  Right now you still always get a 2-pixel
> border regardless of -borderwidth; I've got an idea for how to make
> -borderwidth 1 and -borderwidth 0 work too.

Thanks.  FWIW, I only need 1 or 0 in my apps (where "my" ==
the combobox and like widgets, so it's pretty common).

> But I'm puzzled that -relief sunken doesn't look right --
> the ttk::frame should be doing exactly the right thing here
> (where "right" == "like other Windows 2K apps").

I have no problem with the slightly different look - it may
be "more" correct in fact.  I wouldn't worry about that, or
spend any time changing it, unless it effects something else.

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

Re: [Tile-dev] RE: scrolledw + :ttk::frame

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

Jeff Hobbs wrote:

> OK, it seems like this may be something that themed widgets may
> simply not be able to handle.  Let me elaborate on what I use
> the frame for commonly in tklib's widget package.
>
> Frames are the best containers for megawidgets.  In general,
> they are merely containers and are completely covered, but
> sometimes they have parts exposed (as in the scrolledwindow
> example when both scrollbars are visible).  Thus it would be
> nice to have themed frames.
>
> In the scrolledwindow though, it is common to want the
> megawidget have the inset border so the widget and scrollbar
> appear as one.  Thus you want the -bd/-relief on the frame
> (sunken or solid, 1 pixel usually), not the interior widget.

OK, good use case.  This is something the ttk::frame ought
to support.  

But there's a lot of platform variation that isn't accounted
for by -relief and -borderwidth alone.  On Windows, you
get slightly different borders with DrawFrameControl() than
you do with DrawEdge().  The former is used for things like
pushbuttons, the latter for editable fields and other things,
including most scrolled windows.

You can see the difference between the two if you compare
a ttk::entry with a core entry in the "winnative" theme --
Tk_Draw3DBorder on Windows draws (something similar to)
a DrawFrameControl-style border, which doesn't look quite
right for entry widgets.  Also compare ttk::button borders
with ttk::entry borders in the Tile "alt" theme, there's
a similar difference there (though the "alt" theme uses
3-color borders, and Windows post-98 uses 4-color borders).
Under Luna, editable fields use a 1-pixel thick solid border
instead of the 2-pixel 3-D sunken border, and under Aqua, 
things get even fuzzier (literally).

Borders are a lot more complicated than they look :-(

> This doesn't work with ttk::frame, at least not the XP theme.
> Solid relief isn't supported at all, and sunken just isn't
> "right".  I'm not sure how important it is to get this part
> working though.

Just checked in some code that handles -relief solid on Windows,
this works better now.  Right now you still always get a 2-pixel
border regardless of -borderwidth; I've got an idea for how to make
-borderwidth 1 and -borderwidth 0 work too.

But I'm puzzled that -relief sunken doesn't look right --
the ttk::frame should be doing exactly the right thing here
(where "right" == "like other Windows 2K apps").


--Joe English

  jen...@fl...

[Tile-dev] RE: scrolledw + :ttk::frame

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

Joe English wrote:
> Jeff Hobbs wrote:
> > I looked into the ttk::frame usage for the tklib widget package, but 
> > it's handling of -borderwidth / -relief is not consistent with 
> > tk::frame's.  It appears to be locked at 1/2 pixels, based on -relief, 
> > with -borderwidth essentially ignored.

> The current policy (which is not entirely satisfactory) is:
> (1) the ttk::frame widget honors any user-specified 
> -borderwidth when computing internal padding, but (2) the 
> Frame.border element may draw a thinner border if necessary.  
> Also, (3) the Frame.border element should make a best-effort 
> attempt to honor -relief, but it's allowed to substitute a 
> "morally equivalent" border in case the Motif style is 
> visually incompatible with the rest of the theme.
	...
> with an arbitrary thickness.  (For example, the Win32 
> DrawEdge() routine draws borders that are SM_C[XY]EDGE pixels 
> thick -- the caller doesn't have any say in the matter.)  Hence #2.

OK, it seems like this may be something that themed widgets may
simply not be able to handle.  Let me elaborate on what I use
the frame for commonly in tklib's widget package.

Frames are the best containers for megawidgets.  In general,
they are merely containers and are completely covered, but
sometimes they have parts exposed (as in the scrolledwindow
example when both scrollbars are visible).  Thus it would be
nice to have themed frames.

In the scrolledwindow though, it is common to want the
megawidget have the inset border so the widget and scrollbar
appear as one.  Thus you want the -bd/-relief on the frame
(sunken or solid, 1 pixel usually), not the interior widget.
This doesn't work with ttk::frame, at least not the XP theme.
Solid relief isn't supported at all, and sunken just isn't
"right".  I'm not sure how important it is to get this part
working though.

Jeff

Re: [Tile-dev] Upcoming treeview changes

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

Jeff Hobbs wrote:
> OK, that made sense ... but why not just add -selectmode?
> Are you expecting users to really want something besides the
> standard 4 modes?

Seconded. The -selectmode option is well established in Tk and works
well enough, so it's not clear that there's a good reason to invent a
new mechanism for Ttk. Of course, if there's truly a new mode out there,
then perhaps it is best added to all widgets anyway. :-)

Donal.

Re: [Tile-dev] Upcoming treeview changes

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

Joe English wrote:
> Summarizing: clicking on an item in a treeview widget will
> no longer select that item unless the application explicitly
> says so.  Convenience routines will be provided to enable
> commonly-used selection modes.  This only affects the default
> Treeview widget class bindings.
> 
> Make sense now?

OK, that made sense ... but why not just add -selectmode?
Are you expecting users to really want something besides the
standard 4 modes?

Jeff

Re: [Tile-dev] Upcoming treeview changes

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

Jeff Hobbs wrote:

> You mean not having a 'selection' subcommand?!?!  That doesn't
> seem like a good idea to me.  All widgets must have that
> basic level of control, and I don't see how you'd implement
> your select modes without it yourself.

I'm apparently not explaining myself very well :-)

Let me try again:


Right now, the ttk::treeview widget uses something similar
to the listbox "extended" selection mode:

    <ButtonPress-1>:
    	Sets the selection and focus.

    <Shift-ButtonPress-1>:
    	Extends the selection ("addition" mode)

    <Control-ButtonPress-1>:
    	Toggle the selected state of the identified item.


This behavior is built in to the Treeview class bindings.
The built-in behavior is not always suitable.  It is
currently very difficult for an application to change
the built-in behavior.

Proposed change:  The built-in Treeview class bindings will
no longer include that behavior.  Applications will be able
to explicitly enable it by calling:

	ttk::treeview::selectMode $tv multiple

Other selection models will be provided, including "single",
"extended", and possibly others.  Applications will be able
to explicitly enable those behaviors instead by calling:

	ttk::treeview::selectMode $tv $othermode

If an application does not explicitly enable a selection mode for
a particular ttk::treeview widget, it will act like the BWidget Tree.
That is: none of the built-in Treeview class bindings will cause
items to be added or removed from the selection.  Applications
can add their own widget bindings for selecting and deselecting items
(like with the BWidget Tree), or, as above, they can enable
one of the predefined selection modes with [ttk::treeview::selectMode]

The implementation of [ttk::treeview::selectMode $tv] will involve
modifying $tv's bindtags.  This will make it easier for applications
to define their own selection modes as well.

The proposed change only affects the Treeview widget class bindings.
No widget commands will be harmed in the making of this change.
(Except for [$tv identify], which deserves it, since it's really
horrible.)

Summarizing: clicking on an item in a treeview widget will
no longer select that item unless the application explicitly
says so.  Convenience routines will be provided to enable
commonly-used selection modes.  This only affects the default
Treeview widget class bindings.

Make sense now?


--Joe

Re: [Tile-dev] Upcoming treeview changes

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

Joe English wrote:
> Jeff Hobbs wrote:
>> While I agree with using listbox style select modes (which
>> tktable uses as well), what do you mean by behavior for
>> modifying the selection?  Like a double-click to edit mode?
> 
> No, just changing the selected/deselected state of tree items.

You mean not having a 'selection' subcommand?!?!  That doesn't
seem like a good idea to me.  All widgets must have that
basic level of control, and I don't see how you'd implement
your select modes without it yourself.

Jeff

Re: [Tile-dev] Upcoming treeview changes

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

Jeff Hobbs wrote:

> > [JE]:
> > |     pathname identify row _x_ _y_
> > |     pathname identify column _x_ _y_
> > [...]
>
> Is that the best alternate form though?  What if you want to
> know the row and column as an index?  You have to make 2
> calls.

From initial experiments, it seems to work pretty well.
Multiple entry points that each return a single value are easier 
to work with than a single call that returns multiple values and
having to extract the desired data from the result.

Maybe it's just in contrast with the old [$tv identify] form
(which is really, really horrible), but so far I've found it
pleasant to work with.

> While I agree with using listbox style select modes (which
> tktable uses as well), what do you mean by behavior for
> modifying the selection?  Like a double-click to edit mode?

No, just changing the selected/deselected state of tree items.
In-place editing is a nice idea, but out-of-scope for now.

> Another thing that BWidgets
> has that I've used before is -selectable for an item (like
> making root nodes not selectable).

A use case for this is #1328192 "disable item selectability",
where the tree shows files and directories; files should be
selectable, but directories should not.

The solution I had in mind for this was bindable tags: the
application could assign a 'file' tag to file items, a 'dir'
tag to directory items, use [ttk::treeview::selectMode $tv none]
and handle selection entirely in tag bindings:

    $tv tag bind file <ButtonPress-1> \
    	{ %W selection set [%W identify row %x %y] }

Since the 'dir' tag has no such binding, clicking on a directory
item wouldn't select it.

A per-item 'selectable' option is worth considering too;
need to investigate how that interacts with everything else.

(More on tags later...)


--Joe English

[Tile-dev] Re: scrolledw + :ttk::frame

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

[ CC: tktable-tile-dev, as this is probably of general interest ]

Jeff Hobbs wrote:
>
> I looked into the ttk::frame usage for the tklib widget package,
> but it's handling of -borderwidth / -relief is not consistent
> with tk::frame's.  It appears to be locked at 1/2 pixels, based
> on -relief, with -borderwidth essentially ignored.

[ Depends on the theme -- see below ]

> Joe - what is the intention with that support?  Steve was
> asking because I was avoiding using it due to lack of -bd
> support, but that was a problem in some megawidgets that expose
> the tk::frame background (like a scrolled window).

The -relief/-borderwidth issue is one of the areas where
8.4-compatibility and theme-appropriate appearance are
still fighting it out, with no clear winner as of yet.

The current policy (which is not entirely satisfactory) is:
(1) the ttk::frame widget honors any user-specified -borderwidth
when computing internal padding, but (2) the Frame.border
element may draw a thinner border if necessary.  Also, (3)
the Frame.border element should make a best-effort attempt to
honor -relief, but it's allowed to substitute a "morally
equivalent" border in case the Motif style is visually incompatible
with the rest of the theme.

Without #1, it's impossible for applications to reliably get
widget alignment right in complex layouts.  But on the other
hand, it's not always possible to draw an appropriate border
with an arbitrary thickness.  (For example, the Win32 DrawEdge()
routine draws borders that are SM_C[XY]EDGE pixels thick --
the caller doesn't have any say in the matter.)  Hence #2.

#3 is understandably controversial, and might be changed.
The original reason for this was that the ttk::labelframe
widget had a built-in default of '-relief groove' (for BWidget
compatibility); but on Windows XP and Aqua, you really, really
don't want labelframes with a grooved border.  Now that we've
abandoned all pretense of supporting the 'namespace import'
trick, labelframes can have a NULL default for -relief, and
#3 can probably be revisited.


--Joe English

  jen...@fl...

RE: [Tile-dev] Upcoming treeview changes

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

> First off: the syntax of the [$tv identify] command is
> being replaced with something more sensible.

> |     pathname identify row _x_ _y_
> |     pathname identify column _x_ _y_
> 
> More subcommands will be added as needed, these two seem
> to be the most useful.  The old, horrible, 4-argument form
> [$tv identify $x $y] will stick around for a while, but
> I hope to phase it out as soon as it's convenient to do so.

Is that the best alternate form though?  What if you want to
know the row and column as an index?  You have to make 2
calls.  What tktable does (which is by no means a clean API)
is '$table index $index ?row|col?', where a type specifier
comes last.  IIRC, I added that to maintain support for the
existing index command.  Also, $index is a single argument
that can be @$x,$y (which other Tk widgets are familiar
with), or special items like 'anchor', 'active', etc.

> So, new plan: The ttk::treeview's default bindings will not 
> include any behavior for modifying the selection (this is how 
> the BWidget Tree works).  There will be a small set of 
> predefined selection modes (to be determined, will probably 
> include 'single', 'multiple', and 'extended' a la the core 
> Listbox widget).  Selection modes can be activated with:
> 
>     ttk::treeview::selectMode $tv $mode
> 
> This procedure will (probably) be implemented by adjusting
> the widget's bindtags; I haven't worked out the details yet.

While I agree with using listbox style select modes (which
tktable uses as well), what do you mean by behavior for
modifying the selection?  Like a double-click to edit mode?
It seems reasonable to have the user be required to add
that binding, but BWidgets does have a command to make that
easy ($tree edit $node ...).  Another thing that BWidgets
has that I've used before is -selectable for an item (like
making root nodes not selectable).

Jeff

[Tile-dev] Upcoming treeview changes

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

First off: the syntax of the [$tv identify] command is
being replaced with something more sensible.

The new syntax is:

| pathname identify _component_ _x_ _y_
|     Returns a description of the specified component under the point given
|     by x and y, or the empty string if no such component is present at
|     that position. The following subcommands are supported:
|
|     pathname identify row _x_ _y_
| 	Returns the item ID of the item at position y.
|
|     pathname identify column _x_ _y_
| 	Returns the data column identifier of the cell at position x.
| 	The tree column has ID #0.


More subcommands will be added as needed, these two seem
to be the most useful.  The old, horrible, 4-argument form
[$tv identify $x $y] will stick around for a while, but
I hope to phase it out as soon as it's convenient to do so.

Next: the built-in selection behavior is only appropriate
for (at most) 75% of the typical use cases (see #1328192,
#1389202).  To make things worse, it's really, *really* hard
for applications to change things -- partly because [$tv identify]
is so horrible, but mostly because the selection logic
is tightly coupled to the rest of the bindings.

So, new plan: The ttk::treeview's default bindings will not
include any behavior for modifying the selection (this is
how the BWidget Tree works).  There will be a small set of
predefined selection modes (to be determined, will probably
include 'single', 'multiple', and 'extended' a la the core Listbox
widget).  Selection modes can be activated with:

    ttk::treeview::selectMode $tv $mode

This procedure will (probably) be implemented by adjusting
the widget's bindtags; I haven't worked out the details yet.

As a transition strategy, the default bindings will remain
as they are for the rest of the 0.7 series, and [ttk::treeview::selectMode]
will be available (initially) as a no-op.  Existing code
should add calls to [ttk::treeview::selectMode $tv multiple]
at their earliest convenience to ensure forward-compatibility
when 0.8 comes out.


Sound reasonable?  Any comments?


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile feedback

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

On Tue, 24 Jan 2006, Joe English wrote:

>> displayed) or the tab text (which will break because the application
>> is multilingual). I'm assuming that I could use the child pane
>> window,
>
> Yes, the child window names will work as tab identifiers.
>
>> except I don't see any way of retrieving it.
>
> This is a Frequently Asked Question, with a not very satisfactory
> answer :-(.  The canonical way to get the name of the currently-selected
> tab is [lindex [$nb tabs] [$nb index current]].
>
> There really ought to be a more straightforward way to access this.
> [$nb current] maybe?

Seems like the inverse of index would be reasonable.  i.e.,

[$nb index $window]

vs.

[$nb window $index]

Where either would take "current" as an argument, as index does now.


--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Tile feedback

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

Hi Joe,

Thanks for your prompt response ...

Even though we discussed it on the chat, I'll follow up to the list  
for the sake of posterity

On 25/01/2006, at 12:32 PM, Joe English wrote:
> Steve Landers wrote:
>
>> The main issue I've struck so far has been limitations with the
>> notebook widget.  Whilst I suspect that notebook can do everything I
>> want, I find it much less convenient to use than the BWidget  
>> notebook.

I
>> For example, BWidget NoteBook has a raisecmd option, that causes the
>> specified command to be run when a tab is raised.


> You can replace '-raisecmd' and '-leavecmd' with  ...
...
> a useful approach is to generate your own <<TabRaised>> virtual  
> events:
...
> If you need to generate <<TabLowered>> events too (-leavecmd),
> you'll need to keep track of the previous tab by hand.
> (But again, <Unmap> bindings might be what you want instead).
...

You've just confirmed what I am saying ... Tile can do the job but I  
need to do a bunch more work myself to make it happen.

As discussed, it could be due to an impedance mismatch between the  
virtual event approach and the callback approach used by other  
toolkits. If so, I see this as an artificial barrier to the adoption  
of Tile. Agreed, in a virgin environment it mightn't matter but it's  
a barrier given people's existing skills and investment in code.

Also, as discussed, I can see the two conflicting goals of Tile  
coming into play - theme support and a simpler API.

I came to Tile to get theme support but to get that I have to change  
my development style. That's OK if 1) my style is horribly wrong and  
2) the Tile approach implements an accepted best practice. But in the  
absence of any evidence to the contrary, I conclude that there is no  
one best practice and Tile merely implements your preferred style :)

Let's keep the discussion going - IMNSHO the subject is too important  
in the life of Tcl/Tk to not revisit it even though it is going over  
old ground.

>> except I don't see any way of retrieving it.
>
> This is a Frequently Asked Question, with a not very satisfactory
> answer :-(.  The canonical way to get the name of the currently- 
> selected
> tab is [lindex [$nb tabs] [$nb index current]].
>
> There really ought to be a more straightforward way to access this.
> [$nb current] maybe?

Sounds reasonable to me

Cheers

Steve

Re: [Tile-dev] Tile feedback

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

Steve Landers wrote:

> The main issue I've struck so far has been limitations with the
> notebook widget.  Whilst I suspect that notebook can do everything I
> want, I find it much less convenient to use than the BWidget notebook.
>
> For example, BWidget NoteBook has a raisecmd option, that causes the
> specified command to be run when a tab is raised.

We considered this issue earlier -- see the mailing list archives
for details if you're interested [1], relevant discussion was
between 2004-09-10 and 2004-09-13.  Summarizing:

You can replace '-raisecmd' and '-leavecmd' with <Map> and
<Unmap> bindings on the slave windows, or with a <<NotebookTabChanged>>
binding on the notebook.

With the first option, the binding scripts can fire for other
reasons besides tab selection (main window withdrawn, nested
notebooks, etc.).  This may or may not be what you want.

If you _don't_ want that, and there are heterogeneous -raisecmd's,
a useful approach is to generate your own <<TabRaised>> virtual
events:

    bind $nb <<NotebookTabChanged>> {
    	event generate [lindex [%W tabs] [%W index current]] <<TabRaised>>
    }

If you need to generate <<TabLowered>> events too (-leavecmd),
you'll need to keep track of the previous tab by hand.
(But again, <Unmap> bindings might be what you want instead).

Finally, if you're using -leavecmd to control whether the
tab should switch or not (that's the BWidget feature whereby
the user can select a new tab, and the application can say
"Oh no you don't!"), you're on your own; there's no easy
built-in support for this sort of thing.


> Also, it allows symbolic names for tabs. I use this extensively,
> [... example elided ... ]
> [...] I then have to discover which tab was raised.
> Sounds simple, but without symbolic names for tabs I can either use
> the numeric index (which will breaks because not all tabs are
> displayed) or the tab text (which will break because the application
> is multilingual). I'm assuming that I could use the child pane
> window,

Yes, the child window names will work as tab identifiers.

> except I don't see any way of retrieving it.

This is a Frequently Asked Question, with a not very satisfactory
answer :-(.  The canonical way to get the name of the currently-selected
tab is [lindex [$nb tabs] [$nb index current]].

There really ought to be a more straightforward way to access this.
[$nb current] maybe?


[1] http://sourceforge.net/mailarchive/forum.php?forum_id=42051&viewmonth=200409


--Joe English

  jen...@fl...

[Tile-dev] Tile feedback

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

hi Joe,

As discussed, attached is my feedback re the Tile notebook.

I've started moving an cross-platform / multi-lingual app to Tile and  
I wanted to give you some feedback re the highs and the lows that  
I've encountered, with the specific intent of helping make Tile reach  
it's obvious potential.

The application itself uses BWidgets + tablelist (plus optcl and a  
few other extensions).

Overall, the process has been relatively easy - largely because I use  
ActiveState's style package and therefore tend to not play around  
with widget options explicitly.

Getting BWidgets to play nicer with Tile was easy enough, thanks to  
Jeff's mods in the latest BWidgets

	package require BWidgets
	Widget::theme 1

Likewise, the newer versions of tablelist have some tile support

	package require tablelist_tile

The main issue I've struck so far has been limitations with the  
notebook widget.  Whilst I suspect that notebook can do everything I  
want, I find it much less convenient to use than the BWidget notebook.

For example, BWidget NoteBook has a raisecmd option, that causes the  
specified command to be run when a tab is raised. Also, it allows  
symbolic names for tabs. I use this extensively, and it is quite  
convenient to say something like
	
	$notebook insert end TabName -frame $frame -raisecmd [list raisecmd  
TabName]

where the raisecmd proc can then do whatever it needs to do for the  
current tab. Or I could have written it like

	$notebook insert end TabName -frame $frame -raisecmd raisecmd

and within raisecommand use "$notebook raised" to get the symbolic  
name of the currently raised tab.

I realise I can use the  <<NotebookTabChanged>>  virtual event, but  
it is nowhere near as convenient. Setting it up is easy enough ....

	   bind $notebook <<NotebookTabChanged>> raisecmd

But within raisecmd I then have to discover which tab was raised.  
Sounds simple, but without symbolic names for tabs I can either use  
the numeric index (which will breaks because not all tabs are  
displayed) or the tab text (which will break because the application  
is multilingual). I'm assuming that I could use the child pane  
window, except I don't see any way of retrieving it. For example

	$notebook tab current

returns

	-padding 0 -sticky nsew -state normal -text TabName -image {} - 
compound none -underline -1

In the end I worked around it by creating all the tabs I might need  
and leaving unused ones hidden - and then using numeric indices. A  
pain and the resulting application code is much more complicated than  
it needs to be.

I'm not even sure what the solution should be - a "-raisecmd" option,  
symbolic tab names, a way of passing the child pane window in the  
event binding, modify the "notebook select" command to return the  
selected tab if no index is specified, whatever. I just know that  
Tile notebook is good but could be much better with a little effort.

Now please don't think I'm saying that the Tile notebook is all bad -  
it isn't and I wouldn't have invested the time if I didn't think the  
end results justified it. But equally, please don't gloss over the  
issue either.  Leaving aside the pros/cons of the BWidget  
implementation - the authors clearly understood the requirements of  
application development and it would be a shame if Tile remains more  
difficult to use for the application programmer.

I realise that there are different ways of achieving the same  
outcome, but my concern is that issues like the above are an  
impediment to Tile realising it's potential.

Best regards

Steve

Re: [Tile-dev] Tile notebook vs. Bwidgets PagesManager

[Eric B. <be...@us...>]

I have recently coded a C version of PagesManager widget, also with a 
scrolledwindow widget and a scrollable frame.
If someone is interested to polish the code and put it either in Tk or 
Ttk, I can give the code.

Jeff Hobbs wrote:

>Will Duquette wrote:
>  
>
>>Is there any way to make the Tile notebook widget act like 
>>the Bwidgets PagesManager, i.e., can it be a tab-less 
>>notebook where the displayed pane is controlled solely by the 
>>application?
>>
>>I tried creating the tabs with "-style hidden", but that didn't work.
>>    
>>
>
>Currently this is not possible, although it is a desirable feature.
>
>Jeff
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Tktable-tile-dev mailing list
>Tkt...@li...
>https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>
>
>
>  
>

Re: [Tile-dev] Tile notebook vs. Bwidgets PagesManager

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
If you want a tabless notebook, use the panemanager and selectively
-hide 1 all panes except the one you want visible.<br>
<br>
-Brian<br>
<br>
Jeff Hobbs wrote:
<blockquote cite="mid0e3201c61636$11871bb0$876...@ac..."
 type="cite">
  <pre wrap="">Will Duquette wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Is there any way to make the Tile notebook widget act like 
the Bwidgets PagesManager, i.e., can it be a tab-less 
notebook where the displayed pane is controlled solely by the 
application?

I tried creating the tabs with "-style hidden", but that didn't work.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Currently this is not possible, although it is a desirable feature.

Jeff



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click">http://ads.osdn.com/?ad_id=7637&amp;alloc_id=16865&amp;op=click</a>
_______________________________________________
Tktable-tile-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tkt...@li...">Tkt...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev">https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev</a>

  </pre>
</blockquote>
</body>
</html>

RE: [Tile-dev] Tile notebook vs. Bwidgets PagesManager

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

Will Duquette wrote:
> Is there any way to make the Tile notebook widget act like 
> the Bwidgets PagesManager, i.e., can it be a tab-less 
> notebook where the displayed pane is controlled solely by the 
> application?
> 
> I tried creating the tabs with "-style hidden", but that didn't work.

Currently this is not possible, although it is a desirable feature.

Jeff

[Tile-dev] Tile notebook vs. Bwidgets PagesManager

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

Howdy!

Is there any way to make the Tile notebook widget act like the
Bwidgets PagesManager, i.e., can it be a tab-less notebook where
the displayed pane is controlled solely by the application?

I tried creating the tabs with "-style hidden", but that didn't work.

Thanks!

Will

------------------------------------------------------------------------
Will Duquette, JPL  | Wil...@jp...
But I speak only    | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself.         | It's amazing what you can do with the right tools.