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.
On Wed, May 8, 2013 at 8:58 AM, Dennis Schenk d.schenk@students.unibe.chwrote:
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@me.comwrote:
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@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@me.com> wrote:
How to reproduce the error?
Alexandre
On May 7, 2013, at 1:35 AM, Serge Stinckwich <
serge.stinckwich@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev