- Moose-dev - INF Mailman

by Stephan Eggermont

I wondered how many views the movies would get without being announced: 0. Demo: Handling hierarchical datasets with Quicksilver https://www.youtube.com/watch?v=pOxKVVoCH3A Handling Objects with Fuel and Tanker https://www.youtube.com/watch?v=-UQ35SOsuaY rendering & uploading Custom architectural assessment of a large enterprise system Stephan

12 years, 2 months

1
0
0 0

moose 5.0 roadmap

by Tudor Girba

Hi, The summary of the talk laying out the Moose 5.0 roadmap can be found at: http://www.humane-assessment.com/blog/moose-5-0-roadmap Cheers, Doru -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

12 years, 2 months

8
27
0 0

ConfigurationOfSeaside30

by Diego Lont

Hi all, Hi Johan, I tried loading the seaside30 version 3.0.8 into moose 4.8 by using: (ConfigurationOfSeaside30 project version: '3.0.8') load: 'OneClick'. This resulted in a failure, since there was still some dependency on OB, and this could not be resolved, since OB is removed in Pharo 2.0 for the time being. I fixed this by moving 'Seaside-Tools-OmniBrowser' in group 'OneClick' from squeakcommon to squeak + pharo 1.x. And since this package is too big for the list, anyone who wants it can mail me. On squeaksource I am called del, so if someone could add me here, I will commit this version to the Seaside30 repository. Cheers, Diego

12 years, 2 months

1
0
0 0

Re: Work on configurations browser

by Tudor Girba

(let's keep the discussion on the mailing list) Excellent. I added you to the Moose team. More and more exciting things happen in the Moose-land :) Doru On Tue, Apr 16, 2013 at 9:02 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi Doru, > > I just added myself on smalltalk hub. User DiegoLont. It would be nice if > my work is used by others as well. > > I will make a model of the configuration, so we can store here the things > we use in the configuration browser. Also I will move stuff back into the > glamour tools package. I hope to be able to work on this tomorrow. > > Cheers, > Diego > > On Apr 16, 2013, at 7:35 AM, Tudor Girba wrote: > > > Hi Diego, > > > > I only now got some time to review your browser. Nice job. > > > > What I like: > > - You integrated method editing > > - You made it robust so that it can deal with configurations that do not > have all parts loaded > > - You added the load / fetch commands and the associated refresh > (through announcements) > > - You kept the browser clean (often people have the tendency to add > instance variables for managing the browser state) > > - You added a group view > > > > What should be improved: > > - You have two panes for specs and versions. We should unify them. > Ideally, we should build an intermediary model that keeps track both of the > method and of the Metacello version. Thus, when we select the version we > should get the associated code as well. > I already thought this was needed. But I first wanted to be able to edit > methods, and ran into trouble that I needed a different representation. I > did not want to start with a model of the configuration. > > > - The cache instance variables should move into this model, as well. > That makes sense. > > > - You used underlining to denote loaded code, and blue to denote > configurations. I think would like to keep color to denote when something > has changed locally, but we can talk about this. > I followed the monticello standard, to make it more uniform. I agree: we > should keep blue for something that changed locally. So I will think of > another way to paint projects. > > > - The group view should drill into dependencies as well. Like this we > can see what is the impact of loading a certain group. > The model of the configuration should help for this. > > > - We need commit commands both for the configuration and for the > packages :) > And for using the Metacello toolbox functions: like update this version > for the package versions loaded. > > -- www.tudorgirba.com "Every thing has its own flow"

12 years, 2 months

1
0
0 0

Re: Work on configurations browser

by Tudor Girba

Hi Diego, I only now got some time to review your browser. Nice job. What I like: - You integrated method editing - You made it robust so that it can deal with configurations that do not have all parts loaded - You added the load / fetch commands and the associated refresh (through announcements) - You kept the browser clean (often people have the tendency to add instance variables for managing the browser state) - You added a group view What should be improved: - You have two panes for specs and versions. We should unify them. Ideally, we should build an intermediary model that keeps track both of the method and of the Metacello version. Thus, when we select the version we should get the associated code as well. - The cache instance variables should move into this model, as well. - You used underlining to denote loaded code, and blue to denote configurations. I think would like to keep color to denote when something has changed locally, but we can talk about this. - The group view should drill into dependencies as well. Like this we can see what is the impact of loading a certain group. - We need commit commands both for the configuration and for the packages :) Btw, you worked on a separate package :). If you give me the StHub user, I add you to the Moose team and we can work together on the GToolkit. Cheers, Doru On Apr 12, 2013, at 11:05 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi Doru, > > Maybe I did not follow all standards doing a remake of the configuration browser, but can you take a look. > >> I fixed some performance bugs (not all, dependencies still can be very slow). >> I made it possible to edit the configuration. >> I added the possibility >> I set the layout to follow the Monticello standard instead of a new standard. > > Maybe there is more work to be done, but please give your input how you like it so far. > > Cheers, > Diego > <Deltawerken-Configuration-DiegoLont.7.mcz> -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

12 years, 2 months

1
0
0 0

petitparser first/follow improvements

by Tudor Girba

Hi Jan, You once improved the way First and Follow work in the PPBrowser. Where can I find the changes? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 2 months

1
0
0 0

Videos: Pharo from the CommandLine

by Stephan Eggermont

Not yet combined with the screencast Pharo from the CommandLine https://www.youtube.com/watch?v=T8RNcXD94jk now rendering & uploading: Fuel & Tanker

12 years, 2 months

1
0
0 0

Bezier curves

by mathieubmddehouck＠mailoo.org

Hello It could be nice to use Athens version of Bezier curves, if it's made for better looking in vectorial. Then I've implemented a working way of drawing Bezier curve on Friday morning, so we can use Athens one or not, the code for bezier curves in Roassal now exists. Regards Mathieu

12 years, 2 months

1
0
0 0

Videos: MongoDB

by Stephan Eggermont

Taming MongoDB from Pharo https://www.youtube.com/watch?v=LOFygLIRLY8 now uploading: Pharo from the CommandLine

12 years, 2 months

1
0
0 0

New RadialTreeLayout for Roassal

by mathieubmddehouck＠mailoo.org

Hello I've been working on a new radial tree layout for Roassal. The code still needs some improvements, but the algorithm seems to work. Here are some screenshots for comparison. I'd like to add Bezier curves to Roassal. Mathieu

12 years, 2 months

5
8
0 0

Videos: FileSystem-Git

by Stephan Eggermont

FileSystem-Git https://www.youtube.com/watch?v=4qld2mDIbg4 and uploading: Taming MongoDB from Pharo

12 years, 2 months

1
0
0 0

Video uploads PharoConf & MooseDay resuming

by Stephan Eggermont

Hi all, Raw versions of Building UIs with Spec https://www.youtube.com/watch?v=P98-qpLUvQQ Data Migration with Moose https://www.youtube.com/watch?v=8SGHV1lCry0 Pharo Roadmap https://www.youtube.com/watch?v=9xRVzzjgPu8 are now online Uploading now is FileSystem-Git

12 years, 2 months

1
0
0 0

Roassal-ComplexShape kick-off

by Juraj Kubelka

Hi all, Hi Doru! There is the kick-off of ComplexShape implementation in Roassal. If you file-in the attached code into https://ci.inria.fr/moose/job/moose-latest-dev-4.8/, you will be able to play with it a bit. There is ROGridBuilderTest test class with two examples. Doru, I suppose you are almost only one who manage Mondrian's complex shapes. Would you please examine the code and give me your opinion? Thank you a lot. … Of course any one can give me some feedback :-) I would appreciate it. For now I focused to do UML Class diagram. I know about blue-prints which can be done similar way. I have not seen other complex shapes. So there is an open space for other requirements which can impact interface and design. Implementation breaks several tests because of change in ROContainer>>encompassingNestedRectangle. I removed a default extent (5@5) which is not wanted. I will fix the tests later when the implementation will be accepted. Thank you for any response or question, Jura [image: Imágenes integradas 1]

12 years, 2 months

4
9
0 0

Bug in Roassal?

by Juraj Kubelka

Hi! I wrote a new test: --- ROHorizontalLineLayoutTest>>testStretch | previous | ROHorizontalLineLayout new stretch; on: elements. previous := nil. elements do: [ :el | previous notNil ifTrue: [ self assert: el position x > previous position x ]. previous := el ]. --- It is the same like ROHorizontalLineLayoutTest>>testLayout. I added #stretch on the first command. Should it work? It breaks in the message ROHorizontalLineLayout>>doStretchHorizontal:, because it expect aGraph and ask for "aGraph bounds" and others. It obtains a collection of elements. Right now I do not understand what aGraph it should obtain. Thanks for any advise, Jura

