Default code browser

George Herolyants-3 wrote

Though I think WhiskerBrowser still covers the above use case better.
Unfortunately it doesn't run on Pharo.

Maybe WhiskerBrowser can be created using Glamour?

Talking about browsers, I use to use more than one as Laurent.

And have a question, OB don't have a "recent (r)" menu as Classic
Browser that permit to have at hand the last used classes? This is
very useful to me.

Cheers.
Germán.




2009/12/18 laurent laffont <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/18 GeertClaes <[hidden email]>:
> George Herolyants-3 wrote:
>>
>> Though I think WhiskerBrowser still covers the above use case better.
>> Unfortunately it doesn't run on Pharo.
>>
>
> Maybe WhiskerBrowser can be created using Glamour?

I don't now. IIRC someone on the list mentioned that Glamour can't be
used to build real browsers for now, but I may be wrong.
I wonder, if it can be done using OB? It would be cool if it was possible.
Recently I loaded it into Pharo but it relies on some missing classes
and expects some old behaviour from underlying libraries. It worked
somehow but it has some visual artefacts (for example boxes for tree
menu items are smaller than the text they contain; see in the
attachment). And of course in lacks all the cool stuff OB has.

Cheers,
George

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

You didn't ask, but here's how I see it on pakages :)  PackageInfo **ABUSES** method categories to associate methods with packages.  Methods should be able to belong to multiple categories (you won't miss it until you can do it), and to one package.  Dolphin also has a class category option, but I am not aware that anyone ever found it useful - packages are enough to categorize classes.

I don't know a nice way to say it: if you are confused about packages, ditch the package browser for a while.  I have not used it for a few versions, but I was shocked at how slow it could be, and began to suspect that its behavior was (queue throat-clearing.wav) not deterministic. Another possibility (if this level of re-entrancy is possible??) is that it is SO slow that one fails to appreciate that it is still crunching on the organization??

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of GeertClaes
Sent: Friday, December 18, 2009 3:48 AM
To: [hidden email]
Subject: Re: [Pharo-project] Default code browser



Schwab,Wilhelm K wrote:
>
> Re the various browsers, they are not terribly well identified, so it
> takes work to figure out what I am using.
>

+1 here

Other than that, I find that none of the browsers are at this stage great yet from an intuitive, usability point of view (mind you, I consider myself to be very 'newbie').  I am also looking at Pharo + Seaside or AIDAWeb mainly as an IDE tool to create web apps as I am not that interested (or skilled for that matter) in tinkering with the core.

I am hoping that the new package management system (MetaCello in Pharo 1.1?) will streamline some of the confusion and allow the user to have the option to somehow hide "system" or Pharo-Core packages from the IDE.  I could be wrong here, but methods of a class can be nicely organized using protocols ... and then there is this whole vague, confusing world of how classes are managed in categories and packages ... but the term package could actually also refer to a category, which is actually a package, but a package can also be a Monticello package, which could be different than the category or should I say package?  All this may make perfect sense to the gurus but it is extremely confusing, because packages also need to be able to be grouped into projects (is this the term?) and have dependencies on other packages and/or projects?  I haven't even mentioned the confusion of SqueakMap/PharoMap, SqueakSouce/PharoSource, Monticello and Universes.
--
View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4185502.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K wrote

You didn't ask, but here's how I see it on pakages :)  PackageInfo **ABUSES** method categories to associate methods with packages.  Methods should be able to belong to multiple categories (you won't miss it until you can do it), and to one package.  Dolphin also has a class category option, but I am not aware that anyone ever found it useful - packages are enough to categorize classes.

I think I am with you that class categories are probably a bit overkill here since these class types are already grouped in separate (monticello) packages .

Schwab,Wilhelm K wrote

I don't know a nice way to say it: if you are confused about packages, ditch the package browser for a while.  I have not used it for a few versions, but I was shocked at how slow it could be, and began to suspect that its behavior was (queue throat-clearing.wav) not deterministic. Another possibility (if this level of re-entrancy is possible??) is that it is SO slow that one fails to appreciate that it is still crunching on the organization??

It's not just that I am a bit confused or think the package browser is too slow, from a usability point of view it just does not make sense to me that it seems so complicated to load/share packages from other projects and/or components.

Maybe this discussion belongs more in the 'Pharo IDE usability (was Re: Pharo for Professional Development) ' thread now?

When I said the package browser+MC was not deterministic, I meant it.   My experience was that _sometimes_ packages would be created from categories, and sometimes not.  Things get more clear if you fire up the MC GUI and explicitly create a package.  Then it suffices (with the other browsers at least) to put a class in the corresponding category, and to categorize methods with *packageName (yuk!!!!, but it works).

There are MC tutorials, and you should read one if you have not already done so.  My biggest gripe is that I find myself being forced (AFAIK) to type category names far more often than should be the case.  There is what appears to be "recent categories" list but it is both hard to read and (I suspect[*]) not predictable.  May the overseers be with you if you ever type something with a bad mix of capitalization - deleting the offending package never seems to rid the image of it.  As Murphey would have it, type something wrong and the tools never forget; type something correct and you will end up typing it again, at least until you no longer need it :(  That is based on fixing a many badly-formatted category names created by SIF.  FWIW, I have learned how to use the regex package to make changes to a .sif file before loading it into Pharo, which is a nice way to go.

For now, I get along fairly well and am looking forward to a new package system.  What I find beyond comprehension is that the rough spots have not been fixed.  In my relatively short time making real use of Pharo, I have found it essential to "clone" tools that I use in Dolphin to manage packages.  The core of it is no longer an absolute must in Dolphin, mostly because its package system has improved over the years.  However, I have something that attempts to identify "your" work that is not assigned to one of a collection of packages identified to it, provides one-shot saving of those packages, and can "easily" be loaded into a new image and load the packages into it.  It is rough around the edges, but I plan to make it available to anyone who wants it after it settled down a little more.

One thing I would like to be able to do is to create separate .mcz files for Migrate-core and Mirgrate-uf, with assurance that **nothing** from Migrate-uf will end up in Migrate-core.mcz.  So far, that is not happening, perhaps my fault.

Since I have been spouting complaints all day, I should mention that I have noted that a Pharo image has been serving a Seaside app off of a vmware based win2k3 machine, and has done so with higher reliability than vmware itself, or so it seems.  I have frequent problems with network routing, but it appears to happen only when pings fail to the offending host, and magically gets fixed when the pings begin to succeed again.  Any déjà vu??  I'd like to hear about how you fixed it.  Reports on the net suggest that it could be a known and long-standing defect.  I have also had DNS related hassles, but is really no surprise.  Years ago, I learned the hard way to disable XP's DNS cache service; it is said to be essential to win2k3, and I hesitate to learn the hard way on a vm.  In short, Pharo sucks a LOT less than Windows :)

Bill


[*] Not meaning to spread FUD, just being honest about my observations.




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of GeertClaes
Sent: Friday, December 18, 2009 12:31 PM
To: [hidden email]
Subject: Re: [Pharo-project] Default code browser



Schwab,Wilhelm K wrote:
>
> You didn't ask, but here's how I see it on pakages :)  PackageInfo
> **ABUSES** method categories to associate methods with packages.  
> Methods should be able to belong to multiple categories (you won't
> miss it until you can do it), and to one package.  Dolphin also has a
> class category option, but I am not aware that anyone ever found it
> useful - packages are enough to categorize classes.
>

