Hi all!
I want to make a visualization of a graph (nodes and edges), but applying
ForceLayout to it takes forever, because the graph has too many elements.
if I apply TreeLayout, for example, the view renders almost instantly. Is
there some other Layout, similar to ForceLayout, but faster, for so many
elements?
Thanks!
Hi,
Few days ago I built a view using the class RTData.
With the last version of Roassal.. puff... disappeared…
I read the discussion 'New RTData class in Roassal’ and it looks is the one to use. Am I right?
Cheers,
R
Hello,
I was checking on FAMIXSQL and there is this test class that fails
becuase it depends on the PetitSQLIslandParser package. I think this
class is not belong here. Can we move it into a PetitSQLIslandParser
package?
Thanks and cheers,
Fabrizio
Dear all,
I have created a class RTConditionalLayout and it is into the Layout Builder.
Consider the following example:
-=-=-=-=-=-=-=-=-=
v := RTView new.
es := (RTEllipse new
size: 30;
color: [ :value | value odd ifTrue: [ Color red ] ifFalse: [ Color blue ] ])
elementsOn: (1 to: 4).
v addAll: es.
l := RTConditionalLayout new
condition: [ :element | element model odd ];
thenLayout: RTVerticalLineLayout new;
elseLayout: RTHorizontalLineLayout new.
l on: es.
v
-=-=-=-=-=-=-=-=-=
The idea is to have a layout that segregate some elements that match a particular condition.
This is supported in the Layout builder, which allows one to do (using RTMondrian in that case):
-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle
fillColor: Color white;
borderColor: Color lightGray;
withTextAbove: #name.
b nodes: Collection withAllSubclasses forEach: [ :cls |
b nodes: cls methods.
b edges connectToAll: #dependentMethods.
b layout
ifElement: #isConnected then: RTTreeLayout new;
else: RTGridLayout new.
].
b edges connectFrom: #superclass.
b layout tree.
b
-=-=-=-=-=-=-=-=-=
The issue here is that I have introduced a mechanism to do ‘if’ statements. I am not sure this is the best things…
Comments are welcome :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear All,
RTEdgeBuilder has been completely rewritten. You can now specific objects and elements from where edges begins and edges. The API is about 70% the same I believe.
Migration of your code should be fairly easy. Else, ask for help.
In any case, the old builder is named: RTEdgeBuilderDeprecated
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All
Not sure if this is a bug, but here goes.
Looking through the Glamour examples in Pharo4 I come across the
Updateable Browser example.
This example has a line that, when the collection is greater than 1,
shows a list tab, the title of which is List, col size printString.
This indeed comes up and shows: 'List: 2' but if you continue to add, it
doesn't change. The text will change but not the title.
I came across this when I couldn't get my browser to add tabs, even
though entity gets updated.
Example from Glamour below.
| browser collection|
collection := GLMAnnouncingCollection new.
collection add: 1.
browser := GLMTabulator new.
browser column: #preview.
browser
act: [:b | b entity add: (b entity size + 1). b update ]
icon: GLMUIThemeExtraIcons glamorousAdd
entitled: 'Add an item in the collection'.
browser
act: [:b | b entity removeLast. b update ]
icon: GLMUIThemeExtraIcons glamorousRemove
entitled: 'Remove last item from the collection'.
browser
updateOn: GLMItemAdded from: #yourself;
updateOn: GLMItemRemoved from: #yourself.
browser transmit to: #preview; andShow: [ :a |
a list
title: [:col | 'List: ', col size printString ]; *"This
isn't updating"*
when: [:col | col size > 1 ].
a text title: 'Text';
format: [:col | 'Current collection: ', col printString, '.
Add more items to show the list'] ].
browser openOn: collection
KR
--
Gareth Cox
IT Manager/Developer
Inspired Org (PTY) Ltd
email: gareth(a)inspired.org <mailto:gareth@inspired.org>
Hi Alex,
I think that TRDrag* events should require that you are over the dragged
element with your mouse, because now the behavior is that if the mouse gets
outside the element, drag events are still being fired. But maybe I should
fix this on my side.
To better illustrate my point look at this
https://www.youtube.com/watch?v=4rHdiwGdr4s
When the mouse is completely out of the element the resizing is still
occurring (because the drag event is still being applied), and then compare
it to the behavior of resizing Playground -- there it happens only where it
makes sense.
I haven't found any applicable example directly in Roassal, but you can
look into my
smalltalkhub peteruhnak/roassal-contrib repo (same as we used before for
moving stuff from dynacase)
at DCRTResizable>>example
On another note:
I added methods for moving to RTLayoutTranslator for all sides, so you can
probably move it to Roassal if it looks ok to you.
Thanks,
Peter
Hi!
I do not get an example with DCRTFocusable. What does this interaction do? I tried the following and it does not seem to do much.
-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle width: #numberOfVariables; height: #numberOfMethods.
ns := b nodes: RTShape withAllSubclasses.
es := b edges connectFrom: #superclass.
es @ DCRTFocusable.
b layout tree.
b
-=-=-=-=-=-=
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I'm trying to find a way how to observe all mouse clicks regardless of
elements. I can do this easily on my side, because I have control over
everything I create,
but doing that would prevent certain things like RTResizable from working
in pure Roassal...
Currently all Trachel mouse events are created in Morphic (TRMorph),
however events themselves are fired from shapes' announcers so there is no
convergence point.
So, would it be possible to basically fire the event twice, once from the
shape's announcer and once from probably view or canvas (or some TROverseer
class or whatever).
As far as performance goes this shouldn't be a problem if you consider that
just mouse movement can trigger 10 events every second.
What do you think? Is it worth for you to change/implement it?
If not I will resolve it on my side.
Thanks,
Peter
