- Moose-dev - INF Mailman

Jenkins build became unstable: moose-latest-dev #1156

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1156/>

12 years, 9 months

1
2
0 0

Glamourous Inspector - multiple panes

by Ben Coman

Using a 24" wide screen, it would be useful to be able to configure the Glamourous Inspector [1] to have more than two panes showing at a time. Is that possible? cheers -ben

12 years, 9 months

2
3
0 0

Re: [Pharo-project] Roassal Survey

by Ben Coman

12 years, 9 months

1
0
0 0

Issue 850 in moose-technology: GT should offer a setting for the number of panes in the inspector

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-GlamorousToolkit Milestone-4.7 New issue 850 by tu...(a)tudorgirba.com: GT should offer a setting for the number of panes in the inspector http://code.google.com/p/moose-technology/issues/detail?id=850 We should be able to set the amount of panes visible at one time in the inspector. This is useful when having a large monitor.

12 years, 9 months

1
1
0 0

Re: [Pharo-project] Roassal Survey

by Tudor Girba

Hi, On Sun, Oct 7, 2012 at 10:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities. >> >> Is there a reason for this "freedom" in Roassal? > > Simplicity of the code. Currently there is absolutely no optimization or even caches in Roassal. > I have the feeling that this point will be crucial when we will have to address some scalable situations. But, this is not an optimization. Storing edges in reasonable places is about the meaningfulness of the model. Perhaps it makes sense to have it like it is now in Roassal, but I think there should be an explicit reason for it. That is because a graph has essentially two concepts, and if one of them is randomly placed, the model is only 50% sound :). Regarding caches, the original Mondrian had no cache either precisely because we wanted to keep it open. Caches were introduced only very late in the Pharo version because you wanted to make it faster :). It is clear that we learnt that hard and extensive caches impose limitations and I never argued for them. >>> I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges? >> >> I think you should have both. There should be a lookup, where the node >> should have the priority over the edge. > > > Probably yes. We tried something like this in Mondrian, but the model was not quite clean. There, even the layout could set the attachment points. It would be cool to rethink this part. Cheers, Doru > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- www.tudorgirba.com "Every thing has its own flow"

12 years, 9 months

1
0
0 0

ROMenuActivable on raw graphic elements

by Ben Coman

I have split this post into two parts since I think any follow up will form two distinct threads. As I am developing using Roassal, I find it useful to Explore the graphic elements from a context menu. To demonstrate I have adapted ROExample>>linesOn: "-------------" "-------------" menu := (ROMenuActivable new) item: 'Explore graphic element' action: [ :model | (rawView elementFromModel: model) explore ]. node1 := ROLabel elementOn: 'node1'. node2 := ROLabel elementOn: 'node2'. node1 @ RODraggable @ menu. node2 @ RODraggable @ menu. "uncomment next three lines for Part Two edge := ROEdge lineFrom: node1 to: node2. edge + (ROLine red). rawView add: edge. " rawView add: node1; add: node2. ROHorizontalLineLayout on: (Array with: node1 with: node2). "-------------" "-------------" Is there (or can there be added) a way to access the graphic element more directly? Something like one of the following two lines... item: 'Explore graphic element' action: [ :model :element | element explore ]. item: 'Explore graphic element' rawAction: [ :element | element explore ].

12 years, 9 months

2
5
0 0

Interactive Roassal (.5)

by Ben Coman

I have updated my try at a Roassal-Interactive demo (see attached) to the latest ConfigurationOfRoassal (AlexandreBergel.625). This is specifically to make use of the ROMenuActivable change to use graphic elements rather than nodes. I haven't got a home for this yet. Are there any parts of this that might be included under the main Roassal repository (probably under a separate Configuration due to the dependency on Glamour), or should a start a separate repository? Also are there any parts (especially the extensions to the Roassal-Glamour interface) that might get into mainline - or do you see other ways of achieving this.) cheers -ben

12 years, 9 months

1
0
0 0

Re: Status of PetitDelphi, a first visualization

by Stephan Eggermont

Alexandre wrote: > Looks good! > Using Roassal will give you some zooming in/out and a find button. > Quite useful :-) Yes, Roassal is definitely on the radar. The demo project is rather large, and zooming will be needed as soon as we add more information. Stephan

12 years, 9 months

2
1
0 0

Metrics about Moose itself

by Mariano Martinez Peck

Hi guys. Let's say I need to know how "large" Moose is. I want an approx. number of classes, package, and total LOC. I can take the default Moose distribution (one-click). Of course I only want to take into account only Moose packages (and its dependencies), but not Pharo itself. I could do it...but it may take some time.. maybe someone already did it. anyone? Thanks, -- Mariano http://marianopeck.wordpress.com

