Hi,
If you have talks that are related to Moose, please let us know and we will also add them to the news feed.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi!
I'm trying to load Glamour in pharo 1.4 with the following script:
Gofer it
squeaksource: 'Glamour';
package: 'ConfigurationOfGlamour';
load.
(ConfigurationOfGlamour project version: '2.3') load: #('Core' 'Morphic'
'Glamour-Magritte-Presentations')
And I'm having the following error:
This package depends on the following classes:
GLMOpenBrowserAction
You must resolve these dependencies before you will be able to load these
definitions:
morphicActOn:
Any idea?
Guille
Hello,
I am building a MoosePanel with customized entities, customized model and,
hence customized menus. So, for example, in models pane I would like to
display only my own models.
For menu items, I am looking to replace existing menus (on models and
entities) with my own menus: since the entities in my custom models are
particular, current menus cannot be used (some parts can be used e.g.
delete a model). I would like to keep the current display/navigation model
of the moose panel/moose finder.
For my solution, I have started subclassing MooseModel and MooseEntity to
be able to describe my customized menus on my models and entities.
Customized model integration in Moose Panel was smooth: subclass MooseModel
and launch this class from a MoosePanel subclass (needed to do a
resetMeta, though).
Customized menus cannot be constructed by simply subclassing MooseModel and
MooseEntities because menus are constructed from particular pragmas inside
methods of these classes.
My solution: I override mooseFinderActions method in my custom model class
to populate menus of my model. I works. However, I cannot reuse parts of
MooseModel menus that are applicable on my customized model. Similarly, for
actions (moosePresentationOrder:) I override methods for customized menu
building through pragma reading.
My question: Is it the right way to achieve my objectives or should I look
somewhere else for the task?
tx,
usman
Doru,
The tests that fail make use of the package-cache folder. They create a monticello package and save it locally.
I remember there were something about the configuration you have on Jenkins. What is it exactly?
Cheers,
Alexandre
On 24 Apr 2012, at 16:41, admin(a)moosetechnology.org wrote:
> See <http://hudson.moosetechnology.org/job/moose-latest-dev/951/>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I experienced some problem on installing Glamour for Pharo 1.4
Am I the only one?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7
New issue 791 by tudor.gi...(a)gmail.com: Glamour browsers should announce
changes
http://code.google.com/p/moose-technology/issues/detail?id=791
A Glamour browser should announce when the it changes its inner structure.
Essentially, it should announce the triggering of a transmission.
This can be useful if we want to build meta-tools that react to
interactions. For example, the tree visualization of a browser should be
able to update itself every time the browser changes.
Hi,
I have some minimal glamour enhancements that I would like to push up. Not too important, but I would like to hear opinions before commiting:
1) GLMAction refactoring
-I added several testing methods (#isMenu, #isButton)
-I changed way of rendering actions, adding a #renderGlamorouslyOn: inside actions (so you can change ways of presenting action buttons if desired: I needed to add some behavior for my customer of lawsuit tracker)
-refactor #renderToolbarForPresentation:inMorph: to take advantage of all this issues.
2) morph presentation refactoring
It was showing a plain morph, I added a renderer to be able to respond to events fired by updateOn:
3) actionList presentation was refactored into it's own renderer... yes, I know Doru wants to drop that presentation, but I needed then I added it (if you want to drop this one, I can put it in my own package)
4) I added icons and shortcut text to context menus (if present... if not, everything behaves like before)
all tests are green
so... should I push this changes?
best,
Esteban
Hi!
I just download the last moose from the ci.moosetechnology.org
Simply opening the image seems to active some diff, cleaning, to quit at the end.
Can someone tell us a bit more what is happening?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
The second challenge I mentioned in the mail before is related to outgoing
edges stored for MONodes.
When I create a layout in the following way...
*view nodes: self nodes.*
*view edges: self nodes *
* from: [ :each | each ] *
* toAll: [ :each | each children ].*
* view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model
entity numberOfLinesOfCode ]).*
...Everything works as expected. Meaning every MONode has outgoing edges to
its direct children defined.
However, if I construct a layout in the following way...
*view nodes: (self getLevel: 3) "Returns all nodes on a certain level in
the tree"*
* forEach: [ :each |*
* view nodes: each recursiveChildren. "All nodes below given node"*
* view edges: each recursiveChildren "From all nodes to all their direct
children"*
* from: [ :node | node ] *
* toAll: [ :node | node children ].*
* view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model
entity numberOfLinesOfCode ]).*
* ].*
...So that I have multiple TreeMaps (one for each node on level 3 in the
graph), the MONodes do *not* have outgoing edges defined and thus I can't
render the TreeMap.
Does anyone have an idea what could cause this behavior?
Cheers,
Dennis