why the tree map is a layout and not the distribution map?
Stef
On May 8, 2013, at 9:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Btw: the same
thing with padding lead to the method:
removeMarginFor: elements
"Assume that elements is not nil, and that all the elements have the same
parent"
elements do: [ :e | e allElementsDo: [ :ee | ee resizeStrategy: (e resizeStrategy
paddingGap: 0) ] ]
in ROTreeMapLayout.
I think from a performance perspective this is not very nice as well, since we have to go
over all the elements again and fix something, which could be prevented with default
values or a simple handling of nil values, to ignore the padding.
Well... I think the whole story comes from the fact that the tree map is considered as a
layout. And this layout is very different from other layouts (e.g., tree map layout),
since edges have to be removed, zOrder updated, size of the nodes changed, interaction of
the element modified (they need to forward drag and drop right?). This makes me think that
maybe the tree map should maybe be a new builder (as the MondrianViewBuilder).
At the moment to define your nodes, you can indeed use a padding = 0.
Regarding the performance, your method #removeMarginFor: is called in the initialize of
the layout. Which means that it is executed once. Even iterating over 100 000 elements is
very fast.
Let me know if there is something unclear.
Cheers,
Alexandre
On Wed, May 8, 2013 at 8:58 AM, Dennis Schenk <d.schenk(a)students.unibe.ch> wrote:
Hi Alexandre,
Thanks for looking into this.
When I do QsSystemViewer for: 'Zinc' now, I get an error that padding is nil of a
ROFixedSizedParent instance I'm using when drawing a layout.
I fixed that by changing:
visualRepresentationOfChildNode resizeStrategy: ROFixedSizedParent instance.
to:
visualRepresentationOfChildNode resizeStrategy: (ROFixedSizedParent instance paddingGap:
0).
But that is not very nice, I think. Wouldn't it make sense to have some default
values in place? Or to allow a nil value and interpret it as 0@0?
After I fixed that, the next bug appeared, again the same thing with padding being nil,
but this time when creating a ROPopup.
ROPopup:createElement is called, but then in
ROElement:addedInAnElement: el
self translateBy: el topLeft negated.
self translateBy: el resizeStrategy padding.
self parent: el; view: el view.
el addElement: self.
el adjustSizeIfNecessary
The padding is again nil for resizeStrategy. For ROPopup ROExtensibleParent is used.
I think there should be some check: if padding is nil or 0@0, no translation should be
attempted. What do you think?
Also a related question:
I saw that ROFixedSizeParent was changed in the ROTreemapLayout to ROPermissiveParent:
What is the difference between the two? When should one be used and when the other?
Cheers,
Dennis
On Wed, May 8, 2013 at 1:52 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
I think I have solved the problem. Would you mind to check please?
This was tricky. The problem was due to the recent optimization I did: the rendering
queue was modified while being iterated.
Fortunately, I still had the implementation fresh in mind to solve the problem.
Update to Roassal 1.351
Cheers,
Alexandre
On May 7, 2013, at 3:23 PM, Dennis Schenk <d.schenk(a)students.unibe.ch> wrote:
Hi Alex,
With a fresh 2.0 image run the following:
Gofer new
smalltalkhubUser: 'Quicksilver' project: 'Quicksilver';
package: 'ConfigurationOfQuicksilver';
load.
ConfigurationOfQuicksilver loadDefault.
QsSystemViewer for: 'Zinc'
Cheers,
Dennis
On Tue, May 7, 2013 at 7:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
How to reproduce the error?
Alexandre
On May 7, 2013, at 1:35 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote:
Dear all,
I'm doing some experiments with QuickSilver, but I have always some
Morph issue when running an expression like this one: QsSystemViewer
for: 'Zinc'
I expand the node and try to zoom out. After a while, I have a broken
morph with red square and yellow cross. The problem apparently is
always in
ROView>>elementsToRenderDo: aBlock
Maybe a Roassal bug.
Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev