[Pharo-dev] Nautilus Tree

kilon alios kilon.alios at gmail.com
Mon Dec 2 04:05:56 EST 2013


"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 <thierry.goubier at cea.fr>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 <sean at clipperadams.com
>> <mailto:sean at clipperadams.com>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131202/ffe85557/attachment-0002.html>


More information about the Pharo-dev mailing list