DN589944225

Subject: POLL: BWidgets usage information - DN [1]

Eric Melski <ericm@nospam.scriptics.com> - 25 Feb 2000 - comp.lang.tcl

 (my apologies for the length of the post)

 We have been using BWidgets at Scriptics for several months
 now.  Connect, our flagship product, depends heavily on the
 megawidgets provided by BWidgets.  But we have run into a
 wall as far as the widget set goes:  though they are very
 full-featured, they are also rather slow.  On some of our more
 complex GUI's, the creation time of the BWidgets components
 accounts for a substantial portion of the total creation time.
 The net result is that for some windows the time to create is
 well past the "user tolerance threshhold."

 We have been considering ways to address the problem, in
 the course of which I have been studying the BWidgets
 megawidget infrastructure in detail.  After some experimentation,
 I found that be slightly altering some of the feature set, I could
 improve the loading time of some of our most heavily used widgets
 (SpinBox and ComboBox) by 30% or more.  I know that more
 improvement is possible, but it may require noticeable loss of
 backwards compatibility.

 For my own reference, I would like to know how many people
 would be significantly inconvenienced by the changes enumerated
 below.  The response I see may impact whether these modifications
 are a) made at all; b) made and given to the community as major
 revision to BWidgets (ie, v2.0 or some such); or c) made and given
 to the community as some new package (EWidgets ?).  Of course,
 any changes we make will be made available in some form, it's just
 a question of what the resulting package is called.

 The changes I've been experimenting with are:

 * changes to the option database/BWidgets interface.
 Currently it is possible to add default configuration options to
 a BWidget via the option database with this syntax:

 option add *BWIDGETCLASS.optionName $value widgetDefault

 Unfortunately, this causes, for every widget of type BWIDGETCLASS,
 many option database queries, and an inefficient processing thereof.  If

 we leverage the option database and instead require syntax like:

 option add *BWIDGETCLASS.subWidget.optionName $value widgetDefault

 We eliminate unneccesary option database queries/processing.  (Of
 course,  mega widget options that are new to the mega widget and do not
 map directly to a subWidget are still specified with the former syntax).

 So the question here is, do many people really use the option database
 with
 BWidgets?

 * Changes to the composition of some widgets
 Some widgets, such as the SpinBox and ComboBox, have the BWidget
 LabelFrame included in them.  The LabelFrame makes it easy to have a
 SpinBox with a label next to it, for example.  But the cost of creating
 this
 extra megawidget is significant -- the SpinBox could be created faster
 if
 the LabelFrame were not rolled into it.  Remember that you could still
 get
 the same behavior by explicitly creating the LabelFrame yourself, and
 putting the SpinBox inside it.  It just wouldn't be incorporated into
 the
 SpinBox megawidget itself.

 In my experience, the LabelFrame inside the megawidget is of fairly
 limited utility, because it's difficult to make multiple SpinBoxes with
 labels
 line up correctly unless the geometry management is performed outside of

 the SpinBox (ie, I do the gridding myself).  The LabelFrame prevents
 me from doing that, so I don't use it.  The question here is, do many
 people
 rely on this particular functionality, or could I reasonably remove it
 from the
 SpinBox?

 I apologize for the length of the post, but I appreciate any feedback.
 Again, whatever changes we make will be released (in fact, you can get
 to
 them via CVS right now anyway), but if people feel that the sorts of
 changes
 suggested here have too great an impact, we may change the package name.

 Thanks for your input,

 - eric