Folks -
With the last set of updates traits have finally become un- and
reloadable. To unload traits, execute:
Trait unloadTraits.
This will flatten any existing traits and convert them into classes. The
trait related information is stored in the #traitInfo method (browse the
senders of #traitInfo after unloading to see how that looks). If you run
the tests, the only new failures should be traits related tests (for the
obvious reasons; unload the TraitsTests package to get them out of the way).
Reloading simply works by loading the traits package again, for example:
(Installer repository: 'http://source.squeak.org/trunk')
install: 'Traits'.
Once loaded, the original traits will be restored if the information in
#traitInfo is still present, meaning that the round trip conversion is
lossless.
In the process I noticed a problem with MC diff handling of traits. You
may have to "flush cached versions" in MC after updating or otherwise
the Traits package may be shown as dirty. I think that's our SS server
again acting strangely with regards to diffs.
Cheers,
- Andreas
Andreas Raab uploaded a new version of Traits to project The Trunk:
http://source.squeak.org/trunk/Traits-ar.274.mcz
==================== Summary ====================
Name: Traits-ar.274
Author: ar
Time: 1 January 2010, 8:10:03 am
UUID: 2f372a19-83fc-7147-958e-ca7e0cd2dc9f
Ancestors: Traits-ar.273
Add post-load initialization for reloading traits.
=============== Diff against Traits-ar.273 ===============
Item was added:
+ ----- Method: Trait class>>install (in category 'load-unload') -----
+ install
+ "Make me the default Trait implementation"
+ ClassDescription traitImpl: self.
+ "And restore any previously flattened traits"
+ self restoreAllTraits.
+ !
Item was added:
+ ----- Method: Trait class>>initialize (in category 'load-unload') -----
+ initialize
+ "Install after loading"
+ self install.!
Andreas Raab uploaded a new version of Traits to project The Trunk:
http://source.squeak.org/trunk/Traits-ar.273.mcz
==================== Summary ====================
Name: Traits-ar.273
Author: ar
Time: 1 January 2010, 7:51:17 am
UUID: 80802762-102e-4f46-9678-b16af7aa849d
Ancestors: Traits-ar.272
Deprecated the no longer used kernel traits.
=============== Diff against Traits-ar.272 ===============
Item was changed:
SystemOrganization addCategory: #'Traits-Composition'!
SystemOrganization addCategory: #'Traits-Kernel'!
- SystemOrganization addCategory: #'Traits-Kernel-Traits'!
Andreas Raab uploaded a new version of 311Deprecated to project The Trunk:
http://source.squeak.org/trunk/311Deprecated-ar.1.mcz
==================== Summary ====================
Name: 311Deprecated-ar.1
Author: ar
Time: 1 January 2010, 7:49:53 am
UUID: 557903ee-2ed7-4945-9559-0ab2bf732727
Ancestors:
Deprecate the no longer used kernel traits.
==================== Snapshot ====================
SystemOrganization addCategory: #'311Deprecated-Traits'!
Andreas Raab uploaded a new version of Monticello to project The Trunk:
http://source.squeak.org/trunk/Monticello-ar.350.mcz
==================== Summary ====================
Name: Monticello-ar.350
Author: ar
Time: 1 January 2010, 7:22:28 am
UUID: 7e908a5e-3004-2143-a011-4ab25930801b
Ancestors: Monticello-nice.349
Making traits unloadable: Slight change to Monticello class creation to function correctly in the absence of traits.
=============== Diff against Monticello-nice.349 ===============
Item was changed:
----- Method: MCClassDefinition>>createClass (in category 'installing') -----
createClass
+ | superClass class composition |
- | superClass class |
superClass := Smalltalk at: superclassName.
class := (ClassBuilder new)
name: name
inEnvironment: superClass environment
subclassOf: superClass
type: type
instanceVariableNames: self instanceVariablesString
classVariableNames: self classVariablesString
poolDictionaries: self sharedPoolsString
category: category.
+ "The following is written to support traits unloading"
+ composition := Compiler evaluate: (self traitComposition ifNil:['{}']).
+ (composition isEmpty and:[class traitComposition isEmpty]) ifFalse:[
+ class setTraitComposition: composition asTraitComposition.
+ ].
- class setTraitComposition: (Compiler
- evaluate: (self traitComposition ifNil:['{}'])) asTraitComposition.
+ composition := Compiler evaluate: (self classTraitComposition ifNil:['{}']).
+ (composition isEmpty and:[class class traitComposition isEmpty]) ifFalse:[
+ class class setTraitComposition: composition asTraitComposition.
+ ].
- class class setTraitComposition: (Compiler
- evaluate: (self classTraitComposition ifNil:['{}'])) asTraitComposition.
+ ^class!
- ^class
- !
Andreas Raab uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-ar.363.mcz
==================== Summary ====================
Name: Kernel-ar.363
Author: ar
Time: 1 January 2010, 7:18:12 am
UUID: bb277eb0-1fa6-ef4f-94d3-e29d4ebfc9ee
Ancestors: Kernel-ul.362
Making traits unloadable: We need three backstop methods in Behavior.
=============== Diff against Kernel-ul.362 ===============
Item was added:
+ ----- Method: Behavior>>traitComposition (in category 'traits') -----
+ traitComposition
+ "Backstop. When traits are unloaded we never have a trait composition"
+ ^#()!
Item was changed:
----- Method: Behavior>>superclass:methodDictionary:format: (in category 'initialize-release') -----
superclass: aClass methodDictionary: mDict format: fmt
"Basic initialization of the receiver.
Must only be sent to a new instance; else we would need Object flushCache."
superclass := aClass.
format := fmt.
+ methodDict := mDict.!
- methodDict := mDict.
- self traitComposition: nil!
Item was added:
+ ----- Method: Behavior>>hasTraitComposition (in category 'traits') -----
+ hasTraitComposition
+ "Backstop. When traits are unloaded we never have a trait composition"
+ ^false!
Item was added:
+ ----- Method: Behavior>>traitCompositionString (in category 'traits') -----
+ traitCompositionString
+ "Backstop. Monticello needs a traitCompositionString even with traits unloaded"
+ ^'{}'!
For many years now I have created artistic content that makes intensive use
of mouseovers. About a year ago I got a Nokia N810, and played a bit with
Squeak on that device. I've still not recovered from the shock of realizing
that on a touch screen, there is no such thing as mouseover!: you cannot
get the mouse cursor to move without putting it down. What to do.
I can think of two potential approaches to this problem.
1. Subclass or modify HandMorph to "do the right thing in the right
circumstances". Clearly some work has to be done to clarify how this should
behave. HandMorph seems quite complex -- I don't suppose someone has
written a tutorial on it somewhere?
2. A new class which acts as a mouse event proxy. This could either be a
"screen" -- something that would fit over an entire PasteUpMorph -- or a
"sled" that would be carried around by a HandMorph.
In any case, the obvious question is: how should it behave. I haven't
really specified this yet, but a rough idea would be something like this:
"it" absorbs mouseDown, and records what morph would receive mouseDown if
it weren't there. If a mouseUp occurs that would have been given to the
same morph then mouse events are replayed and sent to that morph.
Otherwise, "it" has to relay mouse events to whatever underlying morph
would have gotten them if it were not there. This may not be simple to
achieve.
Now I've only poked around a little, and it looks to me as though the code
for deciding what morph should get an event is in HandMorph. So, if I'm
serious about doing something, regardless of how I do this it looks like I
will need to get deep into the workings of HandMorph.
I've tended to want to do my custom stuff in Squeak by subclassing, and am
inclined to do approach 2 above -- at this point I kind of like the idea of
a "screen". Am I reinventing a wheel here? If someone knows of work I
should look at, I'd appreciate any references.
There's a major psychological difference between a mouseOver and a click.
The click is a kind of commitment, which a mouseOver isn't. It would be a
real shame to have to say that we just have to give up mouseOvers on touch
screens. I'm not prepared to do that.
-Thanks, Jim
---
Jim Rosenberg http://www.well.com/user/jer/
Internet: jr(a)amanue.com