Referring to the attached graph, what is the best way to approach the
following in Roassal. Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it. >>mondrianShape | builder | builder := MOFormsBuilder new. builder column; center; fill; pref; grow. builder row; center; pref; fill; grow; row; center; pref; fill; grow; row; center; pref; fill; grow. builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . builder x: 1 y: 3 add: ( MORectangleShape new ) . builder x: 1 y: 3 add: ( MOChildrenShape new ) . ^builder shape In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..." >>addSubViewTo: aMOViewRenderer aMOViewRenderer node: self using: self mondrianShape forIt: [ self children do: [ :child | child addSubViewTo: aMOViewRenderer. ] ] My initial issues in migrating this to Roassal are: 1. Roassal appears to not provide any methods that have "using:" in them. 2. Roassal appears to not support MOFormsBuilder It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. cheers -ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev MOFormsBuilder.png (35K) Download Attachment |
Currently, there is no support for complex shapes. This is definitely a direction in which we have to invest.
Cheers, Doru On 28 Jul 2012, at 18:06, Ben Coman wrote: > Referring to the attached graph, what is the best way to approach the following in Roassal. > Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it. > > >>mondrianShape > | builder | > builder := MOFormsBuilder new. > builder column; center; fill; pref; grow. > builder > row; center; pref; fill; grow; > row; center; pref; fill; grow; > row; center; pref; fill; grow. > builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . > builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . > builder x: 1 y: 3 add: ( MORectangleShape new ) . > builder x: 1 y: 3 add: ( MOChildrenShape new ) . > ^builder shape > > In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..." > > >>addSubViewTo: aMOViewRenderer > aMOViewRenderer > node: self > using: self mondrianShape > forIt: > [ > self children do: > [ :child | > child addSubViewTo: aMOViewRenderer. > ] > ] > > My initial issues in migrating this to Roassal are: > 1. Roassal appears to not provide any methods that have "using:" in them. > 2. Roassal appears to not support MOFormsBuilder > > It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. > > cheers -ben > > > <MOFormsBuilder.png>_______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Okay. What is the next best approach for what is available at the
moment? Subclass one of the other ROShapes... ?
I noticed "ROElement>>addShape: " What is the philosophy/architecture there? Reviewing all the senders shows that 90% only call #addShape: once. The only case where #addShape: is called multiple times on an object it always looks like this... node addShape: ROBox new; addShape: ROBorder new. cheers, -ben Tudor Girba wrote: Currently, there is no support for complex shapes. This is definitely a direction in which we have to invest. Cheers, Doru On 28 Jul 2012, at 18:06, Ben Coman wrote:Referring to the attached graph, what is the best way to approach the following in Roassal. Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it.mondrianShape| builder | builder := MOFormsBuilder new. builder column; center; fill; pref; grow. builder row; center; pref; fill; grow; row; center; pref; fill; grow; row; center; pref; fill; grow. builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . builder x: 1 y: 3 add: ( MORectangleShape new ) . builder x: 1 y: 3 add: ( MOChildrenShape new ) . ^builder shape In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..."addSubViewTo: aMOViewRendereraMOViewRenderer node: self using: self mondrianShape forIt: [ self children do: [ :child | child addSubViewTo: aMOViewRenderer. ] ] My initial issues in migrating this to Roassal are: 1. Roassal appears to not provide any methods that have "using:" in them. 2. Roassal appears to not support MOFormsBuilder It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. cheers -ben <MOFormsBuilder.png>_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev-- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ 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 |
As Doru said, Roassal does not provide a way to compose shapes. I will work on it soon, but right now you can't compose. One easy way to render something that looks like what you have shown is to nest nodes:
view node: 'UML' forIt: [ view shape rectangle withText. view node: 'ROShape'. view shape label text: [:el | el model selector]. view nodes: ROShape methods. view verticalLineLayout ]. Soon we will have more... Cheers, Alexandre On Jul 29, 2012, at 10:48 AM, Ben Coman <[hidden email]> wrote: > Okay. What is the next best approach for what is available at the moment? Subclass one of the other ROShapes... ? > > I noticed "ROElement>>addShape: " What is the philosophy/architecture there? > Reviewing all the senders shows that 90% only call #addShape: once. The only case where #addShape: is called multiple times on an object it always looks like this... > node > addShape: ROBox new; > addShape: ROBorder new. > > cheers, -ben > > Tudor Girba wrote: >> Currently, there is no support for complex shapes. This is definitely a direction in which we have to invest. >> >> Cheers, >> Doru >> >> >> On 28 Jul 2012, at 18:06, Ben Coman wrote: >> >> >> >>> Referring to the attached graph, what is the best way to approach the following in Roassal. >>> Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it. >>> >>> >>> >>>>> mondrianShape >>>>> >>>>> >>> | builder | >>> builder := MOFormsBuilder new. >>> builder column; center; fill; pref; grow. >>> builder >>> row; center; pref; fill; grow; >>> row; center; pref; fill; grow; >>> row; center; pref; fill; grow. >>> builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . >>> builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . >>> builder x: 1 y: 3 add: ( MORectangleShape new ) . >>> builder x: 1 y: 3 add: ( MOChildrenShape new ) . >>> ^builder shape >>> >>> In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..." >>> >>> >>> >>>>> addSubViewTo: aMOViewRenderer >>>>> >>>>> >>> aMOViewRenderer >>> node: self >>> using: self mondrianShape >>> forIt: >>> [ >>> self children do: >>> [ :child | >>> child addSubViewTo: aMOViewRenderer. >>> ] >>> ] >>> >>> My initial issues in migrating this to Roassal are: >>> 1. Roassal appears to not provide any methods that have "using:" in them. >>> 2. Roassal appears to not support MOFormsBuilder >>> >>> It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. >>> >>> cheers -ben >>> >>> >>> <MOFormsBuilder.png>_______________________________________________ >>> Moose-dev mailing list >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >> >> -- >> >> www.tudorgirba.com >> >> >> "Some battles are better lost than fought." >> >> >> >> >> _______________________________________________ >> 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 |
Just some additional musings... looking below at my last post where both
ROBox & ROBorder are added to a node, it seems that a node can hold multiple shapes even if they aren't "composed." Perhaps one simpler option that might satisfy my need would perhaps be having a ROOffsetLabel - having a relative offset from its usual location. This would have a callback onto the model so that several different texts could be associated with a node and dragged around with it. An alternative might be to consider a implementing a common interactive feature of drawing packages where multiple nodes can be selected and "grouped" into one node which are moved around together. This might be a desirable feature overall and also be used to composing complex shapes. I guess another alternative would be for myself to create my own subclass of ROShape. Now there is a second thing to consider from my example below. My #mondrianShape methods were implemented as a method within of the model - which I think is poor OO design - but at least got something working quickly. I think perhaps now ROShape is av- however I require the selected shape to follow the inheritance structure of the model - by way of example perhaps anything subclassing from MyModelContainer would have one shape and anything subclassing from MyModelSwitch would have another shape. What I propose then is a node having a definable callback on the model that returns the "Class" of required shape. This callback selector might be stored within the node, or might be a supposed shape DynamicProxyShape - which continually asks for the shape from the model, and then draws that shape. With the model returning the "Class" of a particular shape, then the coupling is that the model knows "which shape" it wants drawn, but not "how" to draw it, which defined as-a-kind-of-ROShape. I am not sure how that aligns with good OO design or not. cheers, Ben Alexandre Bergel wrote: > As Doru said, Roassal does not provide a way to compose shapes. I will work on it soon, but right now you can't compose. One easy way to render something that looks like what you have shown is to nest nodes: > > view node: 'UML' forIt: [ > view shape rectangle withText. > view node: 'ROShape'. > > view shape label text: [:el | el model selector]. > view nodes: ROShape methods. > > view verticalLineLayout > ]. > > Soon we will have more... > > Cheers, > Alexandre > > > On Jul 29, 2012, at 10:48 AM, Ben Coman <[hidden email]> wrote: > > >> Okay. What is the next best approach for what is available at the moment? Subclass one of the other ROShapes... ? >> >> I noticed "ROElement>>addShape: " What is the philosophy/architecture there? >> Reviewing all the senders shows that 90% only call #addShape: once. The only case where #addShape: is called multiple times on an object it always looks like this... >> node >> addShape: ROBox new; >> addShape: ROBorder new. >> >> cheers, -ben >> >> Tudor Girba wrote: >> >>> Currently, there is no support for complex shapes. This is definitely a direction in which we have to invest. >>> >>> Cheers, >>> Doru >>> >>> >>> On 28 Jul 2012, at 18:06, Ben Coman wrote: >>> >>> >>> >>> >>>> Referring to the attached graph, what is the best way to approach the following in Roassal. >>>> Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it. >>>> >>>> >>>> >>>> >>>>>> mondrianShape >>>>>> >>>>>> >>>>>> >>>> | builder | >>>> builder := MOFormsBuilder new. >>>> builder column; center; fill; pref; grow. >>>> builder >>>> row; center; pref; fill; grow; >>>> row; center; pref; fill; grow; >>>> row; center; pref; fill; grow. >>>> builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . >>>> builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . >>>> builder x: 1 y: 3 add: ( MORectangleShape new ) . >>>> builder x: 1 y: 3 add: ( MOChildrenShape new ) . >>>> ^builder shape >>>> >>>> In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..." >>>> >>>> >>>> >>>> >>>>>> addSubViewTo: aMOViewRenderer >>>>>> >>>>>> >>>>>> >>>> aMOViewRenderer >>>> node: self >>>> using: self mondrianShape >>>> forIt: >>>> [ >>>> self children do: >>>> [ :child | >>>> child addSubViewTo: aMOViewRenderer. >>>> ] >>>> ] >>>> >>>> My initial issues in migrating this to Roassal are: >>>> 1. Roassal appears to not provide any methods that have "using:" in them. >>>> 2. Roassal appears to not support MOFormsBuilder >>>> >>>> It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. >>>> >>>> cheers -ben >>>> >>>> Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Having a way to offset shapes is indeed important. A kind of wrapper for shapes using a decorator.
Alexandre On Aug 3, 2012, at 1:25 PM, Ben Coman <[hidden email]> wrote: > Just some additional musings... looking below at my last post where both ROBox & ROBorder are added to a node, it seems that a node can hold multiple shapes even if they aren't "composed." Perhaps one simpler option that might satisfy my need would perhaps be having a ROOffsetLabel - having a relative offset from its usual location. This would have a callback onto the model so that several different texts could be associated with a node and dragged around with it. > > An alternative might be to consider a implementing a common interactive feature of drawing packages where multiple nodes can be selected and "grouped" into one node which are moved around together. This might be a desirable feature overall and also be used to composing complex shapes. > > I guess another alternative would be for myself to create my own subclass of ROShape. > > > Now there is a second thing to consider from my example below. My #mondrianShape methods were implemented as a method within of the model - which I think is poor OO design - but at least got something working quickly. I think perhaps now ROShape is av- however I require the selected shape to follow the inheritance structure of the model - by way of example perhaps anything subclassing from MyModelContainer would have one shape and anything subclassing from MyModelSwitch would have another shape. > What I propose then is a node having a definable callback on the model that returns the "Class" of required shape. This callback selector might be stored within the node, or might be a supposed shape DynamicProxyShape - which continually asks for the shape from the model, and then draws that shape. With the model returning the "Class" of a particular shape, then the coupling is that the model knows "which shape" it wants drawn, but not "how" to draw it, which defined as-a-kind-of-ROShape. I am not sure how that aligns with good OO design or not. > > cheers, Ben > > Alexandre Bergel wrote: >> As Doru said, Roassal does not provide a way to compose shapes. I will work on it soon, but right now you can't compose. One easy way to render something that looks like what you have shown is to nest nodes: >> >> view node: 'UML' forIt: [ >> view shape rectangle withText. view node: 'ROShape'. >> >> view shape label text: [:el | el model selector]. >> view nodes: ROShape methods. >> >> view verticalLineLayout >> ]. >> >> Soon we will have more... >> >> Cheers, >> Alexandre >> >> >> On Jul 29, 2012, at 10:48 AM, Ben Coman <[hidden email]> wrote: >> >> >>> Okay. What is the next best approach for what is available at the moment? Subclass one of the other ROShapes... ? >>> >>> I noticed "ROElement>>addShape: " What is the philosophy/architecture there? Reviewing all the senders shows that 90% only call #addShape: once. The only case where #addShape: is called multiple times on an object it always looks like this... >>> node >>> addShape: ROBox new; >>> addShape: ROBorder new. >>> >>> cheers, -ben >>> >>> Tudor Girba wrote: >>> >>>> Currently, there is no support for complex shapes. This is definitely a direction in which we have to invest. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 28 Jul 2012, at 18:06, Ben Coman wrote: >>>> >>>> >>>> >>>>> Referring to the attached graph, what is the best way to approach the following in Roassal. >>>>> Currently with Mondrian I produce a produce a custom shape using the forms builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the attached graph, as an example this shows the class name "Substation" above the instance "SS1" and has a space for contained items to be displayed within it. >>>>> >>>>> >>>>> >>>>>>> mondrianShape >>>>>>> >>>>>>> >>>>> | builder | >>>>> builder := MOFormsBuilder new. >>>>> builder column; center; fill; pref; grow. >>>>> builder >>>>> row; center; pref; fill; grow; >>>>> row; center; pref; fill; grow; >>>>> row; center; pref; fill; grow. >>>>> builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName; textAlignment: #left; borderColor: Color white ) . >>>>> builder x: 1 y: 2 add: ( MORectangleShape new text: #localName; textAlignment: #left ) . >>>>> builder x: 1 y: 3 add: ( MORectangleShape new ) . >>>>> builder x: 1 y: 3 add: ( MOChildrenShape new ) . >>>>> ^builder shape >>>>> >>>>> In conjunction with the use of MOChildrenShape above, class ModelRoot also has method #addSubViewTo: which descends through contained classes - for example instance "primary" inside "T1" inside "SS2" inside "Figure 8..." >>>>> >>>>> >>>>> >>>>>>> addSubViewTo: aMOViewRenderer >>>>>>> >>>>>>> >>>>> aMOViewRenderer >>>>> node: self >>>>> using: self mondrianShape >>>>> forIt: >>>>> [ >>>>> self children do: >>>>> [ :child | >>>>> child addSubViewTo: aMOViewRenderer. >>>>> ] >>>>> ] >>>>> >>>>> My initial issues in migrating this to Roassal are: >>>>> 1. Roassal appears to not provide any methods that have "using:" in them. >>>>> 2. Roassal appears to not support MOFormsBuilder >>>>> >>>>> It may be that I am accessing to much internal methods. The code above was the result of evolutionary hacking as I was learning Mondrian. I would be happy to re-architect if someone can advise best practice for Roassal. >>>>> >>>>> cheers -ben >>>>> >>>>> > _______________________________________________ > 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 |
Free forum by Nabble | Edit this page |