[Glamour] default selection in ListPresentation
by Cyrille Delaunay
Hello,
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
|tmpBrowser|
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
a list
display: [:input | input];
selection: #a;
yourself
].
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
5 years, 6 months
broken Roassal2Spec Adapter
by Peter Uhnák
Hi,
apparently we broke MorphicRoassalAdapter when cleaning Spec, I attached a
fix.
However my question is - does anybody (except us) actually use the
Roassal2Spec package? Because otherwise we could clean it a bit. For
example I'm not sure of the use case of script:/lastEvent:.
Peter
7 years, 9 months
Magritte annotations removed in Moose 5.1
by Blondeau Vincent
Hello,
I would like to know why the Meta Editor in the Moose panel and the implementing class GLMMagrittePresentation have been removed from the Moose 5.1 image because I want to annotate a model with it.
If it is not possible to do it work for Moose 5.1, is there an equivalent?
Thanks in advance,
Cheers
Vincent
________________________________
Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
8 years, 4 months
Why not having NeoCSV and NeoJSON in the image?
by Alexandre Bergel
… if we have XML, why not CSV and JSON? This is all wide-spread standard
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 4 months
[Roassal2] Pharo 4 MouseWheelEvent compatibility
by Jan B.
Hello
We use Roassal on Pharo 4, but we ran across another compatibility issue.
On Pharo 4, MouseWheelEvent class got a little rework. It does not use
symbols #up and #down as direction anymore, not even via accessors.
TRMouseWheelEvent copies this direction, so because RTZoomableView looks for
these symbols, it is no longer working on Pharo 4 (mouse wheel now just
moves camera, but does not change scale).
More info about this Pharo 4 change you might find here:
http://forum.world.st/MouseWheelEvent-direction-in-Pharo-4-tp4806863p4806...
I tried to make few changes to make it compatible in both Pharo 3 and 4.
One option is just adding two methods into TRMouseWheelEvent which convert
Pharo 4 direction to Pharo 3 direction, so only interface change is when
creating TRMouseWheelEvent, usage of this event is absolutely same.
http://www.mediafire.com/download/es70j9dko45da2b/mouseWheel_pharo3like.zip
Second option is to rework TRMouseWheelEvent in the same way MouseWheelEvent
got changed, so they will have same usage on Pharo 4, but it means even
interface of TRMouseWheelEvent changes and everything that asks for its
direction has to be changed, too.
http://www.mediafire.com/download/38lwuwr1eauuur0/mouseWheel_pharo4like.zip
Third option is to use your own solution instead of mine.
And last solution might be just ignoring it and not trying to be compatible
with both Pharo versions.
Jan Blizničenko
--
View this message in context: http://forum.world.st/Roassal2-Pharo-4-MouseWheelEvent-compatibility-tp48...
Sent from the Moose mailing list archive at Nabble.com.
8 years, 5 months
agilevisualization layout chapter
by Peter Uhnák
Hi,
Is anybody working on layout chapter?
This (summer) semester I'll be writing my bachelor thesis on model
layouting and I am using Roassal, so since I need to get familiar with
Roassal layouting abilities I could as well write something about it. :)
Peter
8 years, 5 months
Issue 1103 in moose-technology: The list resulting of the Inspection of a MooseGroup should be in alphanumerical order
by moose-technology＠googlecode.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1103 by v.blonde...(a)gmail.com: The list resulting of the
Inspection of a MooseGroup should be in alphanumerical order
https://code.google.com/p/moose-technology/issues/detail?id=1103
Describe the problem: what do you get? what do you expect?
When you inspect with the moose panel (or an inspector) a model, the list
of the group items are randomly sorted.
I expect to have a alphanumerical sort on this list to quickly get an
element of the list.
How to reproduce the problem: step by step if necessary
Do: LANPackageTestResource current model allClasses inspect.
And go to the third tab (containing the list)
Additional information: platform, context which may impact the problem
Moose 5.0
Please fill in the labels with the following information:
* Type-Enhancement
* Component-GT
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
8 years, 5 months
PetitParser: Different behavior when a parsing is finished
by Damien Cassou
Hi,
Stéph and I are trying to revive Coral. There is a unit test that
fails:
self assert: (CLIParameterParser boolean) fail: #('falsely').
CLIParameterParser class>>boolean
| trueToken falseToken | trueToken := (self
caseInsensitiveKeywords: #('true' 'yes')) end ==> [:token
| true]. falseToken := (self caseInsensitiveKeywords:
#('false' 'no')) end ==> [:token | false]. ^ self new
setParser: (PPElementParser on: trueToken / falseToken
message: 'boolean expected'); name: 'bool'
CLIParameterParser class>>caseInsensitiveKeywords: aCollection
^ (PPChoiceParser withAll: (aCollection collect: [ :each |
each asParser caseInsensitive ])) token
I don't know if this test used to pass but I guess it did. I think
the problem is in the new work around "contexts".
Can somebody please help?
--
Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
8 years, 6 months