12 years, 2 months

2
2
0 0

FAMIXSQL and MooseSQL

by Fabrizio Perin

Hi, I did some modifications to Moose-SQL and Famix-SQL to support also create index statements. I was developing on a 4.7 image than I wanted to merge the code on smalltalkhub but I could find the project. Moose-SQL and Famix-SQL have been moved to smalltalkhub or they are still in squeaksource? Thanks, Fabrizio

12 years, 2 months

3
5
0 0

Fwd: [smaltalk-gsoc-students] Call for students

by Tudor Girba

FYI Doru Begin forwarded message: > From: Janko Mivšek <janko.mivsek(a)gmail.com> > Subject: [smaltalk-gsoc-students] Call for students > Date: April 11, 2013 9:01:58 PM GMT+02:00 > To: smalltalk-gsoc-students(a)googlegroups.com > Reply-To: smalltalk-gsoc-students(a)googlegroups.com > > Dear Students, > > Now it is your turn! You will have to register in our website first [1], > put there some information, show interest for the projects and contact > the project mentors. After the registration step you will get all the > mentors information in order to contact them. By pressing the button on > the project, you will show your interest. This is not something formal yet. > > Of course you can propose your own project too. In this case write a > proposal in a format other projects have and send it to admins (see the > email on the bottom). > > Our mentors will vote for the most interesting projects and in the > middle of the voting Google will tell us, how many projects will > actually be funded. Voting will happen in May, with final results > expected at the end of May. At that time you will finally know if you > are accepted or not. > > Of course, there can be many students interested per project. This means > that interest for this project is high, but on the other side a chance > that you will be chosen is lower. It is up to you to convince a mentor > that you are the best! > > Note also that the Ideas page is deprecated. On ideas page just the > project ideas were collected. Now, we are preparing the real projects. > So, please from now on always refer to this link for the projects: > > http://gsoc2013.esug.org/projects > > So, your initial steps are: > > 1. Register on our special Smalltalk GSoC website (with > your Google account!): > > http://gsoc2013.esug.org/admin?view=loginGoogle > > 2. Edit your profile to get some more contact information for > mentors to let you know, > 3. Fulfill your brief Biography page (see Biography tab on profile), > 4. Go to Projects page, choose up to three projects and click there > 'I'm interested' button, > 5. Contact and discuss with project mentors about your interest. > > Subscribe also to a special mailing list [2] where we will help you with > further steps. > > Deadline: as soon as possible, because the deadline to register on > official GSoC website [3] is 3.May, which is, well, soon! But about > that later... > > Finally, we will really appreciate if you can help us to distribute this > call for students. One of our goals is to increase the Smalltalk > community. Those who have access to universities can distribute this > among the students. Distribute also our poster [4] in many languages, > English one attached. > > > [1] http://gsoc2013.esug.org > [2] Students mailing list: > http://groups.google.com/group/smalltalk-gsoc-students > [3] Official GSoC website > http://www.google-melange.com > [4] Poster in PDF and image format, in many languages > http://gsoc2013.esug.org/poster > > > Good luck! > Janko & Serge > > --- > GSoC Admin Team > smalltalk.gsoc(a)gmail.com > http://gsoc2013.esug.org > > > -- > You received this message because you are subscribed to the Google Groups "Smalltalk GSoC students" group. > To unsubscribe from this group and stop receiving emails from it, send an email to smalltalk-gsoc-students+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

12 years, 2 months

1
0
0 0

Fwd: proof that moose guys use waterfall project methodology

by Yuriy Tymchuk

Yes, I was always wandering why the platform is called Moose. Begin forwarded message: > From: Clément Bera <clement.bera(a)inria.fr> > Subject: proof that moose guys use waterfall project methodology > Date: 11 квітня 2013 р. 12:36:27 GMT+02:00 > To: Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > https://9gag.com/gag/4457261 > > -- > Clément Béra > Mate Virtual Machine Engineer > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

12 years, 2 months

1
0
0 0

