Links are generated :)

Here is the link I guess: 
http://rmod.lille.inria.fr/web/pier/software/Tools-Improvement/NautilusDocumentation

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 
> 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 <[email protected]
> <mailto:[email protected]>> 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 via email to