On Apr 5, 2011, at 5:31 PM, Alexandre Bergel wrote:

Hi Guys,

Maybe I missed part of the discussion, but what is Nautilus?

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph

Squeaksource simply says "A new browser"

Cheers, Alexandre

It is not. The idea is to have a default browser and set of tools that we can use in bare core image and that are not based on toolBuilder or stringHolder. After if Glamour produces a nice IDE then we can load it and use it. In addition benjamin is fixing a lot of problems in default widgets like multiple selection, hilighting.... Stef

Hi, how does it relate to glamourost?

thanks, Mike

On Tue, Apr 5, 2011 at 7:57 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Apr 5, 2011, at 5:31 PM, Alexandre Bergel wrote:

...

Hi Guys,

Maybe I missed part of the discussion, but what is Nautilus?

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

Hi, Indeed, it would be great to have a Debugger model. Toon produced one in the context of the Glamorous Toolkit. Perhaps it would be good if we merged it in the Core. Cheers, Doru On 6 Apr 2011, at 12:54, Michael Roberts wrote:

Ok. And is the idea to build a new core debugger in this effort? I wanted to check we would only build 1 debugger model; and to know where it is. (I only see one in glamourst source).

Thanks Mike

On 6 Apr 2011, at 07:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

It is not. The idea is to have a default browser and set of tools that we can use in bare core image and that are not based on toolBuilder or stringHolder. After if Glamour produces a nice IDE then we can load it and use it. In addition benjamin is fixing a lot of problems in default widgets like multiple selection, hilighting....

Stef

...

Hi, how does it relate to glamourost?

thanks, Mike

On Tue, Apr 5, 2011 at 7:57 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Apr 5, 2011, at 5:31 PM, Alexandre Bergel wrote:

...

Hi Guys,

Maybe I missed part of the discussion, but what is Nautilus?

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

-- www.tudorgirba.com "Being happy is a matter of choice."

It works. Toon, am I wrong? Cheers, Doru On 6 Apr 2011, at 13:18, Stéphane Ducasse wrote:

On Apr 6, 2011, at 1:08 PM, Tudor Girba wrote:

...

Hi,

Indeed, it would be great to have a Debugger model. Toon produced one in the context of the Glamorous Toolkit. Perhaps it would be good if we merged it in the Core.

As soon as it works I want that in the core :) imagine a model not mixed with UI concerned :) Stef

...

Cheers, Doru

On 6 Apr 2011, at 12:54, Michael Roberts wrote:

...

Ok. And is the idea to build a new core debugger in this effort? I wanted to check we would only build 1 debugger model; and to know where it is. (I only see one in glamourst source).

Thanks Mike

On 6 Apr 2011, at 07:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

It is not. The idea is to have a default browser and set of tools that we can use in bare core image and that are not based on toolBuilder or stringHolder. After if Glamour produces a nice IDE then we can load it and use it. In addition benjamin is fixing a lot of problems in default widgets like multiple selection, hilighting....

Stef

...

Hi, how does it relate to glamourost?

thanks, Mike

On Tue, Apr 5, 2011 at 7:57 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Apr 5, 2011, at 5:31 PM, Alexandre Bergel wrote:

...

Hi Guys,

Maybe I missed part of the discussion, but what is Nautilus?

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

-- www.tudorgirba.com

"Being happy is a matter of choice."

-- www.tudorgirba.com "We are all great at making mistakes."

Why omnibrowser is bad? Is omnibrowser idea for building browsers failed? 2011/4/6 Stéphane Ducasse <stephane.ducasse@inria.fr>

It is not. The idea is to have a default browser and set of tools that we can use in bare core image and that are not based on toolBuilder or stringHolder. After if Glamour produces a nice IDE then we can load it and use it. In addition benjamin is fixing a lot of problems in default widgets like multiple selection, hilighting....

Stef

...

Hi, how does it relate to glamourost?

thanks, Mike

On Tue, Apr 5, 2011 at 7:57 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Apr 5, 2011, at 5:31 PM, Alexandre Bergel wrote:

...

Hi Guys,

Maybe I missed part of the discussion, but what is Nautilus?

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build

by TreeMorphTreeMorph

...

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

Le 05/04/2011 22:03, Alain Plantec a écrit :