12 years, 9 months

3
5
0 0

[Fwd: Re: [Pharo-project] Roassal Survey]

by Ben Coman

moved to moose-dev Ciprian, Thanks for your detailed reply. Some comments inline... Ciprian Teodorov wrote: > Hi Ben, > > Sorry for the delay, I was very bussy these last few days. Attached to this > mail you will find some drawings showing what I mean. > > The first attachement [1] show the two most important graph concepts that > are needed for circuit design: the support for hyper-edges, and the ports > crossing hierarchical nodes. > The hyper-edges are useful to represent physical wires (which are connected > to a source, and then provide input to a number of sinks). > hyper-edges: Can you comment on how close Roassal Easel > #ROMondrianExample > #edges > orthoVerticalLine comes to your need for hyper-edges. Try arranging the nodes in various configurations. Note however... that where you have three "ortho" segments making up an edge and it looks like the first segment is shared by all edges, actually each edge has three segments each and the first segments are being drawn over the top of each other. Would that be significant? > The hierarchical crossings can be thought as the physical pins of an > integrated circuit, that are plugged into a socket in order to integrate > that circuit into a system. > hierarchical-crossing: Check out Roassal Easel > #ROMondrianExample > #edges > attachPoint. Also look at the coding of ROAttachPoint and subclasses, and in particular ROShorterDistanceAttachPoint>>fourFromPointsOfEdge: and >>fourToPointsOfEdge:. I think the way this has been done is quite elegant and building on these to create hierarchical-crossings might not be too hard. You might try it. Perhaps these might be called ROOuterAttachPoint and ROInnerAttachPoint and would respectively check to see if the connecting element is a contained sub-element. Alexandre, I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread. This used to decide which level within a hierarchy of sub-element edges are stored. Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite". Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint. > The second, and third attachement are the same (only the format differs pdf > vs png). They show a detailed example of the hierarchical structure that I > imagine. The main elements of this graphs are: the leaf nodes, the edges, > the hierarchical nodes, the pins, and the ports. > The leaf nodes are just the typical graph nodes. The edges are just links > between nodes. > The hierarchical nodes are graphs themselves, but they can be connected one > to another using edges. However these connections between hierarchical > nodes are done through the pins present on their interface. If such a > hierarchical node wants to be connected to the exterior it has to have pins > so that the layout algorithm can be constrained to route the edges to these > pins (which can be either free or have fixed positions). > The ports in my figure are just ways to group together a number of pins. > > In the figure you will see three graphs (corresponding to three views on > the leftmost graph). > The first one (on the left) just represents the top-level graph with all > hierarchical nodes collapsed. This graph itself has a number of ports so > that it can be embedded in another one. > The second one (in the middle) shows an expanded view of the central > hierarchical node in the top-level graph. This one is expanded into another > view. > The third one (in the right) shows yet another expanded view, this time of > a node in the middle graph. This last graph contains two hierarchical nodes > itself that are expanded in place. > > Now the idea of edges crossing hierarchy boundaries through pins is that > the inner-most hierarchical nodes can be layed out separately and then > collapsed, their containers can be layed out just like a simple graph (in > the case their nodes are collapsed). However if one node is a hierarchical > one, and is expanded, the layout algorithm does not have to layout the > contents inside this hierarchical node, it just layouts the whole graph > considering the pins as fixed nodes to which it will route the links. This > way when expanded the hierarchical nodes retain their initial layout, > moreover this initial layout takes into account the fact that the node will > be embedded into a larger graph and thus it will place the pins on the > boundary. > What do you think of Roassal Easel > Examples > ROExample > #interaction > zooming and ROExample > #interaction > expandableNodesOn: ? > FYI the graphs shown in the last two attachements where automatically > generated from a circuit design, they were imported into the Yed diagram > editor, one by one, layed out semi-automatically (used force-based layout > initially, an then moved a number of nodes manually to align them well - ex > the straight edges were obtained by manually moving the nodes). Just > imagine how boring this process is. Moreover since I had to represent the > pins, and the ports just as plain graph nodes grouped together the layout > algorithms don't have any idea that these nodes are special, thus they > place them everywhere, even more if the groups are expanded their inner > nodes are layouted along with the embedding hierarchy... resulting in a > mess. > > Cheers, > Ciprian > * > * > *References:* > [1] Miro Sponemann, Hauke Fuhrmann, Reinhard von Hanxleden, and Petra > Mutzel. > Port constraints in hierarchical layout of data > flow<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> > diagrams<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> > . > In David Eppstein and Emden Gansner, editors, Graph Drawing, volume 5849 of > Lecture Notes in Computer Science, chapter 14. > Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010. > > On Thu, Sep 27, 2012 at 3:35 PM, Ben Coman <btc(a)openinworld.com> wrote: > > >> Ciprian Teodorov wrote: >> >> >>> Another feature that I think it is missing in most (if not all) graph >>> viewers/layout systems/editors is the possibility to have connection ports >>> on the hierarchical nodes in order to preserve the connections passing >>> through the hierarchy. >>> >>> some pointers: >>> >>> http://www.slideshare.net/**teodorov/tools-and-**crossbarbased-nanocmos-* >>> *architectures<http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-archite…> >>> >>> http://stiff.univ-brest.fr/~**cteodorov/manuscript-teodorov_**FINAL.pdf<http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf> >>> >>> >>> Cheers, >>> >>> Ciprian Teodorov >>> >>> >>> On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena(a)gmail.com> >>> wrote: >>> >>> >>> >>> >> Ciprian, >> >> I have skimmed through those links but can't quite understand your comment >> "in order to preserve the connections passing through the hierarchy" Can >> you expand some more on that - perhaps with a mock up in a paint program? >> >> If you are interested in following the development of Roassal, perhaps >> move your follow up to https://www.iam.unibe.ch/** >> mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>. >> <https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> I have been very encouraged by the clean architecture and the >> responsiveness of the main developers to feature suggestions. >> >> cheers, Ben >> >> >> > > > > > ------------------------------------------------------------------------ >

12 years, 9 months

1
0
0 0

Status of PetitDelphi, a first visualization

by Stephan Eggermont

Hi, We're slowly building up the parse tree of a Delphi project. Here is the first visualization: The WhiteStarUML project is a GPL tool written in Delphi. It consists of 89 units at the interface level. There might be more units that are referred to in the implementation. 4 units cannot be found to be parsed, 5 units cannot be parsed. For each unit the number of classes defined in the interface is shown as a yellow square. Cheers, Diego & Stephan

12 years, 9 months

5
4
0 0

Arki demo

by Simon Denier

Hello guys Is there any demo of Arki in the standard Moose distribution? I would like to give a demo of Moose, including an example with a user browsing custom concerns. I did not see any sample for Arki in Moose 4.6 -- Simon

12 years, 9 months

2
2
0 0

Re: Issue 361 in moose-technology: Glamour status bar should take into account Mondrian window status

by moose-technology＠googlecode.com

Updates: Status: WontFix Comment #1 on issue 361 by alexandr...(a)gmail.com: Glamour status bar should take into account Mondrian window status http://code.google.com/p/moose-technology/issues/detail?id=361 In Roassal, we should instead add an element about this. It should not take that long to do it.

12 years, 9 months

4
5
0 0

Fwd: [Esug-list] Call for PhD candidates in the Software Composition Group, U Bern

by Tudor Girba

FYI Doru ---------- Forwarded message ---------- From: Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> Date: Thu, Oct 4, 2012 at 2:06 PM Subject: [Esug-list] Call for PhD candidates in the Software Composition Group, U Bern To: esug-list(a)lists.esug.org Applications are invited for PhD candidates at the Software Composition Group, University of Bern, Switzerland, to contribute to the SNSF project "Agile Software Assessment". The Software Composition Group carries out research in software analysis and programming language design and implementation, with a view to enabling software evolution. The SCG is led by Prof. Oscar Nierstrasz and is part of the Institute of Computer Science and Applied Mathematics (IAM) at the University of Berne. Details about the research project can be found here: http://scg.unibe.ch/research/snf13 The candidate must have a MSc in Computer Science (equivalent to a Swiss MSc), should demonstrate strong programming skills, and have research interests in several of the following areas: - software evolution - program understanding - software modeling - model-driven engineering - reverse engineering - domain specific languages - dynamic analysis - integrated development environments - programming language design - virtual machine technology To apply, please send an email including your CV to Prof. Oscar Nierstrasz (oscar(a)iam.unibe.ch). --- Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch Software Composition Group -- http://scg.unibe.ch/oscar University of Bern -- Tel/Fax +41 31 631.4618/3355 _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -- www.tudorgirba.com "Every thing has its own flow"

12 years, 9 months

1
0
0 0

