Nautilus Tree

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Nautilus Tree

Sean P. DeNigris
Administrator
That's really cool that we have started making the package list more manageable!

I noticed that right now, separate packages within the same project are not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will be siblings in the tree, instead of both under MyProject. It seems like it would be more useful to have
- MyProject
  - Core
  - Platform
in the tree
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Sean P. DeNigris
Administrator
Sean P. DeNigris wrote
I noticed that right now, separate packages within the same project are not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will be siblings in the tree, instead of both under MyProject. It seems like it would be more useful to have
- MyProject
  - Core
  - Platform
in the tree
Bump... thoughts?
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
I dont see much room for thought, this looks to me like ideal behavior. 


On Fri, Nov 29, 2013 at 6:20 PM, Sean P. DeNigris <[hidden email]> wrote:
Sean P. DeNigris wrote
> I noticed that right now, separate packages within the same project are
> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
> will be siblings in the tree, instead of both under MyProject. It seems
> like it would be more useful to have
> - MyProject
>   - Core
>   - Platform
> in the tree

Bump... thoughts?



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Nautilus-Tree-tp4723819p4726272.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Benjamin Van Ryseghem (Pharo)
+1

Ben

On 29 Nov 2013, at 17:25, kilon alios <[hidden email]> wrote:

I dont see much room for thought, this looks to me like ideal behavior. 


On Fri, Nov 29, 2013 at 6:20 PM, Sean P. DeNigris <[hidden email]> wrote:
Sean P. DeNigris wrote
> I noticed that right now, separate packages within the same project are
> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
> will be siblings in the tree, instead of both under MyProject. It seems
> like it would be more useful to have
> - MyProject
>   - Core
>   - Platform
> in the tree

Bump... thoughts?



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Nautilus-Tree-tp4723819p4726272.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Sean P. DeNigris
Administrator
In reply to this post by kilon.alios
kilon alios wrote
I dont see much room for thought, this looks to me like ideal behavior.
I agree in theory, but it seems that the tree is primarily about chunking information into manageable pieces.

A primary difficulty here is that packages are often divided for reasons that have nothing to do with the domain model, e.g. the ubiquitous MyPackage-Platform, which is an artifact of Metacello that is not all that relevant to a user wanting to understand the system.

From the naive user perspective, if I'm exploring from the top level of the system, I want to see things like:
- CodeImport
- Collections
- Compiler

From this perspective, the 14 entries for Collections, multiplied by a few dozen top-level categories make the list unwieldy and only marginally less daunting than the flattened list we used to have (see http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ):


Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. 

My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one

a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. 

b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont "exist" only their tags will "exist". 

I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. 

So for me at least smart browsing  plus tags plus good search facility can easily replace ugly hierarchy trees and packages with really long names. 

Just using common logic can take you a long way into improving the tools, the hard part is actually coding all this because it takes time and effort. 


On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]> wrote:
kilon alios wrote
> I dont see much room for thought, this looks to me like ideal behavior.

I agree in theory, but it seems that the tree is primarily about chunking
information into manageable pieces.

A primary difficulty here is that packages are often divided for reasons
that have nothing to do with the domain model, e.g. the ubiquitous
MyPackage-Platform, which is an artifact of Metacello that is not all that
relevant to a user wanting to understand the system.

From the naive user perspective, if I'm exploring from the top level of the
system, I want to see things like:
- CodeImport
- Collections
- Compiler

From this perspective, the 14 entries for Collections, multiplied by a few
dozen top-level categories make the list unwieldy and only marginally less
daunting than the flattened list we used to have (see
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ):
<http://forum.world.st/file/n4726287/Picture_1.png>





-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Stéphane Ducasse
In reply to this post by Sean P. DeNigris

On Nov 29, 2013, at 5:20 PM, Sean P. DeNigris <[hidden email]> wrote:

> Sean P. DeNigris wrote
>> I noticed that right now, separate packages within the same project are
>> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
>> will be siblings in the tree, instead of both under MyProject. It seems
>> like it would be more useful to have
>> - MyProject
>>  - Core
>>  - Platform
>> in the tree
>
> Bump... thoughts?

I do not care and i'm not sure that I want to have three levels all the time
        project
                package
                        tags/categories

especially since project do not exist.

For now just what we have but fully working would be good.

Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

philippeback
I do not. Scoped browsing is better for me. 

Search beats Prem a Fe organization. 

Ask Google.  Search is like addition for them

Phil

On Friday, November 29, 2013, Stéphane Ducasse wrote:

On Nov 29, 2013, at 5:20 PM, Sean P. DeNigris <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;sean@clipperadams.com&#39;)">sean@...> wrote:

> Sean P. DeNigris wrote
>> I noticed that right now, separate packages within the same project are
>> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
>> will be siblings in the tree, instead of both under MyProject. It seems
>> like it would be more useful to have
>> - MyProject
>>  - Core
>>  - Platform
>> in the tree
>
> Bump... thoughts?

I do not care and i'm not sure that I want to have three levels all the time
        project
                package
                        tags/categories

especially since project do not exist.

For now just what we have but fully working would be good.



--
---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 


Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Goubier Thierry
In reply to this post by Sean P. DeNigris


Le 29/11/2013 17:20, Sean P. DeNigris a écrit :

> Sean P. DeNigris wrote
>> I noticed that right now, separate packages within the same project are
>> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
>> will be siblings in the tree, instead of both under MyProject. It seems
>> like it would be more useful to have
>> - MyProject
>>    - Core
>>    - Platform
>> in the tree
>
> Bump... thoughts?

I've done that a while ago. But not in Nautilus.

Find it very convenient. Focused browsing, can forget most of the system
around my workset without effort.

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

Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Goubier Thierry
In reply to this post by kilon.alios


Le 29/11/2013 18:16, kilon alios a écrit :

> Currently I am working on Hyperion, a vector editor for Athens. Then I
> will work on Prometheas, on board documentation tool again with Athens.
>
> My third tool, if ever reach that far is Cyclops which will target the
> system browser. Now I am no fan of hierarchy trees. I find them hard to
> navigate and messy when hierarchy gets too complex. I see two solution
> on this one
>
> a) Sophisticated search facility, we have that already with the finder
> tool . I feel its time for the finder tool to go and be one with the
> system browser.

It's done for me (with the added fact that you want to return the search
results inside the system browser itself: done for me too). For
Nautilus, there is a need to reactivate the Finder plugin.

> b) Tag based browsing. That means attach tags to your classes and
> methods , make it easy this way to make things belong to groups and most
> importantly one thing could belong to more than one group. This also
> means bye bye packages, and instead replaced with infinite level groups,
> a group can be inside another group which can be inside another group
> etc. Of course those groups wont "exist" only their tags will "exist".

Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want
to look into dynamic tagging... which brings you to scoped browsing,
more or less.

> I am also smiling to the Glamour philosophy of having a browser tool
> that can have multiple ways of viewing your classes. Bottom line is that
> I will be using existing ideas and I hope also code to push things just
> tiny bit further.

Do it, do it! As I experienced myself, it's fairly easy to rebuilt a
complete system browser...

> So for me at least smart browsing  plus tags plus good search facility
> can easily replace ugly hierarchy trees and packages with really long
> names.

Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I
can remember where things are (and the tree also shorten long package
names ;)).

> Just using common logic can take you a long way into improving the
> tools, the hard part is actually coding all this because it takes time
> and effort.

Beware: there is no common logic in that (you're a specific case, I'd be
very unhappy with your GUI as far as I can see, and the reverse is also
true).

>
> On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     kilon alios wrote
>      > I dont see much room for thought, this looks to me like ideal
>     behavior.
>
>     I agree in theory, but it seems that the tree is primarily about
>     chunking
>     information into manageable pieces.
>
>     A primary difficulty here is that packages are often divided for reasons
>     that have nothing to do with the domain model, e.g. the ubiquitous
>     MyPackage-Platform, which is an artifact of Metacello that is not
>     all that
>     relevant to a user wanting to understand the system.
>
>      >From the naive user perspective, if I'm exploring from the top
>     level of the
>     system, I want to see things like:
>     - CodeImport
>     - Collections
>     - Compiler
>
>      >From this perspective, the 14 entries for Collections, multiplied
>     by a few
>     dozen top-level categories make the list unwieldy and only
>     marginally less
>     daunting than the flattened list we used to have (see
>     http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
>     ):
>     <http://forum.world.st/file/n4726287/Picture_1.png>
>
>
>
>
>
>     -----
>     Cheers,
>     Sean
>     --
>     View this message in context:
>     http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
>     Sent from the Pharo Smalltalk Developers mailing list archive at
>     Nabble.com.
>
>

--
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

Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
"It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."

that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.

"Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
"

My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. 

"Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."

It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "

Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. 

"Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."

Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . 


On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:


Le 29/11/2013 18:16, kilon alios a écrit :

Currently I am working on Hyperion, a vector editor for Athens. Then I
will work on Prometheas, on board documentation tool again with Athens.

My third tool, if ever reach that far is Cyclops which will target the
system browser. Now I am no fan of hierarchy trees. I find them hard to
navigate and messy when hierarchy gets too complex. I see two solution
on this one

a) Sophisticated search facility, we have that already with the finder
tool . I feel its time for the finder tool to go and be one with the
system browser.

It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.


b) Tag based browsing. That means attach tags to your classes and
methods , make it easy this way to make things belong to groups and most
importantly one thing could belong to more than one group. This also
means bye bye packages, and instead replaced with infinite level groups,
a group can be inside another group which can be inside another group
etc. Of course those groups wont "exist" only their tags will "exist".

Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.


I am also smiling to the Glamour philosophy of having a browser tool
that can have multiple ways of viewing your classes. Bottom line is that
I will be using existing ideas and I hope also code to push things just
tiny bit further.

Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...


So for me at least smart browsing  plus tags plus good search facility
can easily replace ugly hierarchy trees and packages with really long
names.

Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).


Just using common logic can take you a long way into improving the
tools, the hard part is actually coding all this because it takes time
and effort.

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).


