Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 15 May 2003 10:42:55 +0200

Hi,

you're right, there is no mega-widget packet for XOTcl (I often use Tcl
megawidgets such as Bwidgets) ... yet it is
quite simple to integrate Tk and XOTcl; and build you're own megawidgets.
I found that wrapping the simple Tk widgets (or Bwidgets) does not make too
much sense, but building classes that represent more complex GUI elements is
very useful. The most simple thing you can do is to store the widget
IDs of the associated widget in a variable on the object representing it.

As said before, I do not use an integration <one widget == one object>
anymore but let the objects aggregate more than one widget. As for instance
a class TextEditor that contains a ScrolledWindow, a ctext, and some buttons.

I often integrate the name of the object and the name of the top
widget in such composite widgets. Here you have to be careful, the object name
returned by [self] contains "::" which you have to strip. Also object names
can potentially start with an upper case letter, widget IDs not. I only use
lower cases object names, so I can do something like:

  button .[namespace tail [self]]

in the constructor. Or you replace the "::"'s with "."'s, if you want to
use XOTcl aggregation to model a class hierarchy.

Another issue is callback commands. You usually want them to be dispatched
on the object. Then you cannot do something like:
  
   button .[namespace tail [self]] -command {[self] doSometing}

as the self is replaced in the wrong scope (of the callback) (because of the
brackets: {}) and does
not find the object. Instead you have to use substitution:

  button .[namespace tail [self]] -command [list [self] doSometing]

If you want to see some nice larger examples, download XOTclIDE
(www.xdobry.de/xotclIDE) and look at the file IDEBaseGUI.xotcl ...

Uwe

On Thursday 15 May 2003 08:09, Nicolas Boretos wrote:
> Hi,
>
> I am fairly new to XOTcl and this list, but so far I like XOTcl..
> Recently on clt, this was posted regarding tk widgets/framework
>
> ----snip---
> I haven't looked recently. Tix is technically adequate, I suspect,
> but there are cleaner ways of doing OO. My vote would be for
> something based on XOTcl---it seems to have about the best performance
> of the various OO frameworks, and it feels more like Tcl than (say)
> [incr Tcl]. On the other hand, [incr Tcl] has a nice set of
> megawidgets in [incr Widgets], so it's more nearly there.
>
> Is there any thoughts on anything like this from the XOTcl team...
>
> regards,
>
> nicolas
>
>
>
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Wed, 29 Sep 2004 12:59:25 +0200

On Sep 28, 2004, at 7:25 PM, Uwe Zdun wrote:

> Hi Catherine,
>
> on Unix we have moved the build system as default to the style
> preferred by TEA: the shells
> are not built anymore by default. Instead it is advisable to load
> XOTcl dynamically into the
> ordinary tclsh or wish. I propose you simply use this style of using
> XOTcl as well:
>
> % wish
> > package require XOTcl
> > namespace import xotcl::*
>
> the shells, if build (what is optional) now do nothing else than this.
>

Understood! and thanks for the "TEA" information - I was not aware of
it.