Issue 835 in moose-technology: MooseGroup symbolsUsedInName uses deprecated methods

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 835 by step...(a)stack.nl: MooseGroup symbolsUsedInName uses deprecated methods http://code.google.com/p/moose-technology/issues/detail?id=835 String withoutTrailingBlanks and withoutLeadingBlanks Fixed in Moose-MondrianPaintings-Stephan.Eggermont.170 in http://www.squeaksource.com/Moose Additional information: platform, context which may impact the problem Please fill in the labels with the following information: * Type-Defect * Component-Mondrian

12 years, 9 months

1
1
0 0

Re: Issue 396 in moose-technology: Mondrian should provide teh start and end nodes in the edge action

by moose-technology＠googlecode.com

Updates: Cc: tudor.girba Comment #1 on issue 396 by alexandre.bergel: Mondrian should provide teh start and end nodes in the edge action http://code.google.com/p/moose-technology/issues/detail?id=396 I started to work on this (testHandlerOnEdge). However, I am unsure for few things. view interaction on: MOMouseDown do: [ :v | ... ] What v is supposed to be? The announcement or the value on which one has clicked? It has to be the value I believe. However, it may brake already existing code. We could leave it like this, and introduce on:withValueDo: What do you think? Cheers, Alexandre

12 years, 9 months

1
1
0 0

Re: Issue 398 in moose-technology: From and To positions need extension

by moose-technology＠googlecode.com

Updates: Status: WontFix Comment #1 on issue 398 by alexandr...(a)gmail.com: From and To positions need extension http://code.google.com/p/moose-technology/issues/detail?id=398 fromPositions: and toPositions: have disapeared in Roassal. Objects have to be used instead of selectors

12 years, 9 months

1
0
0 0

Issue 698 in moose-technology: Mondrian does not properly raise MOElementSelection

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-High Component-Mondrian Milestone-4.6 New issue 698 by tudor.gi...(a)gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698 When in Glamour, often when selecting a Mondrian element does not populate the selection because the MOCanvas does not raise MOElementSelection. The reason for this seems to be a race condition due to changes in the announcement framework. In the new announcement framework from Pharo 1.3, the order of announcements is not guaranteed. The issue seems to be due to the logic of the announcement: MOCanvas>>mouseUp: .. (lastEnteredGraphElement isNil not and: [ (lastEnteredGraphElement class ~~ MORoot and: [ lastEnteredGraphElement isNotSelected ])]) ifTrue: [ selectionEvent := MOElementSelection event: anEvent on: lastEnteredGraphElement. anEvent commandKeyPressed ifTrue: [ selectionEvent setAsMultiple ]. self announce: selectionEvent. anEvent wasHandled: true. ^ self ]. Sometimes, "lastEnteredGraphElement isNotSelected" returns false because somehow the element gets selected beforehand. This is most likely related to the fact that the selection of a node actually happens by handling the same MOElementSelection announcement: MOCanvas>>announce: anAnnouncement ... anAnnouncement element isNil ifFalse: [ anAnnouncement element announcer announce: anAnnouncement ]. self announcer announce: anAnnouncement. MOViewRenderer>>setUsefulHandlersForNodes ... self interaction on: MOElementSelection do: [:ann | ann isUnique ifTrue: [ self root allSelectedNodes do: [ :node | node deselect; announce: (MOElementDeselection new) ] ]. ann element select. self updateWindow ].

12 years, 9 months

4
15
0 0

Re: Issue 113 in moose-technology: Lazy edges in Mondrian

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #5 on issue 113 by tudor.gi...(a)gmail.com: Lazy edges in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=113 Should we postpone this one until later?

12 years, 9 months

2
5
0 0

Concept demonstration - Interactive Roassal for constructing models

by Ben Coman

Following on from recent pharo-project 'Roassal Survey' posts which asked for features for Roassal to be a universal diagram tool, I have cobbled together a concept demo. I was quite surprised and pleased that I was able to achieve this over the weekend - which I think is a testament to the potential power of the clean design that Alexandre has achieved for Roassal. Glamour also helped ease the way. Operation is quite basic - only interactively adding nodes and applying different layouts. Adding edges between nodes is still to go. Previously Roassal has been used only for scripting, so there are some bugs in the way I've forced it to operate, but I thought I'd release as early as possible to garner feedback and interest. Perhaps I get lucky and a Fuel expert finds this interesting. Help with moving the drawings to file and back would be appreciated. The attached package Glamour-Roassal-Interactive-BenComan.3 is based off Moose 4.7, tested against a fresh copy downloaded 2012-10-03 which contained: ConfigurationOfRoassal.AlexandreBergel.605 ConfigurationOfGlamour.TudorGirba.98 cheers -ben

