There have been lots of Mega-widget libraries written at different points in time, and all of them have their merits. I am currently thinking of writing a new mega-widget library which would be a re-write of all the BWidget code into a SNIT framework. I think the BWidget widgets are great. I just think making them leaves something to be desired.
Does anyone think this is worth the time and effort?
How would you go about writing a new mega-widget library?
What widgets would you include?
My hope is that this discussion could bring about a mega-widget library (and possibly a framework) which could become the benchmark for Tk. I want this to be the widget library you can't live without (currently BWidget for me). How would you do it?
RS 2004-02-24 - First of all, "in contrast to Megahertz and Megabytes, a megawidget is not worth a million widgets". BWidget offers some popular things, like ComboBox, NoteBook etc., but custom "megawidgets" are often required. So make it easy on composing things - and best don't waste namespace names like BWidget does... For one-off usage, I often just pack or grid two or more things into a frame. Well, if it's the simplest thing that works...
DC 2004-02-25 - I don't see making a mega-widget framework without using namespaces. That's pretty much the clearest way to store information about a widget. And if it happens that we have a new namespace for each widget created, what's wrong with that? It will be destroyed when the widget is.
I did some preliminary testing by porting the BWidget ButtonBox to SNIT. The process was extremely painless, and I had the whole widget ported to a SNIT framework in about 10 minutes. This shows promise, as the whole BWidget library could be moved to SNIT with very little effort.
The only thing that might stop me is that when testing the two implementations, I found the BWidget actually faster. Not by much, but faster. About 500 microseconds per iteration faster. Anyone care to comment on that?
Bryan Oakley 2004-02-25 - if it were me, I'd not base the widgets on snit. Snit is wonderful, but I personally believe megawidgets would be more universally accepted if they didn't depend on an external library.
As for namespaces, I think there should be a single toplevel namespace (eg: ::megawidget) with additional namespaces below that (eg: ::megawidget::combobox, ::megawidget::notebook, etc). Why? Good top-level namespaces are already being used by some widgets, and placing them all under an umbrella namespace will limit name clashes.
I've also found it convenient to create a namespace per widget but that's just my coding style. I tend to write code like this (not exactly, but this captures the spirit):
proc mywidget {name args} {
namespace eval ::mywidget::instance::$name {
variable options
variable widgets
}
<create the widget...>
interp alias {} $name {} ::mywidget::proxy $name
}
proc ::mywidget::proxy {name command args} {
if {$command eq "configure"} {
eval ::mywidget::configure $name $args
}
}
proc ::mywidget::configure {name args} {
variable ::mywidget::instance::${name}::options
variable ::mywidget::instance::${name}::widgets
....
$widgets(frame) configure -background $options(-background)
....
}I don't know if that's the most efficient way, but it works well in practice and means I don't need a large object system.
And yes, I know that snit is a wonderful mechanism to implement all the details of namespaces, instance variables, etc. I still find standalone widgets preferable to something that has external dependencies on an object system I might not otherwise require.