There is only one extension that I need to embed in a wish shell (it's
made by a colleague to display
3D molecules cf http://www.pasteur.fr/~letondal/biok/i3DMol.html).
It's because we need
to create new Tcl commands and run an init function to set up the
OpenGL environment at
startup.


        Catherine

From: Artur Trzewik <mail_at_xdobry.de>
Date: Thu, 2 Sep 2004 21:24:40 +0200

Am Donnerstag, 2. September 2004 20:55 schrieb Kristoffer Lawson:
> % package require XOTcl
> 1.3
> % xotcl::Class Foo
>
> ::Foo
>
> % Foo instproc bar {a} {puts $a}
> % Foo ob
>
> ::ob
>
> % ob info args bar
> % ob info body bar
>
> Or have I misunderstood something about what should be going on? I would
> assume args to return 'a' and body to return 'puts $a'?
>
> Do they only work on procs? Does that not slightly go against the 'slot'
> idea?

Please use
Foo info instargs bar
Foo info instbody bar

ob info args bar
works only for procs (procs owned by object ob)

master of introspection
Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 20 Mar 2006 15:21:27 +0100

Kristoffer Lawson schrieb:

>> I have added "::xotcl::mymethod" and "::xotcl::myvar" to my
>> development version. i guess, you would you prefer to have
>> these exported. Opinions?
>
>
> On giving it some thought I think I actually prefer the version that
> would be part of Object. After all, it is that object's variable that
> we want. I don't use it that frequently so I don't mind writing a bit
> extra, for clarity's sake.

i am open for everything.

>
> I'm also wondering what the name should be, to make it really clear.
> Is [my var] clear enough? or should it be [my normalisedVar]?

"my var" is not a good option, "my varname" would be better,

furthermore, "my method" is already defined, getting a good name with
method seems messy. how about:

    my trace add variable status write [my callback statusevent]

-gustaf neumann

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 17 Apr 2003 10:17:40 +0200

I'm not pretty sure about the goal of these examples yet, but - I'm
guessing - it seems that the problem is that variable traces do not act
like message interceptors. Instead they happen after the variable is
affected. This simple -pure tcl- example illustrates that the var trace
has no "protective" effect on x:

% proc a {var sub op} {
  error "I do not affect the variable"
}
% trace variable x rwu a
% set x 3
can't set "x": I do not affect the variable
% trace vdelete x rwu a
% set x
3
%

Of course, one could reverse the effect, say with unset; but this is a bit
cumbersome.

--uwe

On Wednesday 16 April 2003 22:35, Michael A. Cleverly wrote:
> On Wed, 16 Apr 2003, Gustaf Neumann wrote:
> > Most of the important things were already answered by Neophytos and
> > Kristoffer.
>
> Thanks to all of you for the pointers. XOTcl seems to be much more
> Tcl-ish than, say, [incr Tcl].
>
> > XOTcl does not need a special construct, since every class is an object
> > as well, and variables kept in a class are nothing special. Note that a
> > programmer can decide what kind of class he is referring to:
> > - the class which is the type of the object (via "my info class")
> > - the current class, which is currently active (via "self class")
> > The type variable you are refering to is the first one.
>
> This is a very helpful explanation. A light bulb just went on in my mind.
> Thanks.
>
> > Often, when people start to use XOTcl, there come requests how to
> > achieve private instance variables. These can be easily achived through
> > variable traces. Maybe someone finds the following code helpful or
> > interesting....
>
> Very interesting. But, I'm confused by the results I'm seeing (both
> before & after applying the patch). It seems that even though [o1 test0]
> and [o1 test1] throw an error the variable is updated. And [o1 test3]
> does unset the variable.
>
> % c1 show
> x=100
> % c1 test
> 10
> % c1 show
> x=10
> % o1 test0
> error: Can't find result of set x
> % c1 show
> x=13
> % c1 test
> 10
> % c1 show
> x=10
> % o1 test1
> error: can't set "x": private member x of ::c1 written from ::o1->test1
> % c1 show
> x=13
> % c1 test
> 10
> % c1 show
> x=10
> % o1 test2
> error: can't read "x": private member x of ::c1 read from ::01->test2
> % c1 show
> x=10
> % o1 test3
> % c1 show
> can't read "x": no such variable
>
> I'm using XOTcl 1.0.2 (compiled from source) & Tcl 8.4.2 (.deb) on Linux.
>
> (Neophytos: yes, I am the author of nstcl fame, though I didn't realize
> that would make me famous anywhere. :-)
>
> Michael
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 23 Mar 2004 15:29:45 +0100

On Tuesday 23 March 2004 13:20, Attilio Dona wrote:
> Hi,
>
> I am newer of XOTcl and I am evaluating the language for using it
> instead of Itcl in the new version
> of a large OSS Telecommunication sw project ranging from SDH/PDH, ip,atm
> and application level management.
>
> XOTcl builded successfully on HP-UX 11 and SunSolaris 8 and was
> integrated easily it into a starkit.

 Hi Attilio,
 good to hear this.

> My preliminary tests reveal this bug:
>
> # define a C class with a name
> Class C -parameter {{name ""}}
>
> # add a new parameter
> C parameter {{oid ""}}
>
> # now inspect the parameters
> C info parameter
> {oid ""}
>
> Whereas it would be:
> {name ""} {oid ""}

 This is a known deficiency. info parameter returns currently
 the content of the last parameter argument.

 Please use for the time being the following approach to
 add parameters (maybe define a proc for it).

   Class C -parameter {{name ""}}
   ...
   # add a new parameter
   C parameter [concat [C info parameter] {{oid ""}}]
   ...
   C info parameter
   # ... returns: {name ""} {oid ""}


 -gustaf neumann


PS: I am currently not completely happy with the parameter command,
 and started some time ago a few approaches to redo it, but these
 turned out to have other deficiencies. Known problems of the
 current implementation:

    - "info parameter" is not truely introspective but
      returns the last string content (although, this is in most cases fine)

    - the semantics of the method "parmeter" is different
      to other methods where one can specify multiple values. Look
      e.g. on the "mixin" method: one can remove mixins by issueing the mixin
      command again with a shorter list of values
        ....
        o mixin A B
        ....
        o mixin A
      In contrary to "mixin" another call of "parameter" adds a new one.

    - for the same reason, one cannot remove a parameter
      through the parameter interface (although one can remove the instcmd
      and the default by hand)

 I think, a better approach will be to use subobjects of the class to
 handle parameter semantics, but this will be most probably
 slower than the current version, which works quite well in a
 wide range of apps....

>--------------------------------------------------------------------
>CONFIDENTIALITY NOTICE
>This message and its attachments are addressed solely to the persons
>above and may contain confidential information. If you have received
>the message in error, be informed that any use of the content hereof
>is prohibited. Please return it immediately to the sender and delete
>the message. Should you have any questions, please contact us by
>replying to webmaster_at_telecomitalia.it.
> Thank you
> www.telecomitalia.it
>--------------------------------------------------------------------

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 15 Nov 2003 11:12:01 +0100

Hi!

The XOTcl are scoped (or can be scoped) in object namespace too.
I use it as follow

GUIClass instproc buildEntry win {
        my requireNamespace
        entry $win -textvariable [self]::entryValue
        my set entryValue {Init Value}
}
requireNamespace is required to build namespace for object.
XOTcl object orientation is build (was build) on Tcl namespaces.

You have access to variable per
my set userName
or
instvar userName
set userName

I recommend also to use list command to programm callbacks

button $win -text "My Button" -command [list [self] buttonPressed]

Look at XOTclIDE http://www.xdobry.de/xotclIDE
component (IDEBaseGUI) to have many examples how
to bind XOTcl with Tk

Artur Trzewik

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Thu, 8 Dec 2005 15:39:27 +0100

When I run the script, I get:

::x y 'y0'
::x y 'y1'
::x init ''
::x y ''
expected 'y1', but got: ''

Yes, you are right, I overload the setter/getter method and expected
naively that it just prints the puts-statement and works otherwise
unchanged. [Should have read the manual more properly, I guess :-)]
I can achieve my desired result too, by doing something like:

X instproc y {args} {
    puts "[self] y '$args'"
    my instvar y
    if {[llength $args]} { set y [lindex $args 0] }
    next
}

But I wanted to have an 'official' answer to this behaviour.

Regards,
- Florian


-----Original Message-----
From: Gustaf Neumann [mailto:neumann_at_wu-wien.ac.at]
Sent: Thursday, December 08, 2005 12:43 PM
To: Murr, Florian
Cc: xotcl_at_alice.wu-wien.ac.at
Subject: Re: [Xotcl] Is this a bug?

Hmm, are you sure? the script you have sent does not produce the message
you are indicating....

~/scripts> set ::xotcl::version
1.3
~/scripts> set ::xotcl::patchlevel
.8
~/scripts> Class X -parameter {
> {y y0}
>}
::X
~/scripts> X instproc init {args} { puts "[self] init '$args'"; next }
~/scripts> X instproc y {args} {
> set x [next]
> puts "[self] y '$args'"
> set x
>}
~/scripts> X create x -y y1
::x y 'y0'
::x y 'y1'
::x init ''
::x
=============================
however, most probably it is not doing what you might be expecting.
your method y overwrites the setter method of parameter y, therefore in
this example, not much happens in the next of method y.

maybe you had in mind to overload the setter/getter method, which you
can do e.g. with a mixin (see below)

Class X -parameter {
    {y y0}
} -instmixin [Class new -instproc y args {
  puts "[self] [self proc] $args"
  set x [next]
  puts "[self] [self proc] $args setter returns <$x>"
  return $x
}]

X create x -y y1
puts x.y=[x set y]

From: Andriy Tkachuk <ant_at_imt.com.ua>
Date: Mon, 24 Dec 2001 22:15:21 +0200 (EET)

I've just tried an new (last) version of XOTcl and get an amount
of my XOTcl code errors, that there isn't such function as cset!.


In http://media.wu-wien.ac.at/doc/ChangeLog I saw:

2001-09-16 Uwe Zdun <uwe.zdun_at_uni-essen.de>
...
- eliminated "cset" on Object and from the distribution, seems to
          be nearly unused

...


How did you estimate the unuseness!? :))

On my mind, it was very usefull one,,, at last for me...

thanks,
  Andriy.

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 11 Dec 2000 16:26:33 +0100 (CET)

>>>>> "L" == Laurent Duperval <laurent.duperval_at_netergynet.com> writes:

L> Hi,
L> How do I do aggregation of objects? For example, in Java I have

L> class Foo {
L> Class1 c1;
L> Class2 c2;
L> }

L> where Class1 and Class2 are two other classes. How do I create the same
L> effect in XOTcl? I've tried a few variations but I don't get the effect I
L> want so I guess I'm doing wrong.


Dear Laurent,

XOTcl supports dynamic aggregation of (a) objects and (b) classes.
Your example resembles a static aggregation of objects (static, since
you can't change the aggregation at runtime).

For object aggregation, one can do:

   Class Class1
   Class Class2

   Class Foo
   Foo instproc init {} {
     Class1 [self]::c1
     Class2 [self]::c2
   }

   Foo f

In order to change the aggregation, one can add new objects

   Object f::o

The objects form an object tree, which can be disaggregated or moved
etc. through the copy/move/destroy methods.

In addition to the aggregation of objects, XOTcl allows the
aggregation of descriptive structures (classes) as well

  Class C
  Class C::Foo

  C::Foo instproc ...
  C::Foo proc ...

which supports the same methods for disaggregation etc. like for
object aggregation.

For a more detailed discussion about aggregation in XOTcl see:
http://nm.wu-wien.ac.at/research/publications/sac.pdf


L> Also, how do you create and use private data? By this I mean data (and
L> possibly methods) which are only accessible by the class or the object.

XOTcl has no native support for private data. The idea of private data
conflicts to a certain point with the idea of introspection and
reflection. However, one can achieve a similar behavior through
refinement of the set method (and by deactivating the Tcl set
command). For the refinement you can define for example a set method
on the class level, mixins or filters.

hope this helps
best regards

-gustaf neumann