I think I am with you that class categories are probably a bit overkill here since these class types are already grouped in separate (monticello) packages .


Schwab,Wilhelm K wrote:
>
> I don't know a nice way to say it: if you are confused about packages,
> ditch the package browser for a while.  I have not used it for a few
> versions, but I was shocked at how slow it could be, and began to
> suspect that its behavior was (queue throat-clearing.wav) not deterministic.
> Another possibility (if this level of re-entrancy is possible??) is
> that it is SO slow that one fails to appreciate that it is still
> crunching on the organization??
>

It's not just that I am a bit confused or think the package browser is too slow, from a usability point of view it just does not make sense to me that it seems so complicated to load/share packages from other projects and/or components.

Maybe this discussion belongs more in the 'Pharo IDE usability (was Re:
Pharo for Professional Development) ' thread now?
--
View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4187788.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On of the idea is to use glamour to experiment new browsers and probably to
write it from scratch when we know what is really good.

Ideally
        I like the multiple method showing of whisker but not the rest
                david implemented that in OB.
        I like the fact that O2 supports the view of class extension view per packages
        Now I avoid to talk about browsers because we do not have somebody in the community
        working heavily on that beside david and david may leave once he will finish his PhD.

Now OB metamodel does not support tree and make it difficult to have something like the class comment
visible close to the class definition.

On Dec 18, 2009, at 3:47 PM, GeertClaes wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes
        gather together
        publish it on squeaksource and
        fix it.

Stef

On Dec 18, 2009, at 10:20 PM, laurent laffont wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse wrote

On of the idea is to use glamour to experiment new browsers and probably to
write it from scratch when we know what is really good.

What I have seen so far I have to say I really like Glamour!  I like a lot of Pharo stuff and can't wait to see the next package management system in 1.1.  Go Pharo :)

I tried whisker on Squeak years ago and hated it.  A clean CHB that offers easy ways to spawn new browsers, can be filtered to subsets of the class hierarchy, and has a history for easy forward-back/recent navigation is the way to go IMHO.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Saturday, December 19, 2009 3:44 AM
To: [hidden email]
Subject: Re: [Pharo-project] Default code browser

On of the idea is to use glamour to experiment new browsers and probably to write it from scratch when we know what is really good.

Ideally
        I like the multiple method showing of whisker but not the rest
                david implemented that in OB.
        I like the fact that O2 supports the view of class extension view per packages
        Now I avoid to talk about browsers because we do not have somebody in the community
        working heavily on that beside david and david may leave once he will finish his PhD.

Now OB metamodel does not support tree and make it difficult to have something like the class comment visible close to the class definition.

On Dec 18, 2009, at 3:47 PM, GeertClaes wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project