[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LUObject revisited
- From: skaller <skaller@...>
- Date: 29 Jan 2005 01:42:16 +1100
On Fri, 2005-01-28 at 20:35, PA wrote:
> > Have you tried anything slightly 'bigger'?
>
> Hmmm... not sure what you mean by "bigger" in this context? Care to
> elaborate?
Sure -- I mean you have an example with one small class and
one derived class which looks nice... but have you tried to
build a larger system with say 20 or so classes in it?
I actually have an interesting OO design for a windowing system
I'd love to code again. It's called HWM for Hierarchical Window
Manager. The idea is to get rid of Mega-Widgets and those horrid
GUI design tools.
Instead, you have a collection of simpler windows organised using
a tree widget instead of a panel list of top level windows. One window
is the 'display'. Some windows are general purpose containers such
as vertical or horizontally paned windows or notebooks with tabs.
Others are application level widgets.
Using the tree widget you can regroup your application widgets
by moving one -- or a whole subtree -- into a different
container, you can iconise a group, delete a group,
or mutate a container from a vertical pane set to a notebook.
All this is done by the window manager, out of control
of the application --- the app sets up the initial
configuration but there is no need for any tearoffs,
special icons to reorganise things etc -- this is all
handled by the window manager.
The system also reflects changes done directly on the
windows, like an ordinary panel (iconising a group
of windows folds that branch of the tree widget)
The design uses three levels of objects. At the bottom level
you just have a graph/tree of abstract nodes which you
can reoganise by method calls. However the nodes are
all subclassed so they have behaviours appropriate to
what kind of container they are. (All windows are
containers .. if not, delegate to your parent).
The top level specialisation goes beyond the topological
structure and provides skins, etc to make the windows
look pretty.
There is also the special tree widget, which both reflects
programmer reconfigurations of the windows, and also
allows the user to click and drag to reconfigure.
My original implementation was in Tcl/Tk, but I switched
to iTcl because it had objects. Later I did it all
again in Python (but it didn't work so well because
Tkinter is fairly badly flawed). I also tried to figure
out how to do it in Java, since Java/Swing has a heap
of notification hooks and reflection, which are needed
by this design (but I couldn't figure out how to do it).
Lua would be perfect for this given an object system,
but the design does place considerable demands on
the OO'ness of that object system.
When I had it running on Unix I could
literally pick up a window and 'throw' it onto
my other box's screen with a flick of the wrist
using a drag'n'drop on the tree widget thing.
Could be a 'killer app' for Lua -- the idea is actually
quite similar to what you'd do in a game (only the
actors are windows instead of NPCs :)
--
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net