12 years, 9 months

2
2
0 0

Jenkins build became unstable: moose-latest-dev #1149

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1149/>

12 years, 9 months

1
1
0 0

Roassal ROPopup styleable

by Dennis Schenk

Hi all, I wanted to be able to style popups in Roassal e.g. using another background color or setting a border, etc. So I added a method to ROPopup to be able to acces the ROBox it uses. The filed out class can be found here: http://cl.ly/code/3D0y0P233v1o @Alexandre: If you like the changes, could you add them to Roassal? Example usage would be: *popup := ROPopup text: 'test'.* *popup textColor: Color black.* *popup box color: Color white; borderWidth: 1; borderColor: Color lightGray. * * * Cheers, Dennis

12 years, 9 months

2
2
0 0

Issue 847 in moose-technology: Glamour does not populate the right value when selecting in EyeSeePresenation

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 847 by tu...(a)tudorgirba.com: Glamour does not populate the right value when selecting in EyeSeePresenation http://code.google.com/p/moose-technology/issues/detail?id=847 See GLMBasicExamples new eyeseeBarDiagram openOn: #(5 2 10 6 12 8).

12 years, 9 months

1
2
0 0

Issues plotting histograms with EyeSee

by Hernán Morales Durand

Hi guys, I want to dome basic plotting with EyeSee in Pharo 1.4, and try to imitate the following histogram produced with matplotlib: http://biopython.org/DIST/docs/tutorial/images/hist_plot.png which was taken from 94 samples rendered with 20 bins. I've tried this script including the same models: | diagram | diagram := ESDiagramRenderer new. diagram histogram models: #(740 753 748 744 733 718 730 704 740 709 700 726 753 699 658 752 726 765 755 742 762 745 750 731 741 740 727 711 743 727 757 770 767 759 750 788 774 789 688 719 743 737 728 740 696 732 731 735 720 740 629 572 587 700 636 716 592 716 733 626 737 740 574 594 610 730 641 702 733 738 736 732 745 744 738 739 740 745 695 745 743 730 706 744 742 694 712 715 688 784 721 703 744 592); property: [:each | each ]; numberOfIntervals: 20; rotatedLabels: true; yAxisLabel: 'Count'; xAxisLabel: 'Sequence length (bp)'; regularAxis; addXDecorator: ESValueLabelDecorator new. ^ diagram open but I'm experimenting some limitations that you may know better: 1) Cannot make both x and y labels to be displayed. 2) In the X axis, matplotlib seems to take only significant interval. 3) Also tried with different decorators (ESValueLabelDecorator, ESRangeLabelDecorator, ESRegularTickDecorator, etc) but it didn't changed. Any hints to overcome this? Best regards, Hernán

12 years, 9 months

2
4
0 0

selective forwarding of ROMenuActivable

by Ben Coman

Alexandre, A couple of days ago you showed how to forward only ROMouseDragging on a composed element while leaving ROLightlyHighlightable on the inner elements. I'd like to do the same with menus using ROMenuActivable. That is, I want to define one menu for an outer element to activate for all its inner elements. I gave it a naive guess by modifying ROExample>>composingOn:. below. This works if all are forwarded per CASE 1, but not per CASE 2. Is there a different class I should be forwarding? cheers -ben "-------------" "-------------" counter := 0. outter := ROElement new + ROBorder white. outter @ RODraggable @ ROLightlyHighlightable. inner := ROElement sprite @ ROLightlyHighlightable. innerLabel := (ROElement labelOn: 'My sprite') @ ROLightlyHighlightable. outter add: inner; add: innerLabel. "We layout the things" ROVerticalLineLayout on: outter elements. rawView add: outter. "CASE 1 forwarding all" inner forward. innerLabel forward. "CASE 2 menu forwarding" "inner forward: ROMouseDragging. inner forward: ROMenuActivable . innerLabel forward: ROMouseDragging. innerLabel forward: ROMenuActivable . " "MENUS" outter @ (ROMenuActivable new item: 'OuterMenu' action: [ :model | counter := counter + 1. Transcript crShow: 'Outer ', counter asString . ] ). inner @ (ROMenuActivable new item: 'InnerMenu' action: [ :model | counter := counter + 1. Transcript crShow: 'Inner ', counter asString . ] ). innerLabel @ (ROMenuActivable new item: 'InnerLabelMenu' action: [ :model | counter := counter + 1. Transcript crShow: 'InnerLabel ', counter asString . ] ). "-------------" "-------------"

12 years, 9 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev