TreeListMorph or MorphTreeMorph
Hi, We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph. Which one should I investigate on? Thanks Hilaire -- Dr. Geo http://drgeo.eu
MorphTreeMorph i would say Ben On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
is TMorphTreeModel trait dropped because I see it in the comment but it is not used by the MorphTreeModel? Thanks Hilaire Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
Ben
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes <hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
no idea, sorry. Ask Alain Plantec :) Ben On Apr 14, 2013, at 2:39 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
is TMorphTreeModel trait dropped because I see it in the comment but it is not used by the MorphTreeModel?
Thanks
Hilaire
Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
Ben
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes <hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
is TMorphTreeModel trait dropped because I see it in the comment but it is not used by the MorphTreeModel? Thanks Hilaire Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
Ben
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com <mailto:hilaire.fernandes@gmail.com>> wrote:
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
I must agree :) But a new implementation is in the starting block :) Ben On Apr 14, 2013, at 2:43 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
is TMorphTreeModel trait dropped because I see it in the comment but it is not used by the MorphTreeModel?
Thanks
Hilaire
Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
Ben
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com <mailto:hilaire.fernandes@gmail.com>> wrote:
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
On Apr 14, 2013, at 5:37 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
I must agree :)
But a new implementation is in the starting block :)
I love to hear that because if we get the same speed up than with the list and the new textMorph then it will be really really exciting.
Le 14/04/2013 17:37, Benjamin a écrit :
But a new implementation is in the starting block :) Ben
Ohoh, will it be compatible? Or should I wait? Hilaire -- Dr. Geo http://drgeo.eu
Le 14/04/2013 17:37, Benjamin a écrit :
But a new implementation is in the starting block :) Ben
I just started to write a few notes to get the logic, and was thinking I could wrote a small note on the colaboractive book. Hilaire -- Dr. Geo http://drgeo.eu
excellent please do. or in a class comment.
Le 14/04/2013 17:37, Benjamin a écrit :
But a new implementation is in the starting block :) Ben
I just started to write a few notes to get the logic, and was thinking I could wrote a small note on the colaboractive book.
Hilaire
-- Dr. Geo http://drgeo.eu
Not sure it makes sense now if it gonna be deprecated. Hilaire Le 15/04/2013 08:16, stephane ducasse a écrit :
excellent please do. or in a class comment.
Le 14/04/2013 17:37, Benjamin a écrit :
But a new implementation is in the starting block :) Ben
I just started to write a few notes to get the logic, and was thinking I could wrote a small note on the colaboractive book.
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
It always make sense :) At the end, everything will be deprecated once :) Ben On Apr 15, 2013, at 10:37 AM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Not sure it makes sense now if it gonna be deprecated.
Hilaire
Le 15/04/2013 08:16, stephane ducasse a écrit :
excellent please do. or in a class comment.
Le 14/04/2013 17:37, Benjamin a écrit :
But a new implementation is in the starting block :) Ben
I just started to write a few notes to get the logic, and was thinking I could wrote a small note on the colaboractive book.
Hilaire
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
When you fell unproductive -- stuck -- because you read library code you have to use but you don't understand it, or at least not deeply enough, it is not funny. Le 15/04/2013 12:18, Benjamin a écrit :
It always make sense :)
At the end, everything will be deprecated once :)
-- Dr. Geo http://drgeo.eu
On Apr 15, 2013, at 4:45 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
When you fell unproductive -- stuck -- because you read library code you have to use but you don't understand it, or at least not deeply enough, it is not funny.
Yes this is why ben said that this is always worth to document. STef
Le 15/04/2013 12:18, Benjamin a écrit :
It always make sense :)
At the end, everything will be deprecated once :)
-- Dr. Geo http://drgeo.eu
Exactly :) I am saying that because I have this kind of question when I spend days documenting Morphic infrastructure :) Everyone is like "Yeah, but we will throw away this crap", and that's perfectly true. But in mid-time so poor guys have to stuck with the existing infrastructure (like you in this case), and I really think it makes perfect sense to document something even if it will be deprecated in 6 months. First because even deprecated it will still be used during 1 year and a half. Moreover I deeply do not believe in a perfect system where nothing need to be changed anymore, so at some point everything will be deprecated and rewritten, that's why I said that even if something will be deprecated, it worth to be documented :) Sorry if my message was not understood as I wanted :) Ben On Apr 15, 2013, at 4:55 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Apr 15, 2013, at 4:45 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
When you fell unproductive -- stuck -- because you read library code you have to use but you don't understand it, or at least not deeply enough, it is not funny.
Yes this is why ben said that this is always worth to document.
STef
Le 15/04/2013 12:18, Benjamin a écrit :
It always make sense :)
At the end, everything will be deprecated once :)
-- Dr. Geo http://drgeo.eu
+1 On Apr 15, 2013, at 5:54 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
Exactly :)
I am saying that because I have this kind of question when I spend days documenting Morphic infrastructure :)
Everyone is like "Yeah, but we will throw away this crap", and that's perfectly true. But in mid-time so poor guys have to stuck with the existing infrastructure (like you in this case), and I really think it makes perfect sense to document something even if it will be deprecated in 6 months. First because even deprecated it will still be used during 1 year and a half. Moreover I deeply do not believe in a perfect system where nothing need to be changed anymore, so at some point everything will be deprecated and rewritten, that's why I said that even if something will be deprecated, it worth to be documented :)
Sorry if my message was not understood as I wanted :)
Ben
On Apr 15, 2013, at 4:55 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Apr 15, 2013, at 4:45 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
When you fell unproductive -- stuck -- because you read library code you have to use but you don't understand it, or at least not deeply enough, it is not funny.
Yes this is why ben said that this is always worth to document.
STef
Le 15/04/2013 12:18, Benjamin a écrit :
It always make sense :)
At the end, everything will be deprecated once :)
-- Dr. Geo http://drgeo.eu
+1 - There is really no such thing as a temporary solution! :) From my industrial/mining experience, many "temporary" solutions can be found in operation years later... Benjamin wrote:
Exactly :)
I am saying that because I have this kind of question when I spend days documenting Morphic infrastructure :)
Everyone is like "Yeah, but we will throw away this crap", and that's perfectly true. But in mid-time so poor guys have to stuck with the existing infrastructure (like you in this case), and I really think it makes perfect sense to document something even if it will be deprecated in 6 months. First because even deprecated it will still be used during 1 year and a half. Moreover I deeply do not believe in a perfect system where nothing need to be changed anymore, so at some point everything will be deprecated and rewritten, that's why I said that even if something will be deprecated, it worth to be documented :)
Sorry if my message was not understood as I wanted :)
Ben
On Apr 15, 2013, at 4:55 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Apr 15, 2013, at 4:45 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
When you fell unproductive -- stuck -- because you read library code you have to use but you don't understand it, or at least not deeply enough, it is not funny.
Yes this is why ben said that this is always worth to document.
STef
Le 15/04/2013 12:18, Benjamin a écrit :
It always make sense :)
At the end, everything will be deprecated once :)
-- Dr. Geo http://drgeo.eu
Once I get done witjh it I will write a small note on the collaboractive book. Btw, I never feel it is crap, just a big piece of library code without much documentation. Hilaire Le 15/04/2013 17:54, Benjamin a écrit :> I am saying that because I have this kind of question when I spend days
documenting Morphic infrastructure :)
Everyone is like "Yeah, but we will throw away this crap", and that's perfectly true.
-- Dr. Geo http://drgeo.eu
Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
It looks great with a lot of options. It has a lot of use cases. It will be even greater if its logic and some of the key methods were commented. Thanks Hilaire -- Dr. Geo http://drgeo.eu
Hi, I need a tree with a depth level of 2. When unfolding at level 1, the subnode is a list of attribute in-place-editable. Unlike the setting browser, the attribute should not be edit in a second column; it will take too much place in my context. Is it doeable with MorphTreeMorph et al.? Thanks Hilaire Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
-- Dr. Geo http://drgeo.eu
Le 15/04/2013 10:51, Hilaire Fernandes a écrit :
Hi,
I need a tree with a depth level of 2. When unfolding at level 1, the subnode is a list of attribute in-place-editable. Unlike the setting browser, the attribute should not be edit in a second column; it will take too much place in my context. Is it doeable with MorphTreeMorph et al.?
You mean a single column tree display ? Yes. Just do not create additional columns. Thierry
Thanks
Hilaire
Le 14/04/2013 14:26, Benjamin a écrit :
MorphTreeMorph i would say
On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 15/04/2013 11:02, Goubier Thierry a écrit :> You mean a single column tree display ? Yes. Just do not create
additional columns.
Thierry
If I understand correctly the logic, it should be two columns. At columns 2, the nodes attributes you can edit-in-place. For example [-]-Point A(1;2) | | | |--- Free point | |--- Name: A | |--- position: 1@2 | |--- shape: =o v= | |--- size: round | |--- color: red | [+]-Point B(5;5) | [+]-Segment [AB] Hilaire -- Dr. Geo http://drgeo.eu
Le 15/04/2013 11:08, Hilaire Fernandes a écrit :
Le 15/04/2013 11:02, Goubier Thierry a écrit :> You mean a single column tree display ? Yes. Just do not create
additional columns.
Thierry
If I understand correctly the logic, it should be two columns. At columns 2, the nodes attributes you can edit-in-place.
You can... Have one colum with a two levels tree in it, and an editing pane to edit the values (it's a quite common approach in other GUI worlds). Or a two-column morph with a two level tree like the settings manager; in the right colum you have the editing morph or nothing or a read-only morph. Would you be OK with the Settings browser approach? Thierry
For example
[-]-Point A(1;2) | | | |--- Free point | |--- Name: A | |--- position: 1@2 | |--- shape: =o v= | |--- size: round | |--- color: red | [+]-Point B(5;5) | [+]-Segment [AB]
Hilaire
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 15/04/2013 11:23, Goubier Thierry a écrit :
You can...
Have one colum with a two levels tree in it, and an editing pane to edit the values (it's a quite common approach in other GUI worlds).
Or a two-column morph with a two level tree like the settings manager; in the right colum you have the editing morph or nothing or a read-only morph.
Would you be OK with the Settings browser approach?
I think no, as it may consume too much place. You can imagine the second column of the settings browser to be a canvas view in my case. The tree view is a hierarchical view of the canvas to browse and to edit items displayed in the canvas. Hilaire -- Dr. Geo http://drgeo.eu
Le 15/04/2013 11:29, Hilaire Fernandes a écrit :
Le 15/04/2013 11:23, Goubier Thierry a écrit :
You can...
Have one colum with a two levels tree in it, and an editing pane to edit the values (it's a quite common approach in other GUI worlds).
Or a two-column morph with a two level tree like the settings manager; in the right colum you have the editing morph or nothing or a read-only morph.
Would you be OK with the Settings browser approach?
I think no, as it may consume too much place. You can imagine the second column of the settings browser to be a canvas view in my case. The tree view is a hierarchical view of the canvas to browse and to edit items displayed in the canvas.
Ok, so you would like the node morph in the tree to be editable in place, but only for the attributes? Single column MorphTreeMorph with nodes that you can edit? I found that if you set an editable morph as the node in a tree, then you can really edit it in the tree :) In that case, you may just need to change the nodeStringGetter: when you initialize your MorphTreeMorph. It will call asMorph on the result of calling that selector on your item; if you happen to build a morph as a reply then it should return it as it is. Just then, for your attributes, return a Morph containing a label and a text field well linked to your item. This should be cool to use :) I'll keep it in my good-ideas-to-try notebook :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Very promising, this example ;-) Does this mean that xml will be deprecated too? On Mon, Apr 15, 2013 at 1:08 PM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Le 15/04/2013 11:02, Goubier Thierry a écrit :> You mean a single column tree display ? Yes. Just do not create
additional columns.
Thierry
If I understand correctly the logic, it should be two columns. At columns 2, the nodes attributes you can edit-in-place.
For example
[-]-Point A(1;2) | | | |--- Free point | |--- Name: A | |--- position: 1@2 | |--- shape: =o v= | |--- size: round | |--- color: red | [+]-Point B(5;5) | [+]-Segment [AB]
Hilaire
-- Dr. Geo http://drgeo.eu
Le 15/04/2013 19:54, Alain Busser a écrit :
Very promising, this example ;-)
Does this mean that xml will be deprecated too?
No, it is just an alternate way to present the attributes in the drgeo UI. What primary interest me is to present to the user the math items in a chronological/historical list. Hilaire -- Dr. Geo http://drgeo.eu
Le 14/04/2013 14:15, Hilaire Fernandes a écrit :
Hi,
We have two players in town. I want to use a tree morph. On some nodes I want different font, on other ones I want custom morph.
Which one should I investigate on?
I personally use MorphTreeMorph. It's reasonably fast (a lot faster than PluggableTreeMorph), very powerfull (too powerfull) and I maintain / correct the drag and drop code in it. It does custom morph rather well, and I have checked / introduced a few hooks to do partial tree rebuilding in it, i.e. rebuilding a sub-tree when a node changes. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (6)
-
Alain Busser -
Ben Coman -
Benjamin -
Goubier Thierry -
Hilaire Fernandes -
stephane ducasse