Le 6/2/15 16:31, Sven Van Caekenberghe a écrit :
Yes, but that is not really provided as a #catalog* method, is it ?

There is #catalogDescription, but that is some lines of text.

There should be something like #catalogLabel for a sjort one-line title style 
label.

if configuration would be filled up we could take advantage of them.
The flybyhelp when hovering over a package is displaying the description of project (when there is one) since two years.

Stef


On 06 Feb 2015, at 16:26, Esteban Lorenzano <esteba...@gmail.com> wrote:

there should be both: a name and a category

Seaside - Web framework
Zinc - HTTP server
etc.

Esteban

On 06 Feb 2015, at 16:16, Marcus Denker <marcus.den...@inria.fr> wrote:

Yes, we need to improve that. Names are nice, but they make it harder to 
explore the system.

On 06 Feb 2015, at 12:43, Sean P. DeNigris <s...@clipperadams.com> wrote:

Markus Fritsche-4 wrote
+1 to that one.
Yes, I also find it difficult - much more so when I was new to the
community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be
catchy, but when I'm browsing the system, I just want to see where the darn
WebClient is, not mine for minerals or go to the beach!! ;) j/k. But
seriously, it's one thing to have "sexy" names at the top level - Pharo,
Squeak, Ruby, Python; but inside the system, it definitely creates
confusion. It's perhaps extra difficult for us because some of these
projects have both an outside and inside identity. It's an interesting open
problem... maybe some metadata at the MetaC/package level could help? Like
some standard tags like #WebClient, #Compiler, etc to say logically what
role a project fills...



-----
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.







Reply via email to