[ann] bloc & cairo+morphic
by Tudor Girba
Hi,
We are happy to announce that based on the work of Glenn, Alex extended Bloc (Sparta) to work directly in the Morphic world using Cairo as a backend.
Cairo is less powerful than Moz2D (see the screenshot below for an example), but the implementation addresses a concern that the community raised regarding a perceived increased liability due to the dependency to Moz2D. Essentially this means that Bloc can be treated as another graphical library that can coexist with Morphic without requiring any external VM plugin.
I would also like to point out that adding a new backend and host was possible because of the many iterations (including throwing away whole implementations) that Alex and Glenn went through. I think they did an amazing job.
You can find a bit more details about Bloc here:
http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
Another issue raised regarding Bloc was that of the engineering effort required to make it a reality. That is why I would also like to announce that Alex joined feenk.com where he is primarily working on the graphical stack for Pharo.
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"To lead is not to demand things, it is to make them happen."
6 years, 4 months
moose & the dark theme
by Tudor Girba
Hi,
As you could see, in Pharo we turned the Dark Theme on by default.
The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:
- they were conceived on a white canvas
- the colors are hardcoded
Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.
What do you think?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
6 years, 4 months
Problem during export of MSE (SourceAnchor duplicated)
by Cyril Ferlicot D.
Hi,
In the latest Moose when I export a model with source anchors they are
not exported right. If I have a class referencing the sourceAnchor, the
source anchor is exported one time as an element and one time as an
attribute of the class instead of using a ref.
To explicit the problem:
testSourcesAnchorsAreNotDuplicatedAfterExport
| model package tempFile importedModel |
model := MooseModel new name: 'Model'.
package := FAMIXPackage new
name: 'Package';
mooseModel: model;
yourself.
FAMIXClass new
name: 'Class';
container: package;
sourceAnchor:
(FAMIXSourceTextAnchor new
source: 'some text';
mooseModel: model;
yourself);
mooseModel: model.
tempFile := (FileSystem memory / 'export-test.mse') ensureCreateFile.
model exportToMSEStream: tempFile writeStream.
importedModel := MooseModel new importFromMSEStream: tempFile readStream.
self assert: importedModel size equals: model size
This test was added to Moose yesterday.
The change of behavior was introduced with the <container> pragma.
In the method FMRepositoryVisitor>>exportProperty:withAll:, the
sourceAnchor property is now detected as a composite and the branch used
to export the property is values do: [ :each | self exportElement: each
]. Before the introduction of the <container> pragma, the property was
not a composite and the branch executed was:
values do: [ :each |
(self isPrimitiveTypeOrObject: each)
ifTrue: [
printer referenceName: each name ]
ifFalse: [
printer referenceNumber: (self indexOf: each) ]]
I don't know the "composite" and "container" system of FAME enough to
know how to correct this problem now.
If someone knows the importer/exporter I would appreciate help with this
one.
https://github.com/moosetechnology/Moose/issues/1198
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
6 years, 4 months
[ann] gt4gemstone
by Tudor Girba
Hi,
feenk.com is proud to announce gt4gemstone, a version of the Glamorous Toolkit aimed at supporting remote development with GemStone/S from Pharo. gt4gemstone is released as an open-source project under the MIT license and was built primarily by Andrei Chis with some marginal contributions from me.
The project is hosted at:
https://github.com/feenkcom/gt4gemstone
The toolkit currently offers several features:
• Remote Playground
• Remote Inspector with extensions that can be coded exactly like the ones in Pharo
• Remote Debugger with mixed stacks (Pharo and GemStone)
• Basic Remote Code Browser
• Remote Session Handler
• Integration with Roassal
• A Glamour-specific proxy model for efficient serialization of Glamour presentations
• A basic proxy model for working with any remote objects from GemStone
One particular aspect that we focused on is performance. So much so, that at one point inspecting objects in gt4gemstone was faster than doing them locally. In the meantime, the GT inspector from Pharo also received an upgrade.
But, perhaps the most exciting thing about this project is that most extensions of the inspector can be expressed exactly in the same way both in Pharo and in GemStone, and this makes the scenario of building in Pharo and deploying in GemStone even more appealing.
The official announcement with some extra details can be found here:
http://www.humane-assessment.com/blog/introducing-gt4gemstone/
Cheers,
Tudor
--
www.tudorgirba.com
www.feenk.com
"There are no old things, there are only old ways of looking at them."
6 years, 5 months
RTCalendarBuilder
by Markus Böhm
May I ask:
Roassal and Pharo are really fantastic. I’m trying to get a grip on it and
use it. What makes me think:
In the introduction of the superb “Agile Visualization” book it is stated,
that the Roassal OO approach allows for visualizations that are “easily
extensible”. I guess compared to hand-crafted, imperative visualizations.
Let’s take an example: RTCalendarBuilder
I noticed that present visualization of week days start with Sunday as
first day of week. E.g. in Europe/Germany weeks start on Monday (according
ISO8601). We are visually so used to it, that other schemes make us think
(not intuitive).
How could I modify this?
P.S.: Especially in calendrical visualizations there will be many (local)
variations. So maybe it’s a good example to understand how to easily extend
Roassal in above and similar topics as an interested user.
BR Mike
6 years, 5 months
