A new version of STklos with great improvements. You can try this version
without recompiling STk (and without overloading the old version).
I leave my office this evening, for two weeks, and I have no time for making a
more conventional release. However changes should (I hope) make things easier.
If you see bugs there send them to stk-bugs_at_kaolin.unice.fr.
All the stuff is on kaolin.unice.fr:/pub/STklos-update.tar.gz
Hererafter is the README file
Happy STklos-ing
-- Erick
--------------------------------------------------------------------------
STklos-update
-------------
This directory contains an update of STklos (I leave this evening,
for two weeks and I have no time for making a new release).
You can test this version without doing the whole installation.
To install this version unpack the file in the STk-2.1 (or STk-2.1.1)
directory and type
- make install
to install it in standard place or
- make install LIB_STKLOS=/new/path/for/stklos
If you choose the second solution (which is probably better since I have not
fully tested its "backward" compatibility with 2.1* ). You will have to define
the variable STK_LOAD_PATH to load the STklos files before the standard STk
files. For instance,
STK_LOAD_PATH=/new/path/for/stklos:/usr/local/lib/stk
Hints: . You can set the *load-verbose* variable to see which files are loaded.
. Don't forget to export the STK_LOAD_PATH variable.
Why you should use this new version of STklos:
1. Code is cleaner (Most of the changes are due to Rob DeLine)
2. An important change is in the meta-class determination. This idea is also
due to Robert Deline. Hereafter, Rob speaks:
Rob>
Rob> [This] change is more exciting, and represents an idea Gregor
Rob> thought of after his book was already published. The standard definition
Rob> of define-class says that, if no metaclass is specified, then <class>
Rob> should be used. This means that, if a user wants to subclass off
Rob> a class that specifies a metaclass, the subclass has to specify the
Rob> same metaclass (or a compatible one). This is a shame, since many
Rob> users don't understand or care about metaclasses.
Rob>
Rob> So the second big change I made was to fix this shortcoming. The
Rob> new definition of define-class says that, if no metaclass is specified,
Rob> then the "appropriate" metaclass is used. What "appropriate" means
Rob> is fairly straightforward, but quite a mouthful: the "appropriate"
Rob> metaclass for class X is the most general subclass of all of X's
Rob> superclasses' metaclasses! (Aiiieee! :)
Rob>
Rob> Here's an example: <Label> has superclasses <Tk-simple-widget>,
Rob> <Tk-simple-text>, <Tk-sizeable>, and <Tk-bitmap>. The metaclasses
Rob> of these classes are: <Tk>, <class>, <class>, and <class>. The most
Rob> general subclass of all of these metaclasses is <Tk>, so <Label>'s
Rob> metaclass should be <Tk> -- just what you would expect! (It turns
Rob> out, under some circumstances, that this "appropriate" metaclass
Rob> may not exist and has to created on the fly -- but this is not a
Rob> big deal.)
Rob>
Rob> So, why are these changes interesting? Well, first let me show you
Rob> how the standard definitions have become simpler. The definition
Rob> of <Label> is now this:
Rob>
Rob> (define-class <Label> (<Tk-simple-widget> <Tk-simple-text>
Rob> <Tk-sizeable> <Tk-bitmap>)
Rob> ())
Rob>
Rob> Notice that the macro define-simple-widget isn't needed anymore
Rob>
Rob> ...
Rob> ...
Rob>
Rob> The benefits are much greater when you think about users subclassing
Rob> off of the Tk classes, like <Label>:
Rob>
Rob> (define-class <My-Label> (<Label>)
Rob> ((my-slot :initform 'foo)))
Rob>
3. You can now make composite canvas items. (See the Examples directory)
4. You can now make group (a` la Mac-Draw) with canvas items. A group is
a special kind of canvas item. and you can make things like
(move the-group 10 10)
(destroy the-group)
....
5. There is a cleaner initialisation of composite objects which permits
to initialize all the slots which have specified a :init-keyword
(this was not the case for pseudo slots before).
6. Composite objects are available in base STklos and don't need to load
Tk classes as before.
7. There are now commented examples of code using STklos.
8. Some cosmetic changes which make the things clearer. Names have been
suggested by Rob:
:pseudo -> :tk-virtual (like ":virtual" but for Tk options)
:special -> :propagated (since these are "propagated" to other widgets)
:propagate -> :propagate-to
All my code use those new names. However, provision was taken for accepting
also
the old one (I hope so...). Please try to avoid old names, so I can delete them
in future versions.
Enjoy.
Received on Fri Aug 05 1994 - 18:06:09 CEST
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST