> Just out of curiosity is there anything wrong with just extending  
> PI so it holds the information you are interested in? It seems to  
> me that its name implies that it would be the right place to store  
> meta data like you mention. It then seems that the relation between  
> package and pi might be something where package holds onto the  
> actual entities but pi can be used to "reconstruct" the package in  
> full. In this way you'd have the best of both worlds.

Do we have classInfo, personInfo, MorphInfo no we have Class, Person,  
Morph
I think that PackageInfo.
So we are extending PackageInfo but renaming it too :)

>>     - having a better browser for Package may be with tabs as in  
>> VW  so that in one click
>>     we can see the views you mentioned (all the extension of a   
>> package, all the package a class belong to)
>>
>
> From what I've seen of the VW browser (which is not recent - I  
> think the last time I looked at it was at ESUG last year)

No this was not the same. I think that what you saw was the classbox  
browser that alex just did to show that we could browse classboxes.  
But as classboxes have only been a research experience the UI was not  
our main goal (now a student is rewriting completely a new browser  
for classboxes with OB to see what we can do). Alex started from  
scratch the new browser a couple of month ago to code something else  
than LaTeX :).

> I wasn't too impressed. It felt overloaded and way to crowded with  
> features. If one would really want all of these features in a  
> single place an approach like StarBrowser would seem more  
> appropriate to me.

:)
We got a lot of fun building the core with roel. I always think that  
smart groups would fit perfectly into whisker too. But here I would  
have a problem to see how smart groups can be a package: may be they  
can co-exist as in Tamaris.

> But -quite practically speaking- I actually quite like the  
> distribution of labour that MC achieves today. Most of the time you  
> spend hacking in a browser and occasionally you commit something to  
> a repository. Since I always check the changes before I commit it  
> is actually useful to switch over to the MC browser, review my  
> changes, and commit them. Personally, I feel little need for having  
> the package management directly integrated into a browser although  
> I will agree that a little restructuring of the tools could help  
> (but so could other things such as being automatically notified  
> when a change to a certain repository occurs).

You are not forced to use it. May be other people want something  
different?
When I program in VW. I click on the package and run the tests and  
when this is green I click on the package and press submit and I do  
not want to see the rest. In VW I guess that 90% of the people  
proceed that way. At least here we all do that.

> I must also say that while the emphasis on the package items is  
> understandable in the new browser there is a danger that it will  
> getting into one's way very quickly. For example, how often do you  
> move a method from one package to another (this is the first item  
> in the message list menu)? Rarely, if ever.

Because you do not try to extract package from the image.
Also recently I have been repackaging my small application and  
renaming all the categories and checking that everything was indeed  
correct was terrible.

> It is dangerous to overload the more common actions with lots of  
> esoteric things that are rarely used.

True see the old browser as an example. Most of the time we use 10%  
of the menu in all the user interfaces. Still when we want something  
in a special case it should be there.

> By the end of the day we must understand that the primary purpose  
> of a system browser is programming, not package management. The  
> system browser can support package management and to the extend it  
> does this is a useful side-effect (after all, the choice for going  
> with category prefixes originates directly from the desire to have  
> the system browser help us with package management) but it's a side  
> effect nonetheless.

Sure why categories are not packages? They could. This is not that  
simple but right now categories are nearly useless.

The browser of alex is trying to let you choose (not all the  
categories are packages, package can contain categories even if I do  
not like that but after discussing with heavy MC users I think that  
this is a good choice). Still for a simple user creating a package or  
a category should be transparent. Only when  you start structuring  
your application you want to see the difference. I should program  
more with it to get the feeling because this may be confusing.

> So what I'm trying to say here is you walking a very fine line here  
> and you need to be careful not to make that new browser so package- 
> centric that it is no longer as useful as other browsers for  
> general-purpose programming.

Sure.

> This should be an interesting exercise and probably needs lots of  
> feedback from real users (both novice and expert).

Yes for the moment I think that our target is mc users.

Stef

>
> Cheers,
>   - Andreas
>
>