3 Oct
2014
3 Oct
'14
10:03 p.m.
Hi,
I am wondering what is the proper level at which should be addressed
composition of elements.
Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements,
because they would have to be inserted into RTView which may not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
5 Oct
5 Oct
6:52 p.m.
Hi Peter,
I would say, stay at the RTShape level. Trachel objects are for the low
level stuff. For example a
TRArcShape defines an arc based on the geometric property and with RTShapes
you visualize a model
by mapping its attributes to geometric values for the visible (trachel )
shapes.
An UML class diagram is a rectangle with three segments (or three boxes).
The mapping from class attributes
to the class diagram would happen on with RTShape/element/builder...., so
you would need something on that level anyway.
Sure you can define a UML-Trachel shape as one geometric object. But I
would only choose this
way if the object is somehow "static" and "closed".If you want to
change
the object(model) through the
visible representation or connect parts of it with other elements, then
every single element of the
UML-diagram (class label, class vars, class methods) should be accessible
on the RT-Level.
I wouldn't subclass RTShape neither. The whole framework looks like it is
based on builders and
building complex shapes as groups of simpler (RT)shapes.
Maybe something like a group of three RTBoxes. The first box only has a
label, the second
and third box has a list of other elements (vars/methods).
In addition the two other boxes may have different states.
Collapsed (only shows the attribute (var or methods) and the number of
elements
Expanded (show a full list, this may be difficult for classes with many
methods roassal shapes do
not provide something like a scrollable list)
Expanded overview (somethink like the "blueprint" diagram, wiith small
single boxes for every item)
I would start by looking at the "Pharo Smart Browser" (In the Roassal2
image)
It defines boxes for classes and within this (expanded) boxes is a list of
trees for the methods, for an UML - Diagramm you'll use a list of labels
for the methods).
Nicolai
2014-10-03 22:03 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Hi,
I am wondering what is the proper level at which should be addressed
composition of elements.
Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements,
because they would have to be inserted into RTView which may not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:13 p.m.
Hi Nicolai,
thank you for your answer, I will try to explain my problem little bit
further/better.
Let's take a simple example of bordered box full of lines of text.
--------------
labels := OrderedCollection new asValueHolder.
view := RTView new.
group := RTGroup new.
box := (RTBox new color: Color white; borderColor: Color black) element.
RTNest new on: box nest: group.
labels whenChangedDo: [ :collection |
group do: [ :each | each remove ].
group removeAll.
group addAll: (RTLabel new elementsOn: collection).
view addAll: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
view signalUpdate.
].
view add: box.
view open.
labels add: 'first'.
labels add: 'second'.
labels at: 1 put: 'First line'.
labels removeLast.
-------------
My first problem with this approach is that its adds multiple elements to
the view, so I cannot do any RTLayout on: view elements, since it would
apply it to everything. For example RTLabelled interaction
adds TRLabelShape instead of RTLabel, maybe to prevent this kind of problem?
And the second issue is that the builder is essentially just a pass-through
thing - just applying some rules on the elements but not really tying them
together. I would prefer to have the whole element somewhat more tightly
coupled. Done this way it is bound only by some TRCallbacks created inside
RTNest, so technically they are connected only through box's trachelShape,
which I feel isn't even the appropriate abstraction level (as you yourself
have pointed out).
So thus my call for custom RTShape or something similar. Maybe it would be
more appropriate to subclass RTElement and RTEdge?
What I am trying to do is not just visualization (as done by Moose) but a
live (diagram) editor.
Peter
On Sun, Oct 5, 2014 at 6:52 PM, Nicolai Hess <nicolaihess(a)web.de> wrote:
Hi Peter,
I would say, stay at the RTShape level. Trachel objects are for the low
level stuff. For example a
TRArcShape defines an arc based on the geometric property and with
RTShapes you visualize a model
by mapping its attributes to geometric values for the visible (trachel )
shapes.
An UML class diagram is a rectangle with three segments (or three boxes).
The mapping from class attributes
to the class diagram would happen on with RTShape/element/builder...., so
you would need something on that level anyway.
Sure you can define a UML-Trachel shape as one geometric object. But I
would only choose this
way if the object is somehow "static" and "closed".If you want to
change
the object(model) through the
visible representation or connect parts of it with other elements, then
every single element of the
UML-diagram (class label, class vars, class methods) should be accessible
on the RT-Level.
I wouldn't subclass RTShape neither. The whole framework looks like it is
based on builders and
building complex shapes as groups of simpler (RT)shapes.
Maybe something like a group of three RTBoxes. The first box only has a
label, the second
and third box has a list of other elements (vars/methods).
In addition the two other boxes may have different states.
Collapsed (only shows the attribute (var or methods) and the number of
elements
Expanded (show a full list, this may be difficult for classes with many
methods roassal shapes do
not provide something like a scrollable list)
Expanded overview (somethink like the "blueprint" diagram, wiith small
single boxes for every item)
I would start by looking at the "Pharo Smart Browser" (In the Roassal2
image)
It defines boxes for classes and within this (expanded) boxes is a list of
trees for the methods, for an UML - Diagramm you'll use a list of labels
for the methods).
Nicolai
2014-10-03 22:03 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Hi,
I am wondering what is the proper level at which should be addressed
composition of elements.
Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements,
because they would have to be inserted into RTView which may not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
_______________________________________________
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
7 Oct
7 Oct
12:32 a.m.
Alex just changed RTElement and RTNest to make the nested objects accessible
(http://forum.world.st/RTNest-should-be-explicit-td4782470.html)
Maybe this helps.
about the layout:
instead of
RTLayout on: view elements.
just layout ont the elements you want
RTLayout on: { ....}
or
RTLayout on:aGroupOfElements.
This is my attempt for creating a TreeLayout of classes with nested list of
instvars in a "class shape"
(the number is the number of methods).
(looks a bit ugly, and I don't know why I have to make some boxes
translucent to make the text show up).
|view classLabelShape classMethodsShape classVarsShape classShape classes
classesElements varBox methodBox|
classes := Canvas withAllSubclasses.
view := RTView new.
classLabelShape := RTLabel new.
classMethodsShape := RTBox new color: (Color lightBlue alpha:0.5).
classVarsShape := RTBox new color:(Color lightGreen alpha:0.5).
varBox := RTLabel new color:Color black;text:#yourself.
methodBox := RTLabel new color:Color black; text:[:c | c size].
classShape := RTBox new.
classesElements := classShape elementsOn:classes.
view addAll: classesElements.
RTNest new for:classesElements add:[:group :model | |varGroup varShapes
methodShape methodGroup|
varGroup :=(classVarsShape elementOn:model).
methodGroup:=(classMethodsShape elementOn:model).
varShapes:=(varBox elementsOn:(model instanceVariables ifNil:[#()])).
methodShape := methodBox elementOn:(model selectors).
view addAll: varShapes.
view add:methodShape.
group add:(classLabelShape elementOn:model).
group add:varGroup.
group add:methodGroup.
RTNest new layout:RTVerticalLineLayout;on:varGroup nest:varShapes.
RTNest new on:methodGroup nest:{methodShape}.
RTVerticalLineLayout on: group.
].
RTEdge buildEdgesFromObjects:classes
from:#yourself
toAll:[:c | c subclasses]
inView: view.
RTTreeLayout on: classesElements.
classesElements @ RTDraggable.
view @ RTDraggableView.
view open
2014-10-05 23:13 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Hi Nicolai,
thank you for your answer, I will try to explain my problem little bit
further/better.
Let's take a simple example of bordered box full of lines of text.
--------------
labels := OrderedCollection new asValueHolder.
view := RTView new.
group := RTGroup new.
box := (RTBox new color: Color white; borderColor: Color black) element.
RTNest new on: box nest: group.
labels whenChangedDo: [ :collection |
group do: [ :each | each remove ].
group removeAll.
group addAll: (RTLabel new elementsOn: collection).
view addAll: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
view signalUpdate.
].
view add: box.
view open.
labels add: 'first'.
labels add: 'second'.
labels at: 1 put: 'First line'.
labels removeLast.
-------------
My first problem with this approach is that its adds multiple elements to
the view, so I cannot do any RTLayout on: view elements, since it would
apply it to everything. For example RTLabelled interaction
adds TRLabelShape instead of RTLabel, maybe to prevent this kind of problem?
And the second issue is that the builder is essentially just a
pass-through thing - just applying some rules on the elements but not
really tying them together. I would prefer to have the whole element
somewhat more tightly coupled. Done this way it is bound only by some
TRCallbacks created inside RTNest, so technically they are connected only
through box's trachelShape, which I feel isn't even the appropriate
abstraction level (as you yourself have pointed out).
So thus my call for custom RTShape or something similar. Maybe it would be
more appropriate to subclass RTElement and RTEdge?
What I am trying to do is not just visualization (as done by Moose) but a
live (diagram) editor.
Peter
On Sun, Oct 5, 2014 at 6:52 PM, Nicolai Hess <nicolaihess(a)web.de> wrote:
Hi Peter,
I would say, stay at the RTShape level. Trachel objects are for the low
level stuff. For example a
TRArcShape defines an arc based on the geometric property and with
RTShapes you visualize a model
by mapping its attributes to geometric values for the visible (trachel )
shapes.
An UML class diagram is a rectangle with three segments (or three boxes).
The mapping from class attributes
to the class diagram would happen on with RTShape/element/builder...., so
you would need something on that level anyway.
Sure you can define a UML-Trachel shape as one geometric object. But I
would only choose this
way if the object is somehow "static" and "closed".If you want to
change
the object(model) through the
visible representation or connect parts of it with other elements, then
every single element of the
UML-diagram (class label, class vars, class methods) should be accessible
on the RT-Level.
I wouldn't subclass RTShape neither. The whole framework looks like it is
based on builders and
building complex shapes as groups of simpler (RT)shapes.
Maybe something like a group of three RTBoxes. The first box only has a
label, the second
and third box has a list of other elements (vars/methods).
In addition the two other boxes may have different states.
Collapsed (only shows the attribute (var or methods) and the number of
elements
Expanded (show a full list, this may be difficult for classes with many
methods roassal shapes do
not provide something like a scrollable list)
Expanded overview (somethink like the "blueprint" diagram, wiith small
single boxes for every item)
I would start by looking at the "Pharo Smart Browser" (In the Roassal2
image)
It defines boxes for classes and within this (expanded) boxes is a list of
trees for the methods, for an UML - Diagramm you'll use a list of labels
for the methods).
Nicolai
2014-10-03 22:03 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Hi,
I am wondering what is the proper level at which should be addressed
composition of elements.
Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements,
because they would have to be inserted into RTView which may not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font
and size... what about underline/italics/bold?
_______________________________________________
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
4:02 p.m.
Hi!
Sorry for my late answer.
As Nicolai said, I do not see a need for creating a new shape.
Simply create a new builder.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed composition of
elements.
Imagine I want to create a diagram of UML class but I want to be able to dynamically add
and remove new lines and sections, including various formatting (underline, italics, bold,
...) of each line separately. The RTUMLClassBuilder (or any other builder for that matter)
is not an option since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and implement
method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements, because they would
have to be inserted into RTView which may not be available at the time - is there a way
around it?
So the other option is to use TRShape (Trachel) elements instead which would be fine
except I feel like I am duplicating code of roassal elements (so for TRLabelShape I would
copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is that in
updateFor:trachelShape: I would need to access internal structure of the element and
change it (because for example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of RTView elements?
Because if I have diagram full of UML classes I probably don't care about the content
of them when doing layouting - so I would prefer to have only MyRTUmlClass elements there
and not every single label inside it (as is the case of RTUmlClassBuilder), because
otherwise having access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and size... what
about underline/italics/bold?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:38 p.m.
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone could help, it would
be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed composition of
elements.
Imagine I want to create a diagram of UML class but I want to be able to dynamically add
and remove new lines and sections, including various formatting (underline, italics, bold,
...) of each line separately. The RTUMLClassBuilder (or any other builder for that matter)
is not an option since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and implement
method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements, because they would
have to be inserted into RTView which may not be available at the time - is there a way
around it?
So the other option is to use TRShape (Trachel) elements instead which would be fine
except I feel like I am duplicating code of roassal elements (so for TRLabelShape I would
copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is that in
updateFor:trachelShape: I would need to access internal structure of the element and
change it (because for example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of RTView elements?
Because if I have diagram full of UML classes I probably don't care about the content
of them when doing layouting - so I would prefer to have only MyRTUmlClass elements there
and not every single label inside it (as is the case of RTUmlClassBuilder), because
otherwise having access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and size... what
about underline/italics/bold?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:53 p.m.
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does
pretty much all I was looking for, so thank you both!
(looks a bit ugly, and I don't know why I have to
make some boxes
translucent to make the text show up).
The reason is quite simple, the elements are placed to the view in the
order in which they were added. So the colored boxes are added on top of
the label.
You can also see this when you move them, they kind of go through each
other. Maybe it would be more natural to move all elements to top when they
are being dragged?
One possible solution would be to add them to a collection and then change
the order on canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart
to TRRemoveCallback), which would be called when the element was added to
the view? It would also eliminate the need to have view already available
in places like RTLabelled.
Peter
On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone could
help, it would be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed
composition
of elements.
Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape
(Roassal) elements,
because they would have to be inserted into RTView which may
not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be
fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView
elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font
and size...
what about underline/italics/bold?
_______________________________________________
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
10:59 p.m.
I would be happy to help Alex, however I am not sure of my level of
knowledge of Roassal. Also I have zero experience writing stuff like this
so I don't think the result would be any good. :(
But if there is something small or like "write something about this or
that" than I could give it a shot.
Peter
On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does
pretty much all I was looking for, so thank you both!
(looks a bit ugly, and I don't know why I
have to make some boxes
translucent to make the text show up).
The reason is quite simple, the elements are placed to the view in the
order in which they were added. So the colored boxes are added on top of
the label.
You can also see this when you move them, they kind of go through each
other. Maybe it would be more natural to move all elements to top when they
are being dragged?
One possible solution would be to add them to a collection and then change
the order on canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart
to TRRemoveCallback), which would be called when the element was added to
the view? It would also eliminate the need to have view already available
in places like RTLabelled.
Peter
On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone
could help, it would be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed
composition
of elements.
Imagine I want to create a diagram of UML class but I want to be able
to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass)
and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape
(Roassal) elements,
because they would have to be inserted into RTView which may
not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be
fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView
elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font
and size...
what about underline/italics/bold?
_______________________________________________
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
8 Oct
8 Oct
2:13 a.m.
No worry :)
By the way, what are you using Roassal for?
Alexandre
Le 07-10-2014 à 17:59, Peter Uhnák
<i.uhnak(a)gmail.com> a écrit :
I would be happy to help Alex, however I am not sure of my level of knowledge of Roassal.
Also I have zero experience writing stuff like this so I don't think the result would
be any good. :(
But if there is something small or like "write something about this or that"
than I could give it a shot.
Peter
On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák
<i.uhnak(a)gmail.com> wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does pretty much all
I was looking for, so thank you both!
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev (looks a bit ugly, and I don't know why I
have to make some boxes translucent to make the text show up).
The reason is quite
simple, the elements are placed to the view in the order in which they were added. So the
colored boxes are added on top of the label.
You can also see this when you move them, they kind of go through each other. Maybe it
would be more natural to move all elements to top when they are being dragged?
One possible solution would be to add them to a collection and then change the order on
canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart to TRRemoveCallback), which would
be called when the element was added to the view? It would also eliminate the need to have
view already available in places like RTLabelled.
Peter
> On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
> I started to write a chapter about Trachel:
>
>
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
>
> There is not much for now… But it is growing. By the way, if someone could help, it
would be fantastic :-)
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
>
> > Hi,
> >
> > I am wondering what is the proper level at which should be addressed composition
of elements.
> >
> > Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various formatting
(underline, italics, bold, ...) of each line separately. The RTUMLClassBuilder (or any
other builder for that matter) is not an option since it's a one time build.
> >
> > The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
> > Now the issue is, that I cannot use other RTShape (Roassal) elements, because
they would have to be inserted into RTView which may not be available at the time - is
there a way around it?
> >
> > So the other option is to use TRShape (Trachel) elements instead which would be
fine except I feel like I am duplicating code of roassal elements (so for TRLabelShape I
would copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is
that in updateFor:trachelShape: I would need to access internal structure of the element
and change it (because for example a new method was added) - does that break
encapsulation?
> >
> > And finally, from conceptual standpoint what should be the content of RTView
elements? Because if I have diagram full of UML classes I probably don't care about
the content of them when doing layouting - so I would prefer to have only MyRTUmlClass
elements there and not every single label inside it (as is the case of RTUmlClassBuilder),
because otherwise having access to RTView elements is useless and I must keep reference to
correct objects myself.
> >
> > Thanks!
> >
> > Peter
> >
> > p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
> >
> > _______________________________________________
> > 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
6:45 a.m.
We are using it for a diagram editor / modeling tool, right now we are
trying to make something comparable to Umlet. To end goal is (Dyna)CASE
tool... but... well... one can dream. :)
Also I believe Jan Bliznicenko contacted you a couple of times, so he is
part of it too.
Using Pharo and Roassal has been tremendous help, but there is still tons
of work to be done.
We will announce it once we feel confident about it, which will be probably
at the end of the school semester... or at least once we have some
stable-ish beta version.
Peter
On Wed, Oct 8, 2014 at 2:13 AM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
No worry :)
By the way, what are you using Roassal for?
Alexandre
Le 07-10-2014 à 17:59, Peter Uhnák <i.uhnak(a)gmail.com> a écrit :
I would be happy to help Alex, however I am not sure of my level of
knowledge of Roassal. Also I have zero experience writing stuff like this
so I don't think the result would be any good. :(
But if there is something small or like "write something about this or
that" than I could give it a shot.
Peter
On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
On Wed, Oct 8, 2014 at 2:13 AM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does
pretty much all I was looking for, so thank you both!
_______________________________________________
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
(looks a bit ugly, and I don't know why I
have to make some boxes
translucent to make the text show up).
The reason is quite simple, the elements are placed to the view in the
order in which they were added. So the colored boxes are added on top of
the label.
You can also see this when you move them, they kind of go through each
other. Maybe it would be more natural to move all elements to top when they
are being dragged?
One possible solution would be to add them to a collection and then
change the order on canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart
to TRRemoveCallback), which would be called when the element was added to
the view? It would also eliminate the need to have view already available
in places like RTLabelled.
Peter
On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com
wrote:
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone
could help, it would be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed
composition
of elements.
Imagine I want to create a diagram of UML class but I want to be able
to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass)
and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape
(Roassal) elements,
because they would have to be inserted into RTView which may
not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be
fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView
elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font
and size...
what about underline/italics/bold?
_______________________________________________
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
No worry :)
By the way, what are you using Roassal for?
Alexandre
Le 07-10-2014 à 17:59, Peter Uhnák <i.uhnak(a)gmail.com> a écrit :
I would be happy to help Alex, however I am not sure of my level of
knowledge of Roassal. Also I have zero experience writing stuff like this
so I don't think the result would be any good. :(
But if there is something small or like "write something about this or
that" than I could give it a shot.
Peter
On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does
pretty much all I was looking for, so thank you both!
_______________________________________________
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
(looks a bit ugly, and I don't know why I
have to make some boxes
translucent to make the text show up).
The reason is quite simple, the elements are placed to the view in the
order in which they were added. So the colored boxes are added on top of
the label.
You can also see this when you move them, they kind of go through each
other. Maybe it would be more natural to move all elements to top when they
are being dragged?
One possible solution would be to add them to a collection and then
change the order on canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart
to TRRemoveCallback), which would be called when the element was added to
the view? It would also eliminate the need to have view already available
in places like RTLabelled.
Peter
On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com
wrote:
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone
could help, it would be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hi,
I am wondering what is the proper level at which should be addressed
composition
of elements.
Imagine I want to create a diagram of UML class but I want to be able
to
dynamically add and remove new lines and sections, including various
formatting (underline, italics, bold, ...) of each line separately. The
RTUMLClassBuilder (or any other builder for that matter) is not an option
since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass)
and
implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape
(Roassal) elements,
because they would have to be inserted into RTView which may
not be
available at the time - is there a way around it?
So the other option is to use TRShape (Trachel) elements instead which
would be
fine except I feel like I am duplicating code of roassal elements
(so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for
my needs), and the second issue is that in updateFor:trachelShape: I would
need to access internal structure of the element and change it (because for
example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of
RTView
elements? Because if I have diagram full of UML classes I probably
don't care about the content of them when doing layouting - so I would
prefer to have only MyRTUmlClass elements there and not every single label
inside it (as is the case of RTUmlClassBuilder), because otherwise having
access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font
and size...
what about underline/italics/bold?
_______________________________________________
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
1:46 p.m.
Ok! sounds great!
Alexandre
Le 08-10-2014 à 1:45, Peter Uhnák
<i.uhnak(a)gmail.com> a écrit :
We are using it for a diagram editor / modeling tool, right now we are trying to make
something comparable to Umlet. To end goal is (Dyna)CASE tool... but... well... one can
dream. :)
Also I believe Jan Bliznicenko contacted you a couple of times, so he is part of it too.
Using Pharo and Roassal has been tremendous help, but there is still tons of work to be
done.
We will announce it once we feel confident about it, which will be probably at the end of
the school semester... or at least once we have some stable-ish beta version.
Peter
On Wed, Oct 8, 2014 at 2:13 AM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
No worry :)
By the way, what are you using Roassal for?
Alexandre
Le 07-10-2014 à 17:59, Peter Uhnák
<i.uhnak(a)gmail.com> a écrit :
I would be happy to help Alex, however I am not
sure of my level of knowledge of Roassal. Also I have zero experience writing stuff like
this so I don't think the result would be any good. :(
But if there is something small or like "write something about this or that"
than I could give it a shot.
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák
<i.uhnak(a)gmail.com> wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does pretty much all
I was looking for, so thank you both!
> (looks a bit ugly, and I don't know why I have to make some boxes translucent to
make the text show up).
The reason is quite simple, the elements are placed to the view in the order in which
they were added. So the colored boxes are added on top of the label.
You can also see this when you move them, they kind of go through each other. Maybe it
would be more natural to move all elements to top when they are being dragged?
One possible solution would be to add them to a collection and then change the order on
canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart to TRRemoveCallback), which would
be called when the element was added to the view? It would also eliminate the need to have
view already available in places like RTLabelled.
Peter
> On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
> I started to write a chapter about Trachel:
>
>
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
>
> There is not much for now… But it is growing. By the way, if someone could help, it
would be fantastic :-)
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
>
> > Hi,
> >
> > I am wondering what is the proper level at which should be addressed composition
of elements.
> >
> > Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various formatting
(underline, italics, bold, ...) of each line separately. The RTUMLClassBuilder (or any
other builder for that matter) is not an option since it's a one time build.
> >
> > The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
> > Now the issue is, that I cannot use other RTShape (Roassal) elements, because
they would have to be inserted into RTView which may not be available at the time - is
there a way around it?
> >
> > So the other option is to use TRShape (Trachel) elements instead which would be
fine except I feel like I am duplicating code of roassal elements (so for TRLabelShape I
would copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is
that in updateFor:trachelShape: I would need to access internal structure of the element
and change it (because for example a new method was added) - does that break
encapsulation?
> >
> > And finally, from conceptual standpoint what should be the content of RTView
elements? Because if I have diagram full of UML classes I probably don't care about
the content of them when doing layouting - so I would prefer to have only MyRTUmlClass
elements there and not every single label inside it (as is the case of RTUmlClassBuilder),
because otherwise having access to RTView elements is useless and I must keep reference to
correct objects myself.
> >
> > Thanks!
> >
> > Peter
> >
> > p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
> >
> > _______________________________________________
> > 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev On Wed, Oct 8, 2014 at 2:13 AM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
No worry :)
By the way, what are you using Roassal for?
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Le 07-10-2014 à 17:59, Peter Uhnák
<i.uhnak(a)gmail.com> a écrit :
I would be happy to help Alex, however I am not
sure of my level of knowledge of Roassal. Also I have zero experience writing stuff like
this so I don't think the result would be any good. :(
But if there is something small or like "write something about this or that"
than I could give it a shot.
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev On Tue, Oct 7, 2014 at 10:53 PM, Peter Uhnák
<i.uhnak(a)gmail.com> wrote:
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does pretty much all
I was looking for, so thank you both!
> (looks a bit ugly, and I don't know why I have to make some boxes translucent to
make the text show up).
The reason is quite simple, the elements are placed to the view in the order in which
they were added. So the colored boxes are added on top of the label.
You can also see this when you move them, they kind of go through each other. Maybe it
would be more natural to move all elements to top when they are being dragged?
One possible solution would be to add them to a collection and then change the order on
canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart to TRRemoveCallback), which would
be called when the element was added to the view? It would also eliminate the need to have
view already available in places like RTLabelled.
Peter
> On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
> I started to write a chapter about Trachel:
>
>
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
>
> There is not much for now… But it is growing. By the way, if someone could help, it
would be fantastic :-)
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
>
> > Hi,
> >
> > I am wondering what is the proper level at which should be addressed composition
of elements.
> >
> > Imagine I want to create a diagram of UML class but I want to be able to
dynamically add and remove new lines and sections, including various formatting
(underline, italics, bold, ...) of each line separately. The RTUMLClassBuilder (or any
other builder for that matter) is not an option since it's a one time build.
> >
> > The option I see is to subclass RTShape (let's name it MyRTUmlClass) and
implement method trachelShapeFor: .
> > Now the issue is, that I cannot use other RTShape (Roassal) elements, because
they would have to be inserted into RTView which may not be available at the time - is
there a way around it?
> >
> > So the other option is to use TRShape (Trachel) elements instead which would be
fine except I feel like I am duplicating code of roassal elements (so for TRLabelShape I
would copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is
that in updateFor:trachelShape: I would need to access internal structure of the element
and change it (because for example a new method was added) - does that break
encapsulation?
> >
> > And finally, from conceptual standpoint what should be the content of RTView
elements? Because if I have diagram full of UML classes I probably don't care about
the content of them when doing layouting - so I would prefer to have only MyRTUmlClass
elements there and not every single label inside it (as is the case of RTUmlClassBuilder),
because otherwise having access to RTView elements is useless and I must keep reference to
correct objects myself.
> >
> > Thanks!
> >
> > Peter
> >
> > p.s.: Is it currently possible to format text? I saw only color, font and
size... what about underline/italics/bold?
> >
> > _______________________________________________
> > 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:14 a.m.
Could be... We have to see
Alexandre
Le 07-10-2014 à 17:53, Peter Uhnák
<i.uhnak(a)gmail.com> a écrit :
Hi Nicolai,
I investigated the new RTNest and your example and it seems that it does pretty much all
I was looking for, so thank you both!
(looks a bit ugly, and I don't know why I
have to make some boxes translucent to make the text show up).
The reason is quite
simple, the elements are placed to the view in the order in which they were added. So the
colored boxes are added on top of the label.
You can also see this when you move them, they kind of go through each other. Maybe it
would be more natural to move all elements to top when they are being dragged?
One possible solution would be to add them to a collection and then change the order on
canvas... something like
-------------------
"your other code...."
labels := RTGroup new.
RTNest new for: classesElements add: [ :group :model | ....
....
labels addAll: varShapes.
labels add: methodShape.
].
labels do: [ :each | each trachelShape pushFront ].
"the rest of your code"
-------------------------
However this feels hacky...
Perhaps there could be TRAddCallback (as a counterpart to TRRemoveCallback), which would
be called when the element was added to the view? It would also eliminate the need to have
view already available in places like RTLabelled.
Peter
On Tue, Oct 7, 2014 at 5:38 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
I started to write a chapter about Trachel:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Trachel/010…
There is not much for now… But it is growing. By the way, if someone could help, it would
be fantastic :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 3, 2014, at 5:03 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I am wondering what is the proper level at which should be addressed composition of
elements.
Imagine I want to create a diagram of UML class but I want to be able to dynamically add
and remove new lines and sections, including various formatting (underline, italics, bold,
...) of each line separately. The RTUMLClassBuilder (or any other builder for that matter)
is not an option since it's a one time build.
The option I see is to subclass RTShape (let's name it MyRTUmlClass) and implement
method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements, because they would
have to be inserted into RTView which may not be available at the time - is there a way
around it?
So the other option is to use TRShape (Trachel) elements instead which would be fine
except I feel like I am duplicating code of roassal elements (so for TRLabelShape I would
copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is that in
updateFor:trachelShape: I would need to access internal structure of the element and
change it (because for example a new method was added) - does that break encapsulation?
And finally, from conceptual standpoint what should be the content of RTView elements?
Because if I have diagram full of UML classes I probably don't care about the content
of them when doing layouting - so I would prefer to have only MyRTUmlClass elements there
and not every single label inside it (as is the case of RTUmlClassBuilder), because
otherwise having access to RTView elements is useless and I must keep reference to correct
objects myself.
Thanks!
Peter
p.s.: Is it currently possible to format text? I saw only color, font and size... what
about underline/italics/bold?
_______________________________________________
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
3728
days inactive
3733
days old
11 comments
3 participants
participants (3)
-
Alexandre Bergel -
Nicolai Hess -
Peter Uhnák