[Pharo-dev] Nautilus Tree

kilon alios kilon.alios at gmail.com
Mon Dec 2 04:26:42 EST 2013


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 <kilon.alios at gmail.com> 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 <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/3271f5c8/attachment-0002.html>


More information about the Pharo-dev mailing list