Build failed in Jenkins: moose-latest-dev-4.8 #239

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/239/> ------------------------------------------ Started by upstream project "roassal" build number 84 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> Deleting project workspace... done [moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson4553338059259466114.sh + bash + wget --quiet -O - http://get.pharo.org/20+vmLatest Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip image.VLXNo/Pharo-20596.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/pharo-linux-latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/image//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/image//PharoV20.sources.zip Creating starter scripts pharo and pharo-ui Please install the 32bit libraries sudo aptitude install ia32-libs + ./pharo Pharo.image save moose-latest-dev-4.8 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-latest-dev-4.8.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=development [31m[33m =============================================================================== Notice: Installing ConfigurationOfMoose development =============================================================================== [0m[0m+ ./pharo moose-latest-dev-4.8.image mooseimagesetup + ./pharo moose-latest-dev-4.8.image moosetest --junit-xml-output [31m[33m =============================================================================== Notice: Running tests in 127 Packages =============================================================================== [0m[0m[31mError: index out of range [0mTabSelectorMorph(Object)>>error: TabSelectorMorph(Morph)>>privateAddAllMorphs:atIndex: TabSelectorMorph(Morph)>>addAllMorphs: TabSelectorMorph>>updateTabs TabSelectorMorph>>extent: TabSelectorMorph(Morph)>>bounds: TabSelectorMorph(Morph)>>layoutInBounds: TableLayout>>layoutLeftToRight:in: TableLayout>>layout:in: PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds LazyTabGroupMorph(Morph)>>submorphBounds in Block: [:m | | subBox | m visible... Array(SequenceableCollection)>>do: LazyTabGroupMorph(Morph)>>submorphBounds LazyTabGroupMorph(Morph)>>privateFullBounds LazyTabGroupMorph(Morph)>>doLayoutIn: LazyTabGroupMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: LazyTabGroupMorph(Morph)>>fullBounds LazyTabGroupMorph(Morph)>>layoutProportionallyIn: ProportionalLayout>>layout:in: in Block: [:m | m layoutProportionallyIn: newBounds] Array(SequenceableCollection)>>do: PanelMorph(Morph)>>submorphsDo: ProportionalLayout>>layout:in: PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@4ce1e2b3:moose-slave at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 97 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…;> lineNumber: 97; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

12 years, 2 months

1
0
0 0

Roassal temporary edges

by Martin Dias

Hello, I have some nodes on a view, and I would like that on ROMouseEnter, some edges are shown, and on ROMouseLeave they disappear. My code is a bit complex, but I can recreate the scenario in a script if you need. Best regards, Martin

12 years, 2 months

4
8
0 0

Need Moose Katas

by Stéphane Ducasse

Hi guys I would really like to get a list of simple questions/actions that we can use to run katas around Moose. Stef

12 years, 3 months

4
3
0 0

Re: ROPopup, views and zIndexes

by Alexandre Bergel

Hi Dennis, Sorry for my late answer. > I looked at the following method: > > ROPopup>>createElementFor: element > ^ ROElement new > add: (ROElement new > + ((ROLabel > text: (text roValue: element model)) color: textColor)) > + box copy; > yourself > > > and noticed some things: > • A ROElement is create inside another. Out of curiosity: why is this necessary? Look at the following example: The popup shows "hello" in a gray background. There are two elements here. The gray background and the white text. > • When doing ROElement new, these elements are NOT added to the same view, the given element is in, thus these elements dont use the same zOrdering. What view is this? Where is it from and why is it a different one? You are very right. The two elements are not added in the same view. It took us some time to come up with that solution. The reason is that you do not want to have the same camera for the view and the popup. Consider the following example: -=-=-=-=-=-=-=-=-=-=-=-= | view el stack | stack := ROViewStack new. view := ROView new. el := ROElement on: 123. el + ROBox. el @ (ROPopup new receivingView: stack). el @ RODraggable. view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ]. view add: el. stack addView: view. stack open -=-=-=-=-=-=-=-=-=-=-=-= Do a bit of clicking on the background and raise the popup. You get something like: The node is large and the popup has its original size. Now, if you remove the "receivingView: stack" as in: -=-=-=-=-=-=-=-=-=-=-=-= | view el stack | stack := ROViewStack new. view := ROView new. el := ROElement on: 123. el + ROBox. el @ (ROPopup new). el @ RODraggable. view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ]. view add: el. stack addView: view. stack open -=-=-=-=-=-=-=-=-=-=-=-= You will have a big popup. Rather ugly isn't it? > • The created elements will have a zIndex of zero, since none is set. > To make popups work in the case a view uses ROBasicZOrdering I changed the method in the following way: > > ROPopup>>createElementFor: element > ^ (ROElement new view: element view; zIndex: element zIndex + 1; yourself) > add: ((ROElement new view: element view; zIndex: element zIndex + 1; yourself) > + ((ROLabel > text: (text roValue: element model)) color: textColor)) > + box copy; > yourself > > > These changes should not affect the normal use case. > > I don't know if this is the correct way to do this, or if there are maybe underlaying issues with zIndex in general which should be adressed first. > > What do you think? If I understand correctly, you want to use the zIndex to always have the popup above the pointed element. Normally, this is not necessary since the popup is the last in the drawing queue (since it is added when a MOMouseEnter is raised). However, I see this is not always the case since you are using zIndexes: you may have elements with a different zIndex and the popup has still 0 as zIndex. But why "+1" ? The popup should be above all the other nodes shouldn't it? It could therefore be 10000 instead no? > I attached the code if you want to merge it in. I have no problem to include your change, I am just trying to figure out the usage scenario first. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 3 months

