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@clipperadams.com <mailto:sean@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