Moose-dev December 2012

moose-dev@list.inf.unibe.ch

15 participants
126 discussions

Issue 870 in moose-technology: ROFocusView focuses on the wrong spot

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Roassal Component-Glamour New issue 870 by tu...(a)tudorgirba.com: ROFocusView focuses on the wrong spot http://code.google.com/p/moose-technology/issues/detail?id=870 Open a Roassal Easel and paste this: | node | node := view node: #a. ROFocusView new on: node view: view raw. The node is selected somewhere at the bottom. The reason is likely to be that the canvas has a static size, instead of adapting by default to the size of the surrounding pane

11 years, 6 months

Issue 894 in moose-technology: Roassal revised ROSelection and example

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 894 by benjamin...(a)gmail.com: Roassal revised ROSelection and example http://code.google.com/p/moose-technology/issues/detail?id=894 Initially I contributed ROSelection as part of the rubberbanding feature. The attached changeset generalizes it a bit and provides the folllowing example of its use. ------------- activeSelection := ROSelection new onInclusion: [ :element | ROHighlightElement on: element color: Color red ]; onExclusion: [ :element | ROUnhighlightElement on: element ]. statusBar := (ROElement on: activeSelection) + (ROLabel text: [ :el | el model asString ]) + ROBox white. view stack add: statusBar. statusBar translateTo: 0 @ 480. view shape label. view interaction on: ROMouseLeftClick do: [ :ann | activeSelection clear. activeSelection add: ann element. ]. view nodes: #(1 2 3 4 5). view gridLayout. --------------- There are two things I need help with: 1. Deselecting all elements when clicking on the background.** 2. Multiple selection, which if I knew the right way to work with the announcement events, would conceptually be as simple as the following modification... [ :ann | ann isShiftClicked ifFalse: [ activeSelection clear ]. activeSelection add: ann element. ]. **may also relate to Issue 884 comment #9 . Attachments: ROSelectionAndExample.1.cs 1.4 KB

11 years, 7 months

Issue 895 in moose-technology: Lack of entities in verveineJ model

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.7 New issue 895 by andreho...(a)gmail.com: Lack of entities in verveineJ model http://code.google.com/p/moose-technology/issues/detail?id=895 I'm parsing the single .java attached file (I have also copied in the end of this message), and I have some points: - A stub class FileUtils is not created. As consequence the receiver os the static invocation "FileUtils.close(ti)" (see last line) is "nil". - A stub class ArchiveScanner (superclass) is not created. What do you think about that? In addition (I believe it is OK): - A stub class Map is created as FAMIXParameterizableClass (it should just be used to Generics, no?). - A 'V' FAMIXParameterType is created - A Comparable is created as FAMIXParameterizedType Maybe these three points are coming from the class Map in Java, then it is OK. Basically this is the code attached: ========= public class TarScanner extends ArchiveScanner { ... protected void fillMapsFromArchive(Resource src, String encoding, Map fileEntries, Map matchFileEntries, Map dirEntries, Map matchDirEntries) { TarEntry entry = null; TarInputStream ti = null; try { try { ti = new TarInputStream(src.getInputStream()); } catch (IOException ex) { throw new BuildException("problem opening " + srcFile, ex); } while ((entry = ti.getNextEntry()) != null) { Resource r = new TarResource(src, entry); String name = entry.getName(); if (entry.isDirectory()) { name = trimSeparator(name); dirEntries.put(name, r); if (match(name)) { matchDirEntries.put(name, r); } } else { fileEntries.put(name, r); if (match(name)) { matchFileEntries.put(name, r); } } } } catch (IOException ex) { throw new BuildException("problem reading " + srcFile, ex); } finally { FileUtils.close(ti); } } ... =========

11 years, 7 months

importers page

by Tudor Girba

Hi, I created a page dedicated to importing instructions: http://www.moosetechnology.org/docs/importers A good example of how these instructions should look like can be found here: http://www.moosetechnology.org/docs/importers/importJavaWithinFusion We would need more detailed information about: - Import C# with PMCS http://www.moosetechnology.org/docs/importers/importCSharpWithPMCS - Import C with CAnalyzer http://www.moosetechnology.org/docs/importers/importCWithCAnalyzer Cheers, Doru -- www.tudorgirba.com "Obvious things are difficult to teach."

