Re: [Tile-dev] creating mega-entry (search) widgets?

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

Last week, Jeff Hobbs wrote:

> As promised, attached is a megawidget variant of Michael's SearchEntry.
>   It's for placement in my tklib widget package, so it uses that
> framework (which basically means it is a snidget).

A few notes:

In proc ::widget::createMenuEntryLayout, you have:

>     foreach theme [style theme names] {
>	[...]
> 	style theme settings $theme {
> 	    style layout MenuEntry { [...] }
> 	    style element create MenuEntry.icon image [...]
> 	}
>	[...]
>     }

It's not necessary to redefine the "MenuEntry" layout in every
available theme -- you can define it just once in the
"default" theme:

| style theme settings "default" {
|     style layout MenuEntry {
| 	Entry.field -children {
| 	    MenuEntry.icon -side left
| 	    Entry.padding -children { Entry.textarea }
| 	}
|     }
| }


and all other themes will inherit it.

Same goes for the MenuEntry.icon element -- you can use:

| style theme settings "default" {
|     style element create MenuEntry.icon image ::widget::img_menuentry
| }


and this will be automagically inherited too.


[ An aside: here, I'd recommend using a one-part name for the element --
  "menuEntryIcon" instead of "MenuEntry.icon" -- since that's less likely
  to run into conflicts if some other custom widget in some other theme
  defines its own "*.icon" element.  The full ramifications
  of the theme engine's current fallback/inheritance strategies
  are not entirely clear at present  :-( ]


The other style settings, OTOH --

| style configure MenuEntry -padding $pad
| style map MenuEntry -image [list disabled ::widget::img_menuentry]


*do* need to be respecified in each theme.  I don't have a good
solution for that.


[ Another aside: The current fallback/inheritance strategies
  seem to work pretty well for defining new themes, and work
  sort-of-OK for defining custom widgets, but if the application
  needs to support custom widgets *and* arbitrary themes, they don't
  work very well at all. ]


> The image isn't configurable ... it's easy if I allow it
> across all instances (modify the master image), but for each
> menuentry will be trickier.

I don't have a good solution for that, either :-(


I had some comments on the class bindings, but it looks like
most of those issues have been addressed in the tklib CVS version.


--Joe English

  jen...@fl...