Le 05/04/2011 20:57, Stéphane Ducasse a écrit :

...

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph yes, maybe MorphTreeMorph is not the good tree to use here. why not use a simpler one ? or try with LazyMorphTreeMorph even it should be improved. (it should be changed to build the list in background).

Alain

...

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

what about my initial question? it got buried beneath other discussions in this thread. Ben, can you give your opinion ? Im interested because for the SMx port, this would help in narrowing the classes to import. Fernando On Wed, Apr 6, 2011 at 9:08 AM, Tudor Girba <tudor.girba@gmail.com> wrote:

Hi,

On 6 Apr 2011, at 08:16, Alain Plantec wrote:

...

Le 05/04/2011 22:03, Alain Plantec a écrit :

...

Le 05/04/2011 20:57, Stéphane Ducasse a écrit :

...

A new browser :) Supporting    - groups    - package    - declarative menus    - environment selection    - scoped actions    - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph yes, maybe MorphTreeMorph is not the good tree to use here. why not use a simpler one ? or try with LazyMorphTreeMorph even it should be improved. (it should be changed to build the list in background).

That would be super cool :)

Doru

...

...

Alain

...

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

-- www.tudorgirba.com

"Presenting is storytelling."

I think that as soon as MorphTreeMorph is improved, you can use it for SMx, or take it as it is right now, and apply fixes ^^ Ben On Apr 6, 2011, at 10:17 AM, Fernando Olivero wrote:

what about my initial question? it got buried beneath other discussions in this thread. Ben, can you give your opinion ? Im interested because for the SMx port, this would help in narrowing the classes to import.

Fernando

On Wed, Apr 6, 2011 at 9:08 AM, Tudor Girba <tudor.girba@gmail.com> wrote:

...

Hi,

On 6 Apr 2011, at 08:16, Alain Plantec wrote:

...

Le 05/04/2011 22:03, Alain Plantec a écrit :

...

Le 05/04/2011 20:57, Stéphane Ducasse a écrit :

...

A new browser :) Supporting - groups - package - declarative menus - environment selection - scoped actions - soon refactoring

but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph yes, maybe MorphTreeMorph is not the good tree to use here. why not use a simpler one ? or try with LazyMorphTreeMorph even it should be improved. (it should be changed to build the list in background).

That would be super cool :)

Doru

...

...

Alain

...

...

Squeaksource simply says "A new browser"

Cheers, Alexandre

-- www.tudorgirba.com

"Presenting is storytelling."

On 6 April 2011 13:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Because once people are dependent and drug addict then they will spend time fixing it :)

No seriously this is mega hyper hyper important that we get        - solid scalable listMorph and treeMorph So the best way is to stress it.

The second answer is that nautilus is cool and needs tree :)

i second that. trees and lists are basic widgets which could be used for different means. So why we should limit ourselves and use some crappy lists to mimic tree, instead of using trees, and improving this widget and making it work well. -- Best regards, Igor Stasenko AKA sig.

Thanks Ben and Stef, the answer was in concordance with what i was thinking. CUIS already has the TextModel class, and the PluggableTextModel class. So together with the menu pragma builders of Pharo, they provide the foundations for the implementation you just nicely explained. Next week, once i finish writing something for my research, i will finish the initial port. And hopefully provide a working example of SMx in Pharo, applying the ideas here discussed. A somehow initial port, which can get expanded gradually, from the list of widgets we mentioned in previous emails: MorphTreeMorph, etc.. (and at a final stage Polymorph). Fernando pd: Alex, SMx is SimpleMorph, an older version of the cleaned up Morphic from the CUIS image. On Wed, Apr 6, 2011 at 6:19 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

YES!YES!YES! It is cool to see your impact on them. Excellent it will really helps bringing pharo IDE to the next level.

Stef

On Apr 6, 2011, at 2:11 PM, Igor Stasenko wrote:

...

On 6 April 2011 13:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Because once people are dependent and drug addict then they will spend time fixing it :)

No seriously this is mega hyper hyper important that we get        - solid scalable listMorph and treeMorph So the best way is to stress it.

The second answer is that nautilus is cool and needs tree :)

i second that. trees and lists are basic widgets which could be used for different means. So why we should limit ourselves and use some crappy lists to mimic tree, instead of using trees, and improving this widget and making it work well.