On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
<mailto:[hidden email]>> wrote:

    kilon alios wrote
     > I dont see much room for thought, this looks to me like ideal
    behavior.

    I agree in theory, but it seems that the tree is primarily about
    chunking
    information into manageable pieces.

    A primary difficulty here is that packages are often divided for reasons
    that have nothing to do with the domain model, e.g. the ubiquitous
    MyPackage-Platform, which is an artifact of Metacello that is not
    all that
    relevant to a user wanting to understand the system.

     >From the naive user perspective, if I'm exploring from the top
    level of the
    system, I want to see things like:
    - CodeImport
    - Collections
    - Compiler

     >From this perspective, the 14 entries for Collections, multiplied
    by a few
    dozen top-level categories make the list unwieldy and only
    marginally less
    daunting than the flattened list we used to have (see
    http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
    ):
    <http://forum.world.st/file/n4726287/Picture_1.png>





    -----
    Cheers,
    Sean
    --
    View this message in context:
    http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
    Sent from the Pharo Smalltalk Developers mailing list archive at
    Nabble.com.



--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: <a href="tel:%2B33%20%280%29%201%2069%2008%2032%2092" value="+33169083292" target="_blank">+33 (0) 1 69 08 32 92 / 83 95


Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
ok I found this after some google search -> http://rmod.lille.inria.fr/web/pier?_s=HmL1nFoP1weCzRt7 .

Is there any more recent documentation on Nautilus plugin system or any other way of extending Nautilus ?


On Mon, Dec 2, 2013 at 11:05 AM, kilon alios <[hidden email]> wrote:
"It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."

that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.

"Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
"

My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. 

"Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."

It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "

Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. 

"Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."

Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . 


On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:


Le 29/11/2013 18:16, kilon alios a écrit :

Currently I am working on Hyperion, a vector editor for Athens. Then I
will work on Prometheas, on board documentation tool again with Athens.

My third tool, if ever reach that far is Cyclops which will target the
system browser. Now I am no fan of hierarchy trees. I find them hard to
navigate and messy when hierarchy gets too complex. I see two solution
on this one

a) Sophisticated search facility, we have that already with the finder
tool . I feel its time for the finder tool to go and be one with the
system browser.

It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.


b) Tag based browsing. That means attach tags to your classes and
methods , make it easy this way to make things belong to groups and most
importantly one thing could belong to more than one group. This also
means bye bye packages, and instead replaced with infinite level groups,
a group can be inside another group which can be inside another group
etc. Of course those groups wont "exist" only their tags will "exist".

Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.


I am also smiling to the Glamour philosophy of having a browser tool
that can have multiple ways of viewing your classes. Bottom line is that
I will be using existing ideas and I hope also code to push things just
tiny bit further.

Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...


So for me at least smart browsing  plus tags plus good search facility
can easily replace ugly hierarchy trees and packages with really long
names.

Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).


Just using common logic can take you a long way into improving the
tools, the hard part is actually coding all this because it takes time
and effort.

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).


On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
<mailto:[hidden email]>> wrote:

    kilon alios wrote
     > I dont see much room for thought, this looks to me like ideal
    behavior.

    I agree in theory, but it seems that the tree is primarily about
    chunking
    information into manageable pieces.

    A primary difficulty here is that packages are often divided for reasons
    that have nothing to do with the domain model, e.g. the ubiquitous
    MyPackage-Platform, which is an artifact of Metacello that is not
    all that
    relevant to a user wanting to understand the system.

     >From the naive user perspective, if I'm exploring from the top
    level of the
    system, I want to see things like:
    - CodeImport
    - Collections
    - Compiler

     >From this perspective, the 14 entries for Collections, multiplied
    by a few
    dozen top-level categories make the list unwieldy and only
    marginally less
    daunting than the flattened list we used to have (see
    http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
    ):
    <http://forum.world.st/file/n4726287/Picture_1.png>





    -----
    Cheers,
    Sean
    --
    View this message in context:
    http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
    Sent from the Pharo Smalltalk Developers mailing list archive at
    Nabble.com.



--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: <a href="tel:%2B33%20%280%29%201%2069%2008%2032%2092" value="+33169083292" target="_blank">+33 (0) 1 69 08 32 92 / 83 95



Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Goubier Thierry
In reply to this post by kilon.alios


Le 02/12/2013 10:05, kilon alios a écrit :

> "It's done for me (with the added fact that you want to return the
> search results inside the system browser itself: done for me too). For
> Nautilus, there is a need to reactivate the Finder plugin."
>
> that's great to hear, this makes things much easier for me. How to
> reactivate that plugin ? Also where I can find documentation for the
> Nautilus plugin system ? I have no intention of reinventing the wheel,
> if I can just extend Nautilus that would be great. Having this option
> means I could even start Cyclops now, cause it will take me much less
> time than I expected.
>
> "Takes ages to tag correctly a system as large as Pharo nowadays.
>
> Such a graph can also makes things very complex at times. You may want
> to look into dynamic tagging... which brings you to scoped browsing,
> more or less.
> "
>
> My plan was to offer tagging for some classes I heavily use but
> obviously not all. I wanted to allow user to create their own tags even
> custom ones and sync automatically with other users against a common
> online tag repository.

Yes, that can be interesting. A good tagging / oragnization creation GUI
can be nice.

> "Up to you :)
>
> Me, I have a fairly good spatial memory, so a tree helps me because I
> can remember where things are (and the tree also shorten long package
> names ;))."
>
> It was not my intention to offer ONLY a tag system, hierarchy trees are
> useful too. I see the tag system as another alternative way of viewing
> classes and methods not as a complete replacement
> to hierarchy trees.Also the tree hides part of the name but force you to
> make long package names to use the tree anyway. Am I wrong ?

No. What I have is in fact a category hierachy + a name matching scheme.

* The category hierarchy starts with top level items (Core, GUI, System,
Packages, Networking, Development), with sub categories (such as Spec in
GUI). I could have as many level of subcategories as I want.

* Then I have a name matching scheme: a package starting with Spec will
be put under GUI/Spec... If there is a common core, I improve on that
and add subcategories under Spec to do Spec-Gui (for the packages
Spec-Gui-Morphic, Spec-GUI-Amber, Spec-GUI-MVC, Spec_GUI-Gtk), and so on.

The tree does automatic prefix reduction: if parent item is XXX and
current item is XXXYYY then current item display is YYY.

It also has an ability to clean up the system: load
ConfigurationOfSomething in, it will be moved under
Packages/Configuration/. You can load hundreds of configurations and
they will all be stored there and you won't be annoyed by the length of
the packages list (unless you open the Monticello Browser, of course :P).

All this is to target the 7 +/-2 magic number HCI strives for. And the
fact that we usually have a fairly good memory to find back things (they
are allways in the same position).

> " Beware: there is no common logic in that (you're a specific case, I'd
> be very unhappy with your GUI as far as I can see, and the reverse is
> also true). "
>
> Common logic means exactly what is implied, logic which some people
> agree on. Obviously nothing is absolute and people
> have different workflow which I respect and love to hear about them ;)
> I definitely would not want to force people doing things a single way.
> Anything can useful.

Yes, that's why I suggest experiments... There is a lot of tuning necessary.

For example, I played a lot with automatic scoping in browsing and
search... And backed off a bit because it made a mess of my search and
understand workflow. I used to do like that:
- looked at a method in a class
- select implementors on a selector in the method source
- get a browser scoped with only the implementors of that selector
- look for an implementor in that browser...
- :( empty browser because I was looking inside the previous scope

So, now, if I ask for implementors in a selector scope, I back off one
level in scoping: if the parent scope was a package, I'll search in the
package scope.

> "Do it, do it! As I experienced myself, it's fairly easy to rebuilt a
> complete system browser..."
>
> Is it or are you being sarcastic ? It was never my intention to rebuilt
> a complete system browser, just reskin and extend the existing one. I
> find the system browser already extremely powerful and fun to use , I
> just wanted to add my own touches to it. This is why I was considering
> Glamour .

No, no, really. The underlying system is a bit hard to get into and
isn't too well described, but it has everything you need to build one.

Even mine... The specifics are the tree handling, but, honestly, you
could use any other way to classify the code and replace that part of
the GUI, reusing all the command and tracking system events logic. I
reused code from the other browsers as well; I have a lot of respect for
the architecture of the OmniBrowser, and for the features of Nautilus.

Thierry

> On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     Le 29/11/2013 18:16, kilon alios a écrit :
>
>         Currently I am working on Hyperion, a vector editor for Athens.
>         Then I
>         will work on Prometheas, on board documentation tool again with
>         Athens.
>
>         My third tool, if ever reach that far is Cyclops which will
>         target the
>         system browser. Now I am no fan of hierarchy trees. I find them
>         hard to
>         navigate and messy when hierarchy gets too complex. I see two
>         solution
>         on this one
>
>         a) Sophisticated search facility, we have that already with the
>         finder
>         tool . I feel its time for the finder tool to go and be one with the
>         system browser.
>
>
>     It's done for me (with the added fact that you want to return the
>     search results inside the system browser itself: done for me too).
>     For Nautilus, there is a need to reactivate the Finder plugin.
>
>
>         b) Tag based browsing. That means attach tags to your classes and
>         methods , make it easy this way to make things belong to groups
>         and most
>         importantly one thing could belong to more than one group. This also
>         means bye bye packages, and instead replaced with infinite level
>         groups,
>         a group can be inside another group which can be inside another
>         group
>         etc. Of course those groups wont "exist" only their tags will
>         "exist".
>
>
>     Takes ages to tag correctly a system as large as Pharo nowadays.
>
>     Such a graph can also makes things very complex at times. You may
>     want to look into dynamic tagging... which brings you to scoped
>     browsing, more or less.
>
>
>         I am also smiling to the Glamour philosophy of having a browser tool
>         that can have multiple ways of viewing your classes. Bottom line
>         is that
>         I will be using existing ideas and I hope also code to push
>         things just
>         tiny bit further.
>
>
>     Do it, do it! As I experienced myself, it's fairly easy to rebuilt a
>     complete system browser...
>
>
>         So for me at least smart browsing  plus tags plus good search
>         facility
>         can easily replace ugly hierarchy trees and packages with really
>         long
>         names.
>
>
>     Up to you :)
>
>     Me, I have a fairly good spatial memory, so a tree helps me because
>     I can remember where things are (and the tree also shorten long
>     package names ;)).
>
>
>         Just using common logic can take you a long way into improving the
>         tools, the hard part is actually coding all this because it
>         takes time
>         and effort.
>
>
>     Beware: there is no common logic in that (you're a specific case,
>     I'd be very unhappy with your GUI as far as I can see, and the
>     reverse is also true).
>
>
>         On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>__>
>         wrote:
>
>              kilon alios wrote
>               > I dont see much room for thought, this looks to me like
>         ideal
>              behavior.
>
>              I agree in theory, but it seems that the tree is primarily
>         about
>              chunking
>              information into manageable pieces.
>
>              A primary difficulty here is that packages are often
>         divided for reasons
>              that have nothing to do with the domain model, e.g. the
>         ubiquitous
>              MyPackage-Platform, which is an artifact of Metacello that
>         is not
>              all that
>              relevant to a user wanting to understand the system.
>
>               >From the naive user perspective, if I'm exploring from
>         the top
>              level of the
>              system, I want to see things like:
>              - CodeImport
>              - Collections
>              - Compiler
>
>               >From this perspective, the 14 entries for Collections,
>         multiplied
>              by a few
>              dozen top-level categories make the list unwieldy and only
>              marginally less
>              daunting than the flattened list we used to have (see
>         http://en.wikipedia.org/wiki/__The_Magical_Number_Seven,___Plus_or_Minus_Two
>         <http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>
>              ):
>              <http://forum.world.st/file/__n4726287/Picture_1.png
>         <http://forum.world.st/file/n4726287/Picture_1.png>>
>
>
>
>
>
>              -----
>              Cheers,
>              Sean
>              --
>              View this message in context:
>         http://forum.world.st/__Nautilus-Tree-__tp4723819p4726287.html
>         <http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html>
>              Sent from the Pharo Smalltalk Developers mailing list
>         archive at
>              Nabble.com.
>
>
>
>     --
>     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
>     <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
>
>