11 years, 7 months

Issue 845 in moose-technology: some Roassal layouts broken when nested

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 845 by google....(a)ben.coman.com.au: some Roassal layouts broken when nested http://code.google.com/p/moose-technology/issues/detail?id=845 The application I am developing needs to apply layouts to nested elements. I noticed that some layouts did not work when nested - so I've done a full review of the layout listed in ROMondrianExample>>chooseLayoutOn: as per the attached image. On the left is the non-nested-result and on the right is the nested-result. I have attached the mcz with a slightly modified #chooseLayoutOn: as well as #chooseLayoutNestedOn: for comparison. Attachments: Roassal-BenComan.313.mcz 241 KB ROMondrianExample-chooseLayoutNestedOn.png 127 KB

11 years, 9 months

Re: Issue 382 in moose-technology: CMD + W does not close Mondrian window

by moose-technology＠googlecode.com

Comment #1 on issue 382 by tudor.gi...(a)gmail.com: CMD + W does not close Mondrian window http://code.google.com/p/moose-technology/issues/detail?id=382 This is still an issue and it hinders usability. Alex, could you take a look at it?

11 years, 9 months

Issue 871 in moose-technology: One click distribution has old vms

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium OpSys-All Milestone-4.7 New issue 871 by tu...(a)tudorgirba.com: One click distribution has old vms http://code.google.com/p/moose-technology/issues/detail?id=871 We need to update the VMs for the one click distribution.

11 years, 9 months

Issue 881 in moose-technology: Missing browser instance variable

by moose-technology＠googlecode.com

Status: Accepted Owner: kurs....(a)gmail.com CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-PetitParser New issue 881 by kurs....(a)gmail.com: Missing browser instance variable http://code.google.com/p/moose-technology/issues/detail?id=881 PPParserBrowser and PPAllParserBrowser are missing browser instance variable, since the supperclass was changed from BrowserTemplate to CompsoitePresentation (PetitGui.107). I presume, this is minor issue, but I have no idea why it was changed from Template to CompositePresentation.

11 years, 9 months

Issue 872 in moose-technology: Roassal refactor RubberBand>>onDrop:

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 872 by benjamin...(a)gmail.com: Roassal refactor RubberBand>>onDrop: http://code.google.com/p/moose-technology/issues/detail?id=872 ROExample>>rubberBandOn: currently has the line... rawView add: (newEdgeRaw + ROLine). While this is fine in the ROExample script, in my application rawView was not available at that point, so instead I needed... newEdgeRaw from view add: (newEdgeRaw + ROLine). For a while I confused myself by trying to use... newEdgeRaw view add: (newEdgeRaw + ROLine). but that was not the same view, since the ROEdge created in the sender had a random default. So I now think it is more clear to not create the ROEdge in the sender, but instead pass the fromElement and toElement and let the user create the ROEdge themselves. I think this is conceptually clearer. See the two methods in the attached changeset. Attachments: RubberBand-20121125.1.cs 2.4 KB

11 years, 9 months

Issue 858 in moose-technology: Roassal contribution ROLineEndDiamond

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 858 by benjamin...(a)gmail.com: Roassal contribution ROLineEndDiamond http://code.google.com/p/moose-technology/issues/detail?id=858 I needed a diamond line end symbol to represent aggregation in a UML diagram, so here it is attached. Name: Roassal-BenComan.364 Ancestors: Roassal-AlexandreBergel.363, Roassal-BenComan.353 Merge addition of ROLineEndDiamond and ROMondrianExample>>umlAggregateOn: into mainline (though actually it more catching up ready to merge into mainline). Though upon further consideration perhaps 'LineEnd' is not proper, since someone might want to use it in the middle of a line. Perhaps better RODiamondLineShape or ROLineShapeDiamond or ROLSDiamond. btw, since there are many more symbols associated with lines than just arrows, perhaps consider renaming class ROAbstractArrow something like one of: ROAbstractLineEnd; ROAbstractLineSymbol; ROAbstractLineShape; ROLineShape.

11 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2012