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