--
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

Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Benjamin Van Ryseghem (Pharo)
In reply to this post by kilon.alios
You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/

I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility.
The idea is also that what you are browsing influence the browser. And Spec is good for that 
(as you can already see in the inspector)

Ben

On 02 Dec 2013, at 10:05, kilon alios <[hidden email]> wrote:

"It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."

that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.

"Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
"

My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. 

"Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."

It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "

Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. 

"Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."

Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . 


On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:


Le 29/11/2013 18:16, kilon alios a écrit :

Currently I am working on Hyperion, a vector editor for Athens. Then I
will work on Prometheas, on board documentation tool again with Athens.

My third tool, if ever reach that far is Cyclops which will target the
system browser. Now I am no fan of hierarchy trees. I find them hard to
navigate and messy when hierarchy gets too complex. I see two solution
on this one

a) Sophisticated search facility, we have that already with the finder
tool . I feel its time for the finder tool to go and be one with the
system browser.

It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.


b) Tag based browsing. That means attach tags to your classes and
methods , make it easy this way to make things belong to groups and most
importantly one thing could belong to more than one group. This also
means bye bye packages, and instead replaced with infinite level groups,
a group can be inside another group which can be inside another group
etc. Of course those groups wont "exist" only their tags will "exist".

Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.


I am also smiling to the Glamour philosophy of having a browser tool
that can have multiple ways of viewing your classes. Bottom line is that
I will be using existing ideas and I hope also code to push things just
tiny bit further.

Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...


So for me at least smart browsing  plus tags plus good search facility
can easily replace ugly hierarchy trees and packages with really long
names.

Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).


Just using common logic can take you a long way into improving the
tools, the hard part is actually coding all this because it takes time
and effort.

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).


On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
<mailto:[hidden email]>> wrote:

    kilon alios wrote
     > I dont see much room for thought, this looks to me like ideal
    behavior.

    I agree in theory, but it seems that the tree is primarily about
    chunking
    information into manageable pieces.

    A primary difficulty here is that packages are often divided for reasons
    that have nothing to do with the domain model, e.g. the ubiquitous
    MyPackage-Platform, which is an artifact of Metacello that is not
    all that
    relevant to a user wanting to understand the system.

     >From the naive user perspective, if I'm exploring from the top
    level of the
    system, I want to see things like:
    - CodeImport
    - Collections
    - Compiler

     >From this perspective, the 14 entries for Collections, multiplied
    by a few
    dozen top-level categories make the list unwieldy and only
    marginally less
    daunting than the flattened list we used to have (see
    http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
    ):
    <http://forum.world.st/file/n4726287/Picture_1.png>





    -----
    Cheers,
    Sean
    --
    View this message in context:
    http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
    Sent from the Pharo Smalltalk Developers mailing list archive at
    Nabble.com.



--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: <a href="tel:%2B33%20%280%29%201%2069%2008%2032%2092" value="+33169083292" target="_blank">+33 (0) 1 69 08 32 92 / 83 95



Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Benjamin Van Ryseghem (Pharo)
In reply to this post by kilon.alios
Links are generated :)


There is no newer documentation, but this one is still up t orate (at least concerning the plugin mechanism).
It is pretty simple.

Have a look at some plugins and you should get it pretty fast :)


Ben

On 02 Dec 2013, at 10:26, kilon alios <[hidden email]> wrote:

ok I found this after some google search -> http://rmod.lille.inria.fr/web/pier?_s=HmL1nFoP1weCzRt7 .

Is there any more recent documentation on Nautilus plugin system or any other way of extending Nautilus ?


On Mon, Dec 2, 2013 at 11:05 AM, kilon alios <[hidden email]> wrote:
"It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."

that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.

"Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
"

My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. 

"Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."

It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "

Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. 

"Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."

Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . 


On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:


Le 29/11/2013 18:16, kilon alios a écrit :

Currently I am working on Hyperion, a vector editor for Athens. Then I
will work on Prometheas, on board documentation tool again with Athens.

My third tool, if ever reach that far is Cyclops which will target the
system browser. Now I am no fan of hierarchy trees. I find them hard to
navigate and messy when hierarchy gets too complex. I see two solution
on this one

a) Sophisticated search facility, we have that already with the finder
tool . I feel its time for the finder tool to go and be one with the
system browser.

It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.


b) Tag based browsing. That means attach tags to your classes and
methods , make it easy this way to make things belong to groups and most
importantly one thing could belong to more than one group. This also
means bye bye packages, and instead replaced with infinite level groups,
a group can be inside another group which can be inside another group
etc. Of course those groups wont "exist" only their tags will "exist".

Takes ages to tag correctly a system as large as Pharo nowadays.

Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.


I am also smiling to the Glamour philosophy of having a browser tool
that can have multiple ways of viewing your classes. Bottom line is that
I will be using existing ideas and I hope also code to push things just
tiny bit further.

Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...


So for me at least smart browsing  plus tags plus good search facility
can easily replace ugly hierarchy trees and packages with really long
names.

Up to you :)

Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).


Just using common logic can take you a long way into improving the
tools, the hard part is actually coding all this because it takes time
and effort.

Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).


On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
<mailto:[hidden email]>> wrote:

    kilon alios wrote
     > I dont see much room for thought, this looks to me like ideal
    behavior.

    I agree in theory, but it seems that the tree is primarily about
    chunking
    information into manageable pieces.

    A primary difficulty here is that packages are often divided for reasons
    that have nothing to do with the domain model, e.g. the ubiquitous
    MyPackage-Platform, which is an artifact of Metacello that is not
    all that
    relevant to a user wanting to understand the system.

     >From the naive user perspective, if I'm exploring from the top
    level of the
    system, I want to see things like:
    - CodeImport
    - Collections
    - Compiler

     >From this perspective, the 14 entries for Collections, multiplied
    by a few
    dozen top-level categories make the list unwieldy and only
    marginally less
    daunting than the flattened list we used to have (see
    http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
    ):
    <http://forum.world.st/file/n4726287/Picture_1.png>





    -----
    Cheers,
    Sean
    --
    View this message in context:
    http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
    Sent from the Pharo Smalltalk Developers mailing list archive at
    Nabble.com.



--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: <a href="tel:%2B33%20%280%29%201%2069%2008%2032%2092" value="+33169083292" target="_blank">+33 (0) 1 69 08 32 92 / 83 95




Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

roberto.minelli@usi.ch
In reply to this post by Benjamin Van Ryseghem (Pharo)
> what you are browsing influence the browser.

Ben!! We should definitely sync on that!

On Dec 2, 2013, at 11:27 AM, Benjamin <[hidden email]> wrote:

> You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/
>
> I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility.
> The idea is also that what you are browsing influence the browser. And Spec is good for that
> (as you can already see in the inspector)
>
> Ben
>
> On 02 Dec 2013, at 10:05, kilon alios <[hidden email]> wrote:
>
>> "It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."
>>
>> that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.
>>
>> "Takes ages to tag correctly a system as large as Pharo nowadays.
>>
>> Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
>> "
>>
>> My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository.
>>
>> "Up to you :)
>>
>> Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."
>>
>> It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?
>>
>> " Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "
>>
>> Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful.
>>
>> "Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."
>>
>> Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour .
>>
>>
>> On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:
>>
>>
>> Le 29/11/2013 18:16, kilon alios a écrit :
>>
>> Currently I am working on Hyperion, a vector editor for Athens. Then I
>> will work on Prometheas, on board documentation tool again with Athens.
>>
>> My third tool, if ever reach that far is Cyclops which will target the
>> system browser. Now I am no fan of hierarchy trees. I find them hard to
>> navigate and messy when hierarchy gets too complex. I see two solution
>> on this one
>>
>> a) Sophisticated search facility, we have that already with the finder
>> tool . I feel its time for the finder tool to go and be one with the
>> system browser.
>>
>> It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.
>>
>>
>> b) Tag based browsing. That means attach tags to your classes and
>> methods , make it easy this way to make things belong to groups and most
>> importantly one thing could belong to more than one group. This also
>> means bye bye packages, and instead replaced with infinite level groups,
>> a group can be inside another group which can be inside another group
>> etc. Of course those groups wont "exist" only their tags will "exist".
>>
>> Takes ages to tag correctly a system as large as Pharo nowadays.
>>
>> Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
>>
>>
>> I am also smiling to the Glamour philosophy of having a browser tool
>> that can have multiple ways of viewing your classes. Bottom line is that
>> I will be using existing ideas and I hope also code to push things just
>> tiny bit further.
>>
>> Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...
>>
>>
>> So for me at least smart browsing  plus tags plus good search facility
>> can easily replace ugly hierarchy trees and packages with really long
>> names.
>>
>> Up to you :)
>>
>> Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).
>>
>>
>> Just using common logic can take you a long way into improving the
>> tools, the hard part is actually coding all this because it takes time
>> and effort.
>>
>> Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).
>>
>>
>> On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     kilon alios wrote
>>      > I dont see much room for thought, this looks to me like ideal
>>     behavior.
>>
>>     I agree in theory, but it seems that the tree is primarily about
>>     chunking
>>     information into manageable pieces.
>>
>>     A primary difficulty here is that packages are often divided for reasons
>>     that have nothing to do with the domain model, e.g. the ubiquitous
>>     MyPackage-Platform, which is an artifact of Metacello that is not
>>     all that
>>     relevant to a user wanting to understand the system.
>>
>>      >From the naive user perspective, if I'm exploring from the top
>>     level of the
>>     system, I want to see things like:
>>     - CodeImport
>>     - Collections
>>     - Compiler
>>
>>      >From this perspective, the 14 entries for Collections, multiplied
>>     by a few
>>     dozen top-level categories make the list unwieldy and only
>>     marginally less
>>     daunting than the flattened list we used to have (see
>>     http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
>>     ):
>>     <http://forum.world.st/file/n4726287/Picture_1.png>
>>
>>
>>
>>
>>
>>     -----
>>     Cheers,
>>     Sean
>>     --
>>     View this message in context:
>>     http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
>>     Sent from the Pharo Smalltalk Developers mailing list archive at
>>     Nabble.com.
>>
>>
>>
>> --
>> 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
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
Goubier thanks for the information, looks like it is as I assumed it is. Its a big motivation to know that there is so much modularity in the code. Its important that we have code that is easy to extend I think, this way we can try new ideas and keep what we like and throw away what we dont without worrying about the cost in development time. By the way I forgot to say that I love the  tree feature, definitely makes browsing packages much more manageable. I am also very excited that now we have a search bar for packages. Things definitely improve.  

thanks Benjamin I will have a look. Yes the plugin system looks very simple, I don't think will cause me any big problem. Is there a roadmap for Nautilus ? or is it "add whatever you want as long as is useful" approach ? 

I have to say that at times it makes me wonder. Pharo is a closed system, pharo code is suppose to run inside the pharo ide. So if its a closed system why we need case sensitivity and thinking hard about class and function names ? Why cant we choose many different names for each class and method and let the system choose the right class and method for us. I am also thinking namespaces, namespaces in language level are essential but at IDE level can be extremely useful as well. 

Lets say you dont like the names used for some classes and methods. Why go through the tedious process of subclassing and creating your own methods that call superclass methods just so you have better names for those methods. Just go in and add new names for those methods, while they keep their old ones. Name clashing ? no problemo, use tags as identifiers that will help you separate methods with same names.

For me pharo could have an extremely flexible naming system. No need for case sensitivity , no fear of names clashing. 

I guess that is what you Goubier were referring to as "scoped" browsing. 

Tags , namespaces, flexible searching via code completion could make it easy to use the right message even for a coder that does not know the name of the message or does not even know what kind of message he wants in his code. We could even abstract the whole process of coding, starting with ideas in form of DSL that gets transformed into pharo code in the process. This DSL will be a "bare bones" pharo code capable of mapping to ideas, ideal for brainstorming without the need to test code and worry about syntax etc. Later on that DSL would be able to change to pharo code and be as specific as needed to be proper code, generate its own tests etc.

These are some random ideas I have, more like brainstorming. But it does make me wonder because I feel that pharo can be so much more flexible than what an average language because the IDE is integrated and something we take for granted. So I think we could push things much further than anyone else.  

If all that sound crazy to you, its ok, I just love to brainstorm , I dont take every idea I have very seriously nor I am saying I will put these ideas to code. But I would like to know what you think about the direction pharo will be going on this matters. Namespaces for example is something we will need sooner or later because pharo will get only bigger and more complex.  


On Mon, Dec 2, 2013 at 12:32 PM, Roberto Minelli <[hidden email]> wrote:
> what you are browsing influence the browser.

Ben!! We should definitely sync on that!

On Dec 2, 2013, at 11:27 AM, Benjamin <[hidden email]> wrote:

