Re: [Tile-dev] Tile-aware treectrl

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

Tim Baker wrote:

> I've been looking into a tile version of treectrl. Using treeview as
> a guide, I end up needing the following things exported:
>

Many of those are scheduled to be added to the stubs table
sometime later, but not all.

The Tile package can be broken up into roughly three subsystems:
the part that deals with defining elements and styles,
the part that deals with using elements and styles, and
the part that deals with defining widgets.

At present, only the first part is available in the stubs table --
just enough so that extensions can define new themes.

These are all part of the second subsystem:

> Ttk_CreateSublayout
> Ttk_DrawLayout
> Ttk_FreeLayout
> Ttk_LayoutFindNode
> Ttk_LayoutNodeInternalParcel
> Ttk_LayoutSize
> Ttk_PlaceLayout
> Ttk_RebindSublayout

I don't consider those fully cooked yet, which is
why they're not in the stubs table right now.
I can add them if you need them, but beware that
they'll be subject to change.

(An aside: this is why I consider it important that Ttk
in the core continues to export its own stubs table,
separate from Tk's.  If we have to support all the
stuff that's currently in there from now until 8.X is
end-of-lifed, the ttk::* widgets are never going to
get any better than they are right now.)


> RegisterWidget -> Ttk_RegisterWidget?
> TtkRedisplayWidget
> TtkResizeWidget
> TtkWidgetCgetCommand
> TtkWidgetConfigureCommand
> TtkWidgetInstateCommand
> ttkCoreOptionSpecs
> TtkWidgetDoLayout
> TtkWidgetGetLayout

These are all part of the third subsystem.  The widget framework
relies heavily on statically-defined tables of function pointers,
and isn't really amenable to stubification.

However, you don't need the widget framework to use
the rest of the theme engine; the traditional Tk facilities
will work just as well.  (Tile's widget framework just
makes things a bit easier is all.)


> Also, there should be some way for a widget to specify that it
> does not want to be double-buffered. For large-area widgets like
> treectrl it isn't very efficient (and treectrl already does
> double-buffering).  Also, on composited desktops (OSX, Vista)
> isn't every toplevel already double-buffered?

That isn't supported at the moment.  So far it hasn't
been necessary, since Tile seems fast enough even under
OSX (where things end up being *triple*-buffered).

If you're not using the widget framework, you can decide
whether or not to use double-buffering in the <Expose>
handler, as per usual.

> A [ttk::style names] command would be nice for getting the
> names of existing styles, like [ttk::style theme names] and
> [ttk::style element names].

In the works.


--Joe English

  jen...@fl...