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?