> You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/
>
> I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility.
> The idea is also that what you are browsing influence the browser. And Spec is good for that
> (as you can already see in the inspector)
>
> Ben
>
> On 02 Dec 2013, at 10:05, kilon alios <[hidden email]> wrote:
>
>> "It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin."
>>
>> that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected.
>>
>> "Takes ages to tag correctly a system as large as Pharo nowadays.
>>
>> Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
>> "
>>
>> My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository.
>>
>> "Up to you :)
>>
>> Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))."
>>
>> It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ?
>>
>> " Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).  "
>>
>> Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful.
>>
>> "Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..."
>>
>> Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour .
>>
>>
>> On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <[hidden email]> wrote:
>>
>>
>> Le 29/11/2013 18:16, kilon alios a écrit :
>>
>> Currently I am working on Hyperion, a vector editor for Athens. Then I
>> will work on Prometheas, on board documentation tool again with Athens.
>>
>> My third tool, if ever reach that far is Cyclops which will target the
>> system browser. Now I am no fan of hierarchy trees. I find them hard to
>> navigate and messy when hierarchy gets too complex. I see two solution
>> on this one
>>
>> a) Sophisticated search facility, we have that already with the finder
>> tool . I feel its time for the finder tool to go and be one with the
>> system browser.
>>
>> It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin.
>>
>>
>> b) Tag based browsing. That means attach tags to your classes and
>> methods , make it easy this way to make things belong to groups and most
>> importantly one thing could belong to more than one group. This also
>> means bye bye packages, and instead replaced with infinite level groups,
>> a group can be inside another group which can be inside another group
>> etc. Of course those groups wont "exist" only their tags will "exist".
>>
>> Takes ages to tag correctly a system as large as Pharo nowadays.
>>
>> Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less.
>>
>>
>> I am also smiling to the Glamour philosophy of having a browser tool
>> that can have multiple ways of viewing your classes. Bottom line is that
>> I will be using existing ideas and I hope also code to push things just
>> tiny bit further.
>>
>> Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...
>>
>>
>> So for me at least smart browsing  plus tags plus good search facility
>> can easily replace ugly hierarchy trees and packages with really long
>> names.
>>
>> Up to you :)
>>
>> Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)).
>>
>>
>> Just using common logic can take you a long way into improving the
>> tools, the hard part is actually coding all this because it takes time
>> and effort.
>>
>> Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true).
>>
>>
>> On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     kilon alios wrote
>>      > I dont see much room for thought, this looks to me like ideal
>>     behavior.
>>
>>     I agree in theory, but it seems that the tree is primarily about
>>     chunking
>>     information into manageable pieces.
>>
>>     A primary difficulty here is that packages are often divided for reasons
>>     that have nothing to do with the domain model, e.g. the ubiquitous
>>     MyPackage-Platform, which is an artifact of Metacello that is not
>>     all that
>>     relevant to a user wanting to understand the system.
>>
>>      >From the naive user perspective, if I'm exploring from the top
>>     level of the
>>     system, I want to see things like:
>>     - CodeImport
>>     - Collections
>>     - Compiler
>>
>>      >From this perspective, the 14 entries for Collections, multiplied
>>     by a few
>>     dozen top-level categories make the list unwieldy and only
>>     marginally less
>>     daunting than the flattened list we used to have (see
>>     http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
>>     ):
>>     <http://forum.world.st/file/n4726287/Picture_1.png>
>>
>>
>>
>>
>>
>>     -----
>>     Cheers,
>>     Sean
>>     --
>>     View this message in context:
>>     http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html
>>     Sent from the Pharo Smalltalk Developers mailing list archive at
>>     Nabble.com.
>>
>>
>>
>> --
>> Thierry Goubier
>> CEA list
>> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
>> 91191 Gif sur Yvette Cedex
>> France
>> Phone/Fax: <a href="tel:%2B33%20%280%29%201%2069%2008%2032%2092" value="+33169083292">+33 (0) 1 69 08 32 92 / 83 95
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

Ben Coman
kilon alios wrote:
>
> Lets say you dont like the names used for some classes and methods.
> Why go through the tedious process of subclassing and creating your
> own methods that call superclass methods just so you have better names
> for those methods. Just go in and add new names for those methods,
> while they keep their old ones. Name clashing ? no problemo, use tags
> as identifiers that will help you separate methods with same names.
Sounds a bit (but not quite) like package "extensions" per the top half
of [1].
[1] http://seandenigris.com/blog/?p=1015

cheers -ben





Reply | Threaded
Open this post in threaded view
|

Re: Nautilus Tree

kilon.alios
no its not , this blog post is about extending existing classes with new methods that are stored to other packages instead of creating subclasses.

My point is about offering multiple names (not just one) to existing methods and classes, plus tags to further identify the methods so it is much easier to find the method you want or make your code more readable. My approach does not generate new methods, it does not touch existing objects , nor make the system more complicated. I see it more like a database to help you find things. 

But thanks for the link anyway , now I know how to make extension classes.  


On Mon, Dec 2, 2013 at 3:34 PM, <[hidden email]> wrote:
kilon alios wrote:

Lets say you dont like the names used for some classes and methods. Why go through the tedious process of subclassing and creating your own methods that call superclass methods just so you have better names for those methods. Just go in and add new names for those methods, while they keep their old ones. Name clashing ? no problemo, use tags as identifiers that will help you separate methods with same names.
Sounds a bit (but not quite) like package "extensions" per the top half of [1].
[1] http://seandenigris.com/blog/?p=1015

cheers -ben