Le 02/12/2013 10:05, kilon alios a écrit :
"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.
Yes, that can be interesting. A good tagging / oragnization creation GUI
can be nice.
"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 ?
No. What I have is in fact a category hierachy + a name matching scheme.
* The category hierarchy starts with top level items (Core, GUI, System,
Packages, Networking, Development), with sub categories (such as Spec in
GUI). I could have as many level of subcategories as I want.
* Then I have a name matching scheme: a package starting with Spec will
be put under GUI/Spec... If there is a common core, I improve on that
and add subcategories under Spec to do Spec-Gui (for the packages
Spec-Gui-Morphic, Spec-GUI-Amber, Spec-GUI-MVC, Spec_GUI-Gtk), and so on.
The tree does automatic prefix reduction: if parent item is XXX and
current item is XXXYYY then current item display is YYY.
It also has an ability to clean up the system: load
ConfigurationOfSomething in, it will be moved under
Packages/Configuration/. You can load hundreds of configurations and
they will all be stored there and you won't be annoyed by the length of
the packages list (unless you open the Monticello Browser, of course :P).
All this is to target the 7 +/-2 magic number HCI strives for. And the
fact that we usually have a fairly good memory to find back things (they
are allways in the same position).
" 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.
Yes, that's why I suggest experiments... There is a lot of tuning necessary.
For example, I played a lot with automatic scoping in browsing and
search... And backed off a bit because it made a mess of my search and
understand workflow. I used to do like that:
- looked at a method in a class
- select implementors on a selector in the method source
- get a browser scoped with only the implementors of that selector
- look for an implementor in that browser...
- :( empty browser because I was looking inside the previous scope
So, now, if I ask for implementors in a selector scope, I back off one
level in scoping: if the parent scope was a package, I'll search in the
package scope.
"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 .
No, no, really. The underlying system is a bit hard to get into and
isn't too well described, but it has everything you need to build one.
Even mine... The specifics are the tree handling, but, honestly, you
could use any other way to classify the code and replace that part of
the GUI, reusing all the command and tracking system events logic. I
reused code from the other browsers as well; I have a lot of respect for
the architecture of the OmniBrowser, and for the features of Nautilus.
Thierry
On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <thierry.goub...@cea.fr
<mailto:thierry.goub...@cea.fr>> 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
<s...@clipperadams.com <mailto:s...@clipperadams.com>
<mailto: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://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>
):
<http://forum.world.st/file/__n4726287/Picture_1.png
<http://forum.world.st/file/n4726287/Picture_1.png>>
-----
Cheers,
Sean
--
View this message in context:
http://forum.world.st/__Nautilus-Tree-__tp4723819p4726287.html
<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
<tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
--
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
