Moose-dev February 2013

moose-dev@list.inf.unibe.ch

21 participants
145 discussions

Issue 858 in moose-technology: Roassal contribution ROLineEndDiamond
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

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.

1 4

Issue 856 in moose-technology: ROAbstractElement>>remove inconsistent nested behaviour
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 856 by benjamin...(a)gmail.com: ROAbstractElement>>remove inconsistent nested behaviour http://code.google.com/p/moose-technology/issues/detail?id=856 I would expect ROAbstractElement>>remove to work consistently whether it belongs to the top-level view or nested in another element. However it is not as demonstrate by the code below having this result... a ROElement<#x> ------ a ROElement<#x> a ROElement<#y> ========================================= v := ROView new. x := ROElement on: #x. y := ROElement on: #y. v add: x. v add: y. "this line different" y remove. v allElementsDo: [ :el | Transcript crShow: el ]. Transcript crShow: '------'. v := ROView new. x := ROElement on: #x. y := ROElement on: #y. v add: x. x add: y. "this line different" y remove. v allElementsDo: [ :el | Transcript crShow: el ].

1 2

Issue 852 in moose-technology: RORubberband with target highlighting
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 852 by benjamin...(a)gmail.com: RORubberband with target highlighting http://code.google.com/p/moose-technology/issues/detail?id=852 I have added highlighting of target elements to RORubberband - changeset attached. Note changeset is against Roassal-AlexandreBergel.343.mcz since .344 breaks something. Note2, I renamed RORubberbanding to RORubberband. I had originally been tossing up between the two, and under further consideration I think the latter is more appropriate. The former will need to be manually removed. Attachments: RubberBand2.3.cs 5.9 KB

1 8

Issue 849 in moose-technology: Roassal rubber-banding
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 849 by benjamin...(a)gmail.com: Roassal rubber-banding http://code.google.com/p/moose-technology/issues/detail?id=849 As a new feature for Roassal, I would like to be able to interactively drag what I term a rubberband (you may have a better one?) from one element to another to create and edge between them. I had previously implemented this on original Mondrian but I think only in my image. I don't think it made it to the Mondrian trunk. As a starting point of discussion I have attached an extracted changeset from my image - mostly so that it can be browsed for inspiration in a plain text editor. One key part of the Mondrian implementation was using MOCanvas>>drawOn: to draw the rubberband every cycle as well as being outside of the main graph. However there is no corresponding #drawOn: on any of the RO-canvases. The changeset shows the use by the application of two entry points #dropRubberBandFrom and #dropRubberBandOn:. Rubber bands can be dragged from EpcimTerminal elements to EpcimConnectivityNode elements. Method #addSubViewTo: was my own application-way of splitting up graph creation to the elements of the graph. I've done this a bit different for updating my application from Mondrian to Roassal and the reference implementation for this should preferably use "GLMRossalInteractive" I have manually re-ordered the changeset so that the order that methods are used go generally from top to bottom. However the best starting point would be to scroll down to look at MOCanvas>>drawOn: and MOCanvas>>rubberBand:, then back up to look at the EpCim* classes, the the two MOAnnouncer methods.

1 7

Issue 846 in moose-technology: Roassal Easel Find... button
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 846 by google....(a)ben.coman.com.au: Roassal Easel Find... button http://code.google.com/p/moose-technology/issues/detail?id=846 With the following steps in Roassal.AlexandreBergel.320 1. World > Tools > Roassal Easel 2. <Example> > ROExample > #basic > lines 3. <Find...> > Node1 > Node2 produces an "Error: not found" from RONullShape. I am guessing this should be working in this example.

1 2

Issue 843 in moose-technology: ROLightlyHighlightable drains element colour
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 843 by google....(a)ben.coman.com.au: ROLightlyHighlightable drains element colour http://code.google.com/p/moose-technology/issues/detail?id=843 The following code snippet results in the attached image, showing that ROLightlyHighlightable drains the original colour from el2 - leaving it drab and dreary. I think we need to liven up the party for poor old el2, and give him back his colour. -------------------- el1 := (ROElement on: 1) height: 50; width:50. el1 + (ROCircle color: Color lightGreen). el2 := (ROElement on: 1) height: 50; width:50. el2 + (ROCircle color: Color lightGreen) @ ROLightlyHighlightable. rawView := ROView new @ RODraggable. rawView add: el1. rawView add: el2. ROHorizontalLineLayout on: rawView elements. rawView open. -------------------- Attachments: ROLightlyHighlightable-drains-colour-from-element.png 3.6 KB

