objectprofile / roassal2 Goto Github PK

Issue by bergel
Thursday Aug 03, 2017 at 00:27 GMT
Originally opened as moosetechnology/Moose#1254

We need something like:

g := RTGrapher new.

d1 := RTData new.
d1 noDot .
d1 connectColor: Color blue.
d1 points: #(1 2 4 5 6 10).
d1 y: #yourself.
g add: d1.

d1 := RTData new.
d1 noDot .
d1 connectColor: Color red.
d1 points: #(1 -3 3 5 9 10).
d1 y: #yourself.
g add: d1.

g addDecorator: (RTContinuousPopup ...)

g

When doing mass exporting of figures using RTSVGExporter some of them could be empty. It would be nice to have a method to check this condition, for example: hasShapes or to allow exporting empty figures

See screenshot for details:

Hi, since the works on Roassal2 stopped in favor to Roassal3, I would like to ask for making a (final?) release. For Pharo8. I try to avoid using master itself, so I point to specific commit, but it would be nice if we had a release of current state of Roassal2.

Issue by bergel
Saturday Jun 17, 2017 at 12:40 GMT
Originally opened as moosetechnology/Moose#1231

There are some existing algorithms:
http://www.sciencedirect.com/science/article/pii/S0020025507000989
http://rp-www.cs.usyd.edu.au/~visual/valacon/pdf/papers/APVIS05-UsingSpringToRemoveNodeOverlapping.pdf

We need a solution for this. It is a recurrent complain.

@dusty on discord would like to have it

| data b s d |
data := OrderedCollection new.
data add: (OrderedCollection with: 'Main Item' with: 2458135 with: 2459200).
data add: (OrderedCollection with: 'Sub Item 1' with: 2458235 with: 2459100).
data add: (OrderedCollection with: 'Sub Item 2' with: 2458335 with: 2458900).
data add: (OrderedCollection with: 'Sub Item 3' with: 2458435 with: 2458800).
data add: (OrderedCollection with: 'Sub Item 4' with: 2458535 with: 2458700).
data add: (OrderedCollection with: 'Sub Item 5' with: 2458635 with: 2458700).

minValue := 2458135.
b := RTTimeline new.
s := RTTimelineSet new.
s objects: data reverse.
s lineIdentifier: #first.
s start: [ :da | da second - minValue ].
s end: [ :da | da third - minValue ].
b add: s.
b axisX
    numberOfLabels: 10;
    labelRotation: -45;
    labelConversion: [ :v | (Date julianDayNumber: v + minValue) ].
d := RTVerticalTickLineDecorator new.
d shape line color: Color white.
b addDecorator: d.
b build.
^ b view

Roassal extends some system traits that were flattened in Pharo 7. Such extensions should be placed in the users of the original traits

Some tests in Roassal do not pass QA checks

• setUp/tearDown should be in running protocol
• setUp should call super setUp
• tearDown should call super tearDown at the end

Issue by bergel
Tuesday Apr 18, 2017 at 16:37 GMT
Originally opened as moosetechnology/Moose#1183

Consider the following code:

v := RTView new.
lbl := RTLabel new fontName: 'Bitmap DejaVu Sans'; elementOn: 'Hello World'.
v add: lbl.
v

It produces what is shown on the screenshot.

However, what is displayed is not DejaVu Sans. E.g., compare the "e" with https://www.fontsquirrel.com/fonts/dejavu-sans

Issue by bergel
Tuesday Nov 21, 2017 at 00:33 GMT
Originally opened as moosetechnology/Moose#1272

Peter asked: is there a way to modify RTDraggableView to support dragging via middle click or left click?

I'm trying to do something with Roassal, and it just crashes my image.
Here are the steps of what I did:

1. Installed a fresh Pharo 6.1 64-bit image using Pharo Launcher on Mac
2. Installed Roassal2 using the Metacello script from Roassal's GitHub: https://github.com/ObjectProfile/Roassal2#pharo
3. Opened World Menu > Roassal > Roassal examples > Geographical maps

On the last step, my image crashes.

Issue by bergel
Monday Apr 24, 2017 at 10:54 GMT
Originally opened as moosetechnology/Moose#1188

There are some good ideas here: https://github.com/d3/d3-scale-chromatic

The following code raises an error. The reason is that normalizeLineWidth: changes the model of the line. Which is wrong.

data := #(1 2 3 4 5).
edges := { 1 -> 2 . 1 -> 4 . 2 -> 3 . 3 -> 4 . 4 -> 5 . 2 -> 4 }.

b := RTMondrian new.
b shape circle.
(b nodes: data) @ RTLabeled.

b shape line
	if: [ :assoc | (assoc key + assoc value) even ] color: Color red.
edgeElements := 
	b edges 
		useAssociations: edges.
b layout circle.
b normalizer
	edges: edgeElements;
	normalizeLineWidth: [ :from :to | from + to ].

b 

Issue by girba
Friday Jun 09, 2017 at 08:32 GMT
Originally opened as moosetechnology/Moose#1222

Take a look at this script:
http://ws.stfx.eu/54G9IO1XX4R2

The issue is that instead of aligning the top left, it kind of centers the entities from the same layer.

This used to work properly, and the tree algorithm did not change. So something must have changed not too long ago related to translations.

Acá algunas sugerencias para Roassal3

seria genial tener un script que combine caracteristicas de RTShapeBuilder RTShape y RTInteractionBuilder

shape := RTShape box.
shape size: [:model | self computeSizeForModel: model ].
shape if: #hasChildren color: Color red.
shape position: [:model | model position ].
shape if: #hasChildren size: 10.
shape theme: RTSuperCoolTheme.

shape popup.
shape when: TRMouseClick do: [:evt | ...].

elements := shape elementsOn: models.
elements first rawShape: RTShape ellipse.

view addAll: elements.

Hi, trying to do some graphs for my graduation project I've found that whereas the vertical decorators do support color settings (via the RTAbstractVerticalValuesDecorator>>#labelColor: accessor), the horizontal decorators don't 😞

I think this shouldn't be that hard, just adding the corresponding instance var and accessors for RTAbstractHorizontalValuesDecorator>>#labelColor: and actually using them for rendering should do the trick. Maybe I'll make a Pull Request when I have more time (or maybe not lol).

Issue by bergel
Monday Dec 11, 2017 at 14:30 GMT
Originally opened as moosetechnology/Moose#1273

Dusty on Discord suggested to use foreign objects. He says:
"creating SVG for web interfacces, like I'm doing the graphical rendering in roassal, but exporting the SVG to a web interface. I'd like to make the blocks clickable (via <a ...> tag) to open properties of the item in the web app"
"also, forienobject would allow for title= or <title> tag for hover"

We should have a look at this.

Issue by bergel
Tuesday Apr 18, 2017 at 16:30 GMT
Originally opened as moosetechnology/Moose#1182

The following GitHub produces some functions and methods that do not have a number of lines of code:
https://github.com/radio-astro-tools/spectral-cube

Issue by bergel
Thursday Apr 20, 2017 at 19:54 GMT
Originally opened as moosetechnology/Moose#1185

Apparently it is not

g := RTGrapher new.
d := RTData new.
d interaction toggleDataset.
d points: (0.0 to: 5.0 by: 0.1).
d y: #yourself.
g add: d.
g

Does not seem to do much.

Issue by bencoman
Monday Feb 27, 2017 at 12:46 GMT
Originally opened as moosetechnology/Moose#1153

@bergel, Most of the explora examples have some problem with adjusting the viewport after expanding elements.

World > Roassal examples > Explora > CircularList

Starts with one big circle. Right-Clicking on it ==> viewport is now blank. Translating the view up via left-drag finds two circles a page below. The circles are original size, so you can't see both ends of link at the same time.

In addition, Left-Clicking the original single circle moves focus to a new inspector pane.

Either the viewport should scale to the whole graph, but if there are many children each might end up too small to observe; Or, scale viewport to the min of the x & y directions; Or scale viewport to the sum length of the edges in the path from original to leaf node.

http://holoviews.org/user_guide/Large_Data.html

Issue by bergel
Tuesday Jun 13, 2017 at 17:00 GMT
Originally opened as moosetechnology/Moose#1230

Edge width indicating dependence between packages.

Here is an examples for classes:

b := RTMondrian new.
b shape circle size: 20; color: Color red trans.
b nodes: RTObject withAllSubclasses.

b shape line color: Color blue trans.
es := b edges connectToAll: #dependentClasses.
b layout force charge: -500.
b normalizer 
    edges: es;
    normalizeLineWidth: [ :from :to | 
        | outgoingRef |
        outgoingRef := (from methods flatCollect: [ :cm | cm literals select: [ :l | l class == GlobalVariable ] ]) groupedBy: #value.
        (outgoingRef keys includes: to)
            ifTrue: [ (outgoingRef at: to) size ]
            ifFalse: [ 0 ] ] min: 0.2 max: 10.
b

RTOSM buildingsAndStreamKampungMelayu -> expecting 193 but got 194

Issue by bergel
Monday Feb 27, 2017 at 00:52 GMT
Originally opened as moosetechnology/Moose#1152

Agree. Not only in Overall, in general with more than 4 figure previews at the same time, they became too small.

Cheers,

Hernán

2017-02-25 10:38 GMT-03:00 Ben Coman [email protected]:
Just some quick feedback... in the "Moose Suite 6.0 (beta)" image from PharoLauncher I opened World > Roassal > Roasasal Examples

Nice interface, but for the category "Grapher - Overall" I find there are too many items,
such that even the text labels are too small to read. It might be better to split this out to a few more categories.

cheers -ben

Hello,
Roassal2 has dependency on Geometry project from https://github.com/peteruhnak/geometry. Modified version of Geometry project has been recently adopted by Pharo ( https://github.com/pharo-contributions/Geometry ) and integrated into the main image. Roassal3 depends on this new Geometry repository from pharo-contributions and the same Roassal3 is used for drawing diagrams in Calypso.

Loading Roassal2 causes replacing the new Geometry repository by the old one, causing Roassal3, and therefore Calypso, to not work properly and causing errors when using the Calypso.

Steps to reproduce:

1. Download and open fresh Pharo 9 image
2. Load current Roassal2 into the image
3. Open Calypso (System Browser)
4. Find and select (click on) any Baseline package (for example BaselineOfAthens)
5. Select (click on) the Baseline class (for example BaselineOfAthens)
6. Click on tab Baselines-Graph
   Result: Error "Instance of GEllipse class did not understand #center:vertex:coVertex:"
   Note that sometimes the error occurs even before the step 5 or 6.

It is possible that Roassal2 would work even with current implementation of Geometry, but that would require multiple modifications. @hernanmd attempted to solve this by making fork of Peter Uhnak's repo and renaming everything to prevent names conflicts in his fork of Roassal2: https://github.com/hernanmd/Roassal2/commits/master
His solution seems to be working.

Issue by bergel
Friday Mar 24, 2017 at 17:28 GMT
Originally opened as moosetechnology/Moose#1165

Check if RTGraphVizLayoutPlugin works

Issue by bergel
Thursday May 04, 2017 at 14:37 GMT
Originally opened as moosetechnology/Moose#1197

Apparently, the structure of the meta-information have changed. The class needs to be updated

Issue by peteruhnak
Tuesday Jun 20, 2017 at 13:49 GMT
Originally opened as moosetechnology/Moose#1234

RTBorderAttachPoint has glitchy behavior when offset is used.

| v e1 e2 l1 l2|
v := RTView new.

e1 := RTLabel new elementOn: #RTBorderAttachPoint, ' left'.
e2 := RTLabel new elementOn: #RTBorderAttachPoint, ' right'.
e2 translateBy: 500 @ 0.
v add: e1; add: e2.
l1 := RTLine new
    attachPoint: (RTBorderAttachPoint new offset: 20);
    edgeFrom: e1 to: e2.
l2 := RTLine new
    attachPoint: (RTBorderAttachPoint new offset: 20);
    edgeFrom: e1 to: e2.
v add: l1; add: l2.

v elements @ RTDraggable.

^ v

Issue by bergel
Friday Mar 03, 2017 at 22:03 GMT
Originally opened as moosetechnology/Moose#1156

Should be available from the Menu in the playground

Issue by seandenigris
Monday Aug 03, 2015 at 18:35 GMT
Originally opened as moosetechnology/Moose#1108

Originally reported on Google Code with ID 1108

Package Core defines the abstract class RTObject.
Package ExampleBrowser defines the abstract class RTAbstractExample as subclass of
RTObject. 

The problem is that package Core also includes class RTMultiColoredLineExample as a
subclass of RTAbstractExample. So package ExampleBrowser requires package Core because
of RTObject, and package Core requires package ExampleBrowser because of RTAbstractExample.

The solution could be to move class RTMultiColoredLineExample to package ExampleBrowser?

This leads to cyclic dependencies, that at least in the Visualworks port lead to warnings
and bundle structure errros.

Please fill in the labels with the following information:
* Type-Defect
* Component-Roassal

Reported by [email protected] on 2015-03-03 09:30:16

We should have the following behavior:

g := RTGrapher new.

d := RTData new.
d connectColor: Color blue.
d noDot.
d areaColor: Color orange.
d points: (-3.14 to: 3.14 by: 0.1).
d y: #sin.
d x: #yourself.
g add: d.

g axisX numberOfTicks: 10; numberOfLabels: 5.

g

Issue by bergel
Wednesday Jun 21, 2017 at 14:02 GMT
Originally opened as moosetechnology/Moose#1240

b := RTMondrian new.
b shape labeledBox
    borderColor: Color black;
    textHeight: 2.
    
b nodes: (1 to: 10).
b

Probably it is a problem of asIntegerPoint somewhere

Issue by bergel
Wednesday May 02, 2018 at 17:16 GMT
Originally opened as moosetechnology/Moose#1293

Increating the 30 to 100 does not show anything. We should be able to drag the background and see the graph content and the axes adjusted accordingly.

r := Random seed: 10.
data := OrderedCollection new.
1 to: 30 do: [:i | | datum r1 r2 |
    r1 := r next * 100.
    r2 := r next * 100.
    datum := OrderedCollection with:  ('c',i asString) with: (r1 min: r2) with: (r1 max: r2).
    data add: datum
].    
b := RTTimeline new.
s := RTTimelineSet new.
s objects: data.
s lineIdentifier: #first.
s start: #second.
s end: #third.
b add: s.
b axisX
    numberOfLabels: 15;
    labelRotation: -45;
    labelConversion: [ :v | v ceiling ].
b build.
^ b view

Issue from Moose moosetechnology/Moose#1186

It is an obsolete class

Issue by bergel
Thursday Nov 09, 2017 at 11:33 GMT
Originally opened as moosetechnology/Moose#1271

https://datavizcatalogue.com/methods/violin_plot.html

Issue by bergel
Friday May 05, 2017 at 18:39 GMT
Originally opened as moosetechnology/Moose#1199

titleExtension
	^ 'PNG with scale'	

is obscure. Maybe something like visible part and not scale

thanks Juraj for having spotted it!

The class RTEventRegister uses a class that was removed from Pharo 8 so Roassal cannot load anymore in Pharo 8.

Issue by bergel
Sunday Apr 30, 2017 at 17:24 GMT
Originally opened as moosetechnology/Moose#1195

A more flexible handling of colors using definable color schemes or palettes or some like means sounds interesting though. We currently have made changes to Roassal to adjust some constantly defined colors, like eg. tooltip background, to our needs/wishes which could be more elegantly solved by definable color schemes.

Trying to get it to work on macOS 12.5 (Intel), but I keep getting UHEs at #nsBitmap.

The bundle comment for Roassal2 says:

On Windows (7 through 10), this version of Roassal requires Cairo library version 1.10.2 (provided in VisualWorks 8.3 and after) and does not work with version 1.14.2. Both versions of the Cairo library are provided in VisualWorks 8.3.1 and after, with the relevant ExternalInterface class definition data set to see the older version. With a small code change, a knowledgeable user can move to the new version and load a later compatible version of Roassal from the Cincom Open repository, should they so wish.

There are several issues here:

(1) brew cannot find Cairo 1.10.x

(2) The library isn't provided in VisualWorks, as the bundle comment says (unless 'library' actually means 'parcel' and it's "OpenGL-CairoGraphics"...?)

(3) The "small code change" isn't explained.

(4) Most of the packages don't have comments.

How to make this work?

The world menu entries need to have help text. It is required by the release QA checks

Please add them for the next version release so I can easily declare a dependency on a specific Roassal version in my projects' baselines 😄

Also it would be a good idea to have a 'stable' branch or something similar, just to make sure a random commit doesn't break the installation of other projects.

Issue by bergel
Tuesday Mar 21, 2017 at 20:15 GMT
Originally opened as moosetechnology/Moose#1163

we should eventually also get rid of this nonsense
headStart: RTNoDecorationShape asHead;
headEnd: RTNoDecorationShape asTail;

… the method should correctly convert it to the proper head/tail… the user shouldn't be bothered by it

Issue by bergel
Thursday May 11, 2017 at 14:51 GMT
Originally opened as moosetechnology/Moose#1202

Applying a layout make takes time. It would be great to be able to save node positions and apply them again. This could be done, for example, using a hook in RTLayout.