-- Best regards, Igor Stasenko AKA sig.

I agree, hope to something working really soon. Keep up the good work on Nautilus, finally someone is tackling this issue. pd: I've been tackling it from another perspective: less tool based and more object based, but for now i'm also into developing the next Gaucho. This would be the main driver for me, to port SMx. Hopefully we have the same requirements for SystemAnnouncements and RPackageOrganizer, and refactorings, and undos, and ..... On Wed, Apr 6, 2011 at 10:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Thanks fernando! this is cool to see some work on this front. We should work step by step. What I wanted to say is that while I value some part of CUIS. Other parts are still old and odd like its ancestor. Pharo is moving on a lot of front and people may not notice it but soon we will have a lot of pieces of the puzzle ready to get real benefit of the infrastructure we are steadily building :).

Stef

...

Thanks Ben and Stef, the answer was in concordance with what i was thinking.

CUIS already has the TextModel class, and the PluggableTextModel class. So together with the menu pragma builders of  Pharo, they provide the foundations for the implementation you just nicely explained.

Next week, once i finish writing something for my research, i will finish the initial port. And hopefully provide a working example of SMx in Pharo, applying the ideas here discussed. A somehow initial port, which can get expanded gradually, from the list of widgets we mentioned in previous emails: MorphTreeMorph, etc.. (and at a final stage Polymorph).

Fernando pd: Alex, SMx is SimpleMorph, an older version of the cleaned up Morphic from the CUIS image.

On Wed, Apr 6, 2011 at 6:19 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

YES!YES!YES! It is cool to see your impact on them. Excellent it will really helps bringing pharo IDE to the next level.

Stef

On Apr 6, 2011, at 2:11 PM, Igor Stasenko wrote:

...

On 6 April 2011 13:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Because once people are dependent and drug addict then they will spend time fixing it :)

No seriously this is mega hyper hyper important that we get        - solid scalable listMorph and treeMorph So the best way is to stress it.

The second answer is that nautilus is cool and needs tree :)

i second that. trees and lists are basic widgets which could be used for different means. So why we should limit ourselves and use some crappy lists to mimic tree, instead of using trees, and improving this widget and making it work well.

-- Best regards, Igor Stasenko AKA sig.

pd: Alex, SMx is SimpleMorph, an older version of the cleaned up Morphic from the CUIS image.

Ok, thanks Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Geert Claes wrote:

How does one load Nautilus? I tried by adding the nautilus repository and using the ConfigurationOf on a clean 1.2 OneClick but I get a DNU readStream?

Mmm, seems to be a network issue because I get the same message for other stuff :( -- View this message in context: http://forum.world.st/abouth-nautilus-and-the-removal-of-CodeHolder-hierarch... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Apr 6, 2011, at 1:19 PM, Stéphane Ducasse wrote:

On Apr 5, 2011, at 2:32 PM, Fernando Olivero wrote:

...

Hi Ben, i was thinking about the discussion of the menus:

Since you are using menu pragma builder, and have explicit views for each tool, then the CodeHolder hierarchy is no longer needed. Because the specialized views get the behavior for answering the actions in the menus (which currently is spread across the StringHolder hierarchy).

I would say yes but I will let ben replied with more depth if necessary.

There is two kinds of menus, menus provided by the lists/trees and menus provided by the pluggable text morph. They're different because first ones really act on the model elements (here classes/methods/etc), when second ones act on text For lists/trees menus, because they act on your model have to be handled locally ( by your model or your view depending of the action ). For text menus, they act on text, and will always act on text, so they should be managed by a kind of TextModel, because it's not the role of your Browser to tell how to implement copy/paste, or implementors :)

...

So this is the main reason why you simple need a pluggable text model, for the model of the views. And a pluggable TextModel (or StringHolder in Pharo) would suffice? Is this correct?

...

...

Thanks,

...

Fernando

StringHolder shouldn't exist anymore :) For Nautilus, menus actions are handled by the view, but could/should be moved in the model for some of them, but it can be a bit hard to separate the ones only related to the view, and ones relatives to the model ... And text menus are handled by the PluggableTextMorph whose model is SmalltalkEditor. So it's SmalltalkEditor responsibility to know how to look for senders/implementors/etc I hope it answer your question ^^ Ben