> what you are browsing influence the browser. Ben!! We should definitely sync on that!
On Dec 2, 2013, at 11:27 AM, Benjamin <[email protected]> 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 <[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 >> >> >
