TIP #180 [1] (Add a Megawidget Support Core Package) proposes improved support for Megawidgets, without attempting to be an OO system.
MSW Mind explaining how megawidgets differ in composition from objects ? Actually our (plain) widgets -are- objects (you create an instance and use an instance-command approach to talk to them, while the behaviour is defined inside the 'class') ...
It's my belief that if a given OO system happens to be perfect for Megawidgets, that's a happy coincidence, but I have a nagging suspicion that one of the historical reasons OO hasn't taken off in tcl is that it keeps getting confused with the needs of Megawidgets. If there was an excellent OO and an excellent Megawidget system, it wouldn't bother me as much as if one had to be distorted to suit the other. -- 4Dec04 CMcC
4Dec04 SRIV A question to those of you that have made OO or megawidget frameworks, is it possible to have a unified system that can create objects AND widgets AND types while maintaining the feel of tcl? Discuss..4Dec04 CMcC almost all of the well developed OO systems are extended to provide megawidgets, so I don't think you can answer your question before asking what 'maintaining the feel of tcl' means, and that's a very big question.The question, here, is about significant differences between what the perfect OO system needs, and what the perfect megawidget system needs. I think that question needs an answer before we can really talk about unification.2004-12-04 MSW For OO Systems, I think the answer is that the system should be flexible enough to allow mapping the different styles of OO thinking within the very same system (as e.g. OTcl / XOtcl do) -- kind of like said about Lisp at [2]. For Megawidget systems, what else is needed but being able to both use megawidgets the same as you do with plain widgets (create them, use a method like approach to access commands in the instances [ like for plain tk widgets ]) as well as being able to build bigger megawidgets with plain tcl code or OO code from existing mega- as well as plain widgets ?
Question by SRIV re-added by MSW:Another question: If I define a widget in a tcl OO system, why do I have to use the "method" keyword instead of proc? Can't it "do the right thing" and know that I'm defining a method and make it behave as such, without having to use a redundant keyword? The proc would be private to the widget/object, unless explicitly exported, as in namespaces.MSW answers: "method" (or "instproc" or whatever) is needed for the distinction of instance vs. class methods / state.
SRIV mentions that the nomenclature of OO systems (specifically method) can be intrustive if what you want to do is define a megawidget ... perhaps thinking of a name which is more connotatively consonant for a widget would emphasise some of the differences in thinking about megawidgets and conventional objects.MSW answers: why ? If you're defining megawidgets in an oo-system, why would you want to not use the oo-system to define the megawidget ?SRIV Because there is no official OO for tcl yet, so, why cant tcl's future OO be smarter than whats available today? I understand that conventional OO languages or tcl extensions "need" instproc or method, I'm just trying to get a consensus on whether a future tcl OO system can be made lighter, more coherent and more tk like.Either I, as a non-OO programmer other than tk, am oversimplifying OO, or OO programmers are blinded by their past learnings. I find it hard to believe that theres only one paradigmn for OO in this world.
29Mar05 SRIV I just tried out itcl to see if I could make a tk widget. Using gButtons as an example, I found that I can make something that almost works like a Tk widget. In looking at the megawidget building commands in tcllib and mkWidgets and my guess is that someone could easily re-implement them using itcl at the core class mechanism.The advantages would be :
- high speed due to a c based OO core
- low memory usage compared to tcl based class system like snit
- itcl has been TIP'ed into the tcl core
- itcl is already in tclkit
- itcl is too c++ like, unlike tcl in general
- Xotcl is better suited to the task, could easily be wrapped to emulate snit
shows an example of how to create a Tk widget using Xotcl:# Widget is a metaclass, that provides the generic create method to
# the Widget classes. For each XOTcl object, a Tk widget with a
# leading dot is created.
Class Widget -superclass Class
Widget instproc create {name args} { eval [[self] set tk] .$name; next }
Widget instproc create {name args} { eval [[self] set tk] .$name; next }
# The Class TkWidget handles the flags, that are useful to redefine
# for XOTcl. We want to be able to work with self in callbacks, we
# want to sent instances variables of Objects, and so on. Everything
# unknown is delegated to Tk configure.
Widget TkWidget
TkWidget instproc s {} {string trimleft [self] :}
TkWidget instproc invoke cmd { eval $cmd }
TkWidget instproc command cmd {
.[[self] s] configure -[self proc] [list [self] invoke $cmd]
}
TkWidget instproc textvariable v {
.[[self] s] configure -[self proc] [self]::$v
}
TkWidget instproc unknown {m args} {
puts stderr "UNKNOWN eval .[[self] s] $args"
eval .[[self] s] configure -$m $args
}
# we want to support the following widget classes
Widget Button -superclass TkWidget -tk button
Widget Label -superclass TkWidget -tk label
Widget Entry -superclass TkWidget -tk entry
# well, now our application:
Button hello -text "hello world" -command {[self] text [self]}
Label l -text "Enter some text:"
Entry e -width 20 -textvariable input
Button quit -text "exit" -command {[self] print}
pack .hello .l .e .quit
pack .hello .l .e .quit
quit proc print {} {
#orig line: puts "entry var: '[e set input]'"
puts "entry var: '[.e get]'"
exit
}LV I have never built a megawidget. But it would seem, to me, that a Tcl oriented framework for creating widgets comprised of various existing widgets along with potentially new behavior could go several routes. For instance, one could create a framework where they didn't worry whether these megawidgets were coded, or even behaved, anything like Tk (or Ttk now). While this would mean that all developers start from the same point in learning the new framework, it frees the creator of the framework from past choices that may not suit them. If the widget behavior also changes, this means the users of applications based on the framework may also have issues, if something that looks like a tk or ttk widget acts differently in some cases.So, to me, it seems like, from a community of developers, users, and people who try and help those groups, having a goal of interfaces and behavior which exhibit least surprise would be best.Why bother saying this? Well, to get that least surprise goal, it would seem to me that one would want to make use of the existing widgets as much as possible. In that way, one doesn't have to duplicate (and keep in sync) code matching the existing toolset.Building a framework that makes use of existing widgets sounds like an object system with inheritance. I don't doubt that there are other ways to achieve this, however. It would seem to me though that to create a megawidget framework that either does not make use of an existing oo system, or creates its own as part of the framework, is going to have to go to a lot more work.DKF: I think there are a number of different things that people want with megawidgets. Some of them are easier than others.
- To add/modify methods/behaviours of existing widgets
- To make a new widget from scratch without writing C
- To do things that are somewhere between the two (e.g. a text widget with automatically adding scrollbars).