3
5
0 0

MooseModel+FAMIXClassGroup help

by roberto.minelli＠usi.ch

Hi, I'm building a MooseModel for a development session, in which, by now, I'm just storing some details about the method invocations performed by the user. Apart from the name of the session and other small meta-data, my session knows the receivers (i.e., Smalltalk classes) of the method invocations performed during the session. I'm pretty new to Moose & FAMIX but I managed to have a working MooseModel that I can easily browse in the MoosePanel. Here are the steps I made: - Added pragmas to the Session's field accessors I'm interested in - Added the visit: method - Added the annotation method on the class side Now, I've a problem. The field containing the receivers (i.e., the set of Smalltalk classes which is defined as a property of my MooseModel) is a MooseGroup. My goal is that such property is a FAMIXClassGroup so that I can use some of the utility methods defined for FAMIXClassGroup's to do some data analysis. Any help is appreciated and also feedback about the process I followed to build my MooseModel. Thanks in advance, Roberto

12 years, 3 months

1
0
0 0

MooseSqueakClassPackageImporterTask does not exists anymore

by Dennis Schenk

Hi all, I used to create moose models in the following way: systemName := 'Moose' ^ MooseModel root entityStorage at: systemName ifAbsent: [ model := MooseModel new. model name: systemName. importer := MooseSqueakClassPackageImporterTask new. importer importingContext mergeClassAndMetaclass. importer runCandidateOperator. importer model: model; addFromPackagesNamed: (MooseScripts packageNamesFor: systemName, '*') ; addFromPackagesNamed: (MooseScripts packageNamesFor: 'ConfigurationOf', systemName); runWithProgress. ^ model install ]. But the class MooseSqueakClassPackageImporterTask does no longer exists. What is the correct way to create a moose model? Cheers, Dennis

12 years, 3 months

3
2
0 0

Fwd: Some Radial News

by Stéphane Ducasse

Soem work on the roassal front :) Thanks Mathieu Begin forwarded message: > From: mathieubmddehouck(a)mailoo.org > Subject: Some Radial News > Date: April 9, 2013 2:29:43 PM GMT+02:00 > To: Stephane Ducasse <stephane.ducasse(a)inria.fr>, Alexandre Bergel <abergel(a)dcc.uchile.cl>, Tudor Girba <tudor(a)tudorgirba.com> > > Hello > > > I've worked on radial tree, and i have good results. > > The code needs improvements, but it does work well. > > > I'll add bezier curves tomorrow I hope. > > > And then I'll focus on force based. > > > But what do you want the force based layout to do ? > > I mean there's already one, so what does not work with it ? > > > I've add some picture of my work. > > > Mathieu > >

12 years, 3 months

7
6
0 0

Accessing the common hierarchy

by roberto.minelli＠usi.ch

Hi, When I was at the PharoConf + MooseDay, Doru in one of his talks used a really cool method to, given a set of classes, provides all the common superclasses to build a cool system complexity. Any of you remembers or knows that message? Thanks in advance, Roberto

12 years, 3 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