QuickSilver bug
Locked
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Serge, I encountered this behavior recently as well. It seems to be a newly introduced bug. Maybe because of a change in Roassal - but I think it's not necessarily a bug there. Maybe I didn't adapt to a change correctly, since it does not seem to happen in other Roassal views. So far I haven't been able to track it down and fix it but I will work on it and update you when I found something.
Any input on this is welcome of course. Cheers, Dennis On Tue, May 7, 2013 at 7:35 AM, Serge Stinckwich <[hidden email]> wrote: Dear all, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
How to reproduce this problem starting from a new 2.0 image?
Cheers, Alexandre On May 7, 2013, at 5:13 AM, Dennis Schenk <[hidden email]> wrote: > Hi Serge, > > I encountered this behavior recently as well. It seems to be a newly introduced bug. Maybe because of a change in Roassal - but I think it's not necessarily a bug there. Maybe I didn't adapt to a change correctly, since it does not seem to happen in other Roassal views. So far I haven't been able to track it down and fix it but I will work on it and update you when I found something. > > Any input on this is welcome of course. > > Cheers, > Dennis > > > On Tue, May 7, 2013 at 7:35 AM, Serge Stinckwich <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by SergeStinckwich
How to reproduce the error?
Alexandre On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: How to reproduce the error? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: > How to reproduce the error? > > Alexandre > > > On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: I think I have solved the problem. Would you mind to check please? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Indeed, default values should be in place everywhere to require minimal setup and scripting.
Doru On May 8, 2013, at 9:00 AM, Dennis Schenk <[hidden email]> 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. > > > On Wed, May 8, 2013 at 8:58 AM, Dennis Schenk <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > How to reproduce the error? > > > > Alexandre > > > > > > On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Be rather willing to give than demanding to get." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
Hi Dennis,
I think the problem is the following: - you have been using an old version of Roassal that does not have the padding for resize strategy and - you have upgraded, supposedly yesterday, to try my fix. Two ways to fix the problem: 1 - Execute in your image: ROAbstractResizeStrategy resetAll. ROView resetNullView. 2 - or take a fresh moose image and try Quicksilver Can you try again please? There is a number of strategies to resize the parent as you have seen. Both ROFixedSizedParent and ROPermissiveParent do not resize the parent node when children nodes are added. Now, the different between the two is: - ROFixedSizedParent makes sure that a child node cannot be dragged and dropped outside its parent. - ROPermissiveParent does not care if a children node is dragged and dropped outside its parent. When you should use ROPermissiveParent? I would say never. I did this to fix a performance problem Usman spotted when doing a grid layout of inner node. Try the following: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | view | view := ROView new. el := ROBox element. el @ RODraggable. el extent: 100 @ 80. el resizeStrategy: ROPermissiveParent instance. "el resizeStrategy: ROFixedSizedParent instance." el2 := ROBox green element. el3 := ROBox red element. el2 extent: 20 @ 20. el3 extent: 20 @ 20. el2 @ RODraggable. el3 @ RODraggable. el add: el2; add: el3. view add: el. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I have added this example in ROExample by the way. Other strategy exist as you may have seen. Such as ROShrinkingParent and ROExtensibleParent. ROExtensibleParent is the default one, used in the Mondrian builder. Cheers, Alexandre On May 8, 2013, at 2:58 AM, Dennis Schenk <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > How to reproduce the error? > > > > Alexandre > > > > > > On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > How to reproduce the error? > > > > Alexandre > > > > > > On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
This is the case actually. I suspect that Dennis did an update of the code, meaning some singleton object where not properly reseted.
Cheers, Alexandre On May 8, 2013, at 3:58 AM, Tudor Girba <[hidden email]> wrote: > Indeed, default values should be in place everywhere to require minimal setup and scripting. > > Doru > > > On May 8, 2013, at 9:00 AM, Dennis Schenk <[hidden email]> 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. >> >> >> On Wed, May 8, 2013 at 8:58 AM, Dennis Schenk <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>> How to reproduce the error? >>> >>> Alexandre >>> >>> >>> On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by abergel
why the tree map is a layout and not the distribution map?
Stef On May 8, 2013, at 9:47 PM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>> How to reproduce the error? >>> >>> Alexandre >>> >>> >>> On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Good question. I think treemap should not be defined as a layout, but as a builder. My suggestion is to define a new builder for distribution map.
Alexandre Le 9 mai 2013 à 11:40, stephane ducasse <[hidden email]> a écrit : > why the tree map is a layout and not the distribution map? > > > Stef > > On May 8, 2013, at 9:47 PM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> How to reproduce the error? >>>> >>>> Alexandre >>>> >>>> >>>> On May 7, 2013, at 1:35 AM, Serge Stinckwich <[hidden email]> 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |