[Pharo-dev] Nautilus Tree
kilon.alios at gmail.com
Fri Nov 29 12:16:37 EST 2013
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
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
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".
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
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.
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.
On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <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
> View this message in context:
> Sent from the Pharo Smalltalk Developers mailing list archive at
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev