No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Re: [Xotcl] Re: [Xotcl] Widgets
From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Tue, 6 Feb 2001 13:11:05 +0100 (CET)
>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
CL> Gustaf Neumann wrote:
RH> Or wrap every tk command in my xotcl object.
>>
>> Sometimes, this is a straight forward solution to keeps the
>> XOTcl objects and the tk widget in separate trees. Architecturally,
>> this is not a beauty.
CL> How do you then implement the composite pattern for widgets trees as
CL> explained in:
...
CL> In my application, every Tk widget creation is wrapped in a method:
CL> widgets build ${frame}::widgets::panel {
CL> frame $path.panel
CL> }
CL> where widgets is of class Object.
my point is not that you can't do it, the point is that it can be
done in many ways, but we have for now no definitive best
solution. The main problem is that often there are other Tcl commands
(pure Tcl, [incr tcl], tk, ...) that we want to treat like first
class XOTcl objects. A mechanism suited for Tk is not necessarly the
best for [incr tcl] or other situations. We are using some ad-hoc
approaches for the problem already for "package" (see package.xotcl)
or file (see make.xotcl) based on renaming of the original
command. The classical solution are object wrappers for "legacy
components", which are more a programming than a generic approach,
and are difficult when the "legacy component" has a different
understanding of e.g. the composite model (like tk). I have
implemented most of my GUIs via Motif, which is some respects easier
to integrate, since it follows the idea "every widget has an ID"
rather than "every widget is a command" (like in tk). The latter
leads to the "conflict" with XOTcl, which says "every Object is a
command". OTOH, solving this conflict is quite an interesting and
generic challenge.
CL> Then you may store informations concerning the widget, in order to
CL> be able to save it, clone it, or whatever.
CL> The composite pattern is very convenient indeed for tk widgets. I
CL> use it to make recursive Tk bindings, or to build a graphical
CL> attribute editor for all the widget tree.
Catherine, you seem to be quite happy with your Tk integration. Can
you post a small but complete introductory example. Do you use Tk
features like "-command"?
best regards
-gustaf
CL> --
CL> Catherine Letondal -- Pasteur Institute Computing Center
Date: Tue, 6 Feb 2001 13:11:05 +0100 (CET)
>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
CL> Gustaf Neumann wrote:
RH> Or wrap every tk command in my xotcl object.
>>
>> Sometimes, this is a straight forward solution to keeps the
>> XOTcl objects and the tk widget in separate trees. Architecturally,
>> this is not a beauty.
CL> How do you then implement the composite pattern for widgets trees as
CL> explained in:
...
CL> In my application, every Tk widget creation is wrapped in a method:
CL> widgets build ${frame}::widgets::panel {
CL> frame $path.panel
CL> }
CL> where widgets is of class Object.
my point is not that you can't do it, the point is that it can be
done in many ways, but we have for now no definitive best
solution. The main problem is that often there are other Tcl commands
(pure Tcl, [incr tcl], tk, ...) that we want to treat like first
class XOTcl objects. A mechanism suited for Tk is not necessarly the
best for [incr tcl] or other situations. We are using some ad-hoc
approaches for the problem already for "package" (see package.xotcl)
or file (see make.xotcl) based on renaming of the original
command. The classical solution are object wrappers for "legacy
components", which are more a programming than a generic approach,
and are difficult when the "legacy component" has a different
understanding of e.g. the composite model (like tk). I have
implemented most of my GUIs via Motif, which is some respects easier
to integrate, since it follows the idea "every widget has an ID"
rather than "every widget is a command" (like in tk). The latter
leads to the "conflict" with XOTcl, which says "every Object is a
command". OTOH, solving this conflict is quite an interesting and
generic challenge.
CL> Then you may store informations concerning the widget, in order to
CL> be able to save it, clone it, or whatever.
CL> The composite pattern is very convenient indeed for tk widgets. I
CL> use it to make recursive Tk bindings, or to build a graphical
CL> attribute editor for all the widget tree.
Catherine, you seem to be quite happy with your Tk integration. Can
you post a small but complete introductory example. Do you use Tk
features like "-command"?
best regards
-gustaf
CL> --
CL> Catherine Letondal -- Pasteur Institute Computing Center