5 14

Issue 842 in moose-technology: ROTranslatingShape mouse hotspot mis-alignment
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 842 by google....(a)ben.coman.com.au: ROTranslatingShape mouse hotspot mis-alignment http://code.google.com/p/moose-technology/issues/detail?id=842 Fix attached related to the following mail-posts Also attached are before and after snapshots from ROExample>>nestingTranslate. Ben Coman wrote: > I was trying to apply ROTranslatingShape to produce a label sitting above > the > children nodes. To understand it better how to get what I > need, I made ROExample>>nestingTranslate to show a permutation of the > order > the shapes can be applied. I have attached a screen snapshot and fileout > for > this. The case I am particularly interested in is el3. > The 'el0' case is the reference without any ROTranslatingShape. > When running the example hover near and over the inner elements to view > the > misalignment of the mouse hotspot. I have marked the approximate offset in > green in the snapshot. > I notice that the existing call chain goes... > ROView>>localElementAt: > ROElement>>elementAt: > ROElement>>contains: > ROElemenet>>bounds > ROShape>>extentFor: (union of extent of each shape) > It seems to me the hotspot misalignment is related to the translation > being > applied at the shape draw level whereas the #contains: checking is done > at the > element level. This relies on the union of the shape extents to set the > element bounds, but I can't see how that extent union could be modified to > account for the translation - particular in the case of a negative > translation > since extents throw away information > about any negative offset. > So I thought perhaps that the element #contains: checking needs might be > better chained through the shaped, so that the translation > could be applied similar to ROTranslatingShape>>chainedDrawOn:for: and > that > this would not cause any/much additional computation since all the shapes > were > being cycled through anyway for #extentFor: > Something like... > ROView>>localElementAt: > ROElement>>elementAt: > ROElement>>contains: > ROShape>>chainedContains:For: (for each shape) You can see in all case el1 to el8, the child elements have shifted in relation to el0. However the hotspot remains aligned with the location in el0. I think part of the problem is that ROChildrenShape is a ROAbstractEndingShape and is always at the end of the line - so the translation is applied to the children elements. Whereas it might work better if the position of the child elements was not affected by ROTranslatingShape, such that it becomes the reference for the position of any other translated shapes. This would require ROChildrenShape be always the first shape of an element, rather than always be the last shape. -------------------- The following code snippet... el := ROElement on: 1. (el + ROBorder + ROTranslatingShape + ROLabel ) inspect. produces shapes chained in order of: ROLabel-->ROTranslatingShape-->ROBorder-->ROChildrenShape. which seems reversed from what I would intuitively expect reading the code left to right. I think ideally the shape chain would be: ROChildrenShape-->ROBorder-->ROTranslatingShape-->ROLabel-->RONullShape Otherwise as in el1 you can see the position of the label is the same as el0, since the label has actually been drawn first prior to the translation, and instead the translation is applied to the border and child elements, the latter of which affects the mouse hotspot. Attachments: Roassal-BenComan.310.mcz 242 KB ROTranslatingShape-permutations-mouse-hotspot-broken.png 33.2 KB ROTranslatingShape-permutations-mouse-hotspot-fixed.png 29.8 KB

3 29

Issue 841 in moose-technology: Roassal: ROPopup: Text not visible
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 841 by hephster(a)gmail.com: Roassal: ROPopup: Text not visible http://code.google.com/p/moose-technology/issues/detail?id=841 See the example in Roassal Easel: Interaction -> Popup. The popup is always gray with no text visible.

1 2

Issue 840 in moose-technology: ROCircle border only
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 840 by google....(a)ben.coman.com.au: ROCircle border only http://code.google.com/p/moose-technology/issues/detail?id=840 Could you include in Roassal the ability to have a non-filled circle. See attached. Attachments: ROCircle.1.cs 1.4 KB

1 3

Issue 839 in moose-technology: ROCenteredLabel
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 839 by google....(a)ben.coman.com.au: ROCenteredLabel http://code.google.com/p/moose-technology/issues/detail?id=839 I required text to be centered within a circle, so I created ROCenteredLabel. I think it would be generally useful. Would you consider adding it to Roassal? Attachments: ROCenteredLabel-drawOnfor.st 1.0 KB

1 5

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev February 2013