Offline bug reports

While the news server has been down, I have received quite a few bug reports
off line (particularly from Ian Bartholomew, thanks Ian).

I'm not intending to post those here, as I would rather spend the time
fixing them. However they are in the bugs system, and will appear in the
bugs lists when refreshed.

As a reminder a snapshot of the reports can be found at:

Preliminary Release Notes for 5.0:
http://www.object-arts.com/Beta5/D5%20Bug%20fixes%20and%20Enhancements.htm
Outstanding issues for 5.0:
http://www.object-arts.com/Beta5/D5%20Defects%20Outstanding%20(List).htm
Issues reported for 5.0 betas:
http://www.object-arts.com/Beta5/Defects%20reported%20in%20D5%20betas%20(Lis
t).htm

Regards

Blair

As a courtesy to all of you, here's a message and reply that I had with Blair
while the server was down. For readability purposes, I've started my replies to
his replies with "Note:".

.joseph

>
> I've been working heavily with the DS 5 beta over the last few days, and
> have noticed a number of problems:
>
> - I filed in some code which implemented #ifNil:. After removing my
> package, a lot of things crashed. I presume that Dolphin silently moved
the
> definitions into my package. Of course, I may be wrong about this one,
> since I've been shoveling a *lot* of code over.


Uninstalling a package which replaced system methods will also uninstall
those methods (though you should have been warned when installing the
package that it contained clashing items?). We've been meaning to do
something about this for ages - Andy and I discussed how to save/restore
replaced methods at CS1 in San Diego, though he didn't believe my algorithm
for restoring the supplanted methods would work :-).  This still hasn't been
risen to the top of the priority list unfortunately, and because David
Gorisek's excellent Envy-like STS package is available, we've not done much
work on improving source code management and packaging. David has an update
in the beta 5.0 newsgroup.

Note: There was no warning. I have a solution for the save/restore problem, and
would be happy to discuss it with you online or offline. - Joseph


> - Which brings me to my biggest complaint. Is there no way to file code in
> directly into a package? It's a pain to have to go and catch every single
> loose method individually and move it to the correct package.


No. As we don't often file in chunk-format .st files from other
environments, this isn't a big issue for us, but I can imagine that if you
did it would be useful. Don't any of the SIF format writers/readers provide
a way to do this?

Note: there is no support AFAIK. Since I'm currently contemplating moving some
*big* projects over to Dolphin, though, this is an issue. One of the first
things I'm moving over is Ginsu, which should take away a good bit of the pain.
- Joseph

> - In the Package Browser, Prereq pane, I tried to move a method to a new
> package. I got a walkback. In PackagePrerequisites>>#choosePackage,
<model>
> is nil, and it was dNU'ing on #packageManager.


Thanks I've recorded that as issue 568.


>
> Other things:
> - You're not up to date with SUnit. I'll get you the 3.1 code over the
weekend.


OK, thanks. We've been using the version we got from Jeffrey Odell with his
browser, at least I think we have.

Note: I enjoy using Jeff's browser, but it requires a slightly different
implementation of TestResource. Since it's rolled into the base product, I have
no problem with having that implementation in there. The 3.1 update deals with a
few other problems. - Joseph

> - Do you offer hooks to add items to browser menus?. If not, what is
> standard procedure for doing so? I want to add an item to the package list
> pane in the Package Browser to let me file out a package in SmallScript
format.


There are a number of ways you can do this, but the easiest is to edit the
view (locate it in the resource browser, or in the resources pane of the
package browser, or by using the CHB Views/Edit command). You can edit the
menu bar with the WIYSIWYG menu editor (Modify/Set Menu Bar), and the
context menu in much the same way. If the package list is a reference view,
you can either dereference it, or Edit the reference to copy its menu, and
paste that back in to the reference view before editing it in the normal
way. I'd recommend saving the new PB view under a new name (File/Save As in
the View Composer), and then using Tools/Options/Inspect on the PB menu to
open an inspector on the PB's options, in which you can choose to your new
view in place of the original one as the default. If you want to subclass
the PB and use your subclass by default, you can change the default package
browser class too, as it is an option under 'System Folder', accessible
using Tools/Options/Inspect from the main launcher window.

Note: speaking from my long history of trying to keep whole groups of budding
junior toolsmiths in line, I dare say that your solutions won't scale. That was
the motivation behind my implementing the VendorExtensions for ENVY. I know
easier ways to do it, though, and will post suggestions as soon as I can test
them. - Joseph

BTW: If you do attempt this, there is a nascent "AMLSourceFiler" in the
"SourceFiler" hierarchy intended to file out in Smallscript format. Any
enhancements/bug fixes, or suggested refactorings of the SourceFiler
hierarchy, would be most welcome. I know there are some bugs in the AML
filer (some of the output format is not quite right), but it is basically
there. I haven't tried filing out an entire package with it, or thought
about the best way to do that.

Note: I'll take a look at that right away. I've been working with Dave quite
intensively on this.  - Joseph

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

Joseph Pelrine wrote:

> > - Which brings me to my biggest complaint. Is there no way to file code
in
> > directly into a package? It's a pain to have to go and catch every
single
> > loose method individually and move it to the correct package.

I raised this on the main ng some time back (see the archive).  There's no
pre-packaged solution so I came up with something.  It's a bit dicey, but
we're all adults here and it may be useful to others so (with apologies for
wandering off "charter") I've attached it to this message.

Please note that my testing under D5 is limited to installing the package
and observing that there don't seem to be any name clashes...

    -- chris


begin 666 FID.zip
M4$L#!!0````(`$IIT"HA6)67M0H``-\D```5````0U4@4&%C:V%G92!&:6QE
M:6XN<&%CS5IK;]NZ&?Z<`OT/=/K!=N$$;M?UM-[.L,1.#X*M%S1)]Z%H`5JB
M;9[(HB;*<;UU/VC_<L_[DI0EV4Y\FFXK6K2V2#Y\[S?YJ\AD="VG2GQ]^"!\
M'/PLWOF/J9RK@6@/K\HGKW2B=-H^7F_/Y)</*K?:I /1_\/#!P=C:74T-/.Y
M2@LZ;+)5KJ>S0OQ;#&>YMN(JRV32$T]>OGS9$T_[_3[0(EHY7M#*G^>JD-/4
MV$)'QR:?/GSP\,&%<E>?I^]5K',5%28742*M%9&[24SP9&YR)70Z,<=$X9I&
M)LFS4!+;[A_W^Z(SQFU=M_WP)(Y%,2.>W#D;Y3HK[&%MT5U+HK$]D1ACE0#%
M,Q.'9]/$C&42ON7*FD4>.6$25 !GG#?T$$*3<3P0CYHLDCA7.&U5,JDQY"ZL
M'PXJ.OJ3>#1AH &=W[%8U)8OYC))"IE<7ZQLH>;E-D?0I?''=]+C6 [T;-T2
MY+!UT^&I3F6^$K\XT?&>BJC&O.H6>6T@.A>J$*E:5I"Z@#I\'\3=Q "#8>UV
MB*H=Y"I7?U]HJXM-_5E5O*NL$^!Y#$O4Q6H-S.)MC]2-2DS&=NHDW"YEWQZ9
M))O!IZK"=73XFUI,TY#-;J0F.M4%#-@>\O.WXU]A*L(NQFQ/6XP(L#JUA4PC
M]4'F6HZ3(("VOZ"-+7RZN4X+F3')2$=T)5;+Q[S_? =N&Z0=_I5=XS5;JB>V
M%<S0V:]]97)^[LU52**=0'#!X4F>RQ1["R-H7:?K9;&<Z<060A8095;H=$J[
M5&H7\/]B)@O6GF'1D*W%)#45B_&*%SS<4B>)&,,RXAAK`* UR$SI&Y4?L],_
M&E[Q*JOCH+,1@A!T!C $*(Q!:SP<KUDC9Q/RHLA!Z0[6W.(/RUB5`YQI"3!7
M:C.2A9H:,@XH%!;H1=%Z?(3,P=>TAE='P6\<D:UL,4YTU/+>BH= W@.6"/E&
M8$ WX]P6.VR$/%+7N]Q &9QA)-\B.I%)"PE/A(*BV2*]METATQC+GI@>?X7<
MTZ"4H!^O8G+_?91,GW,%_095;U6NO]7I]N!KF<#H0HI;E-_K*J]D^^',Z$@Y
M)A6%BX.(GU!$*QU6IO@O#\!62'MA\D+%0Y,DH),SZL=!]D0,LJ<"!#SA>"G^
M^+/ =_KXJ2L86H)C3K\CA0R?2OI6TG_,B;LD3MLW.A%Z<IDO4(=\_,P6^<DQ
M4+(&#DAG;S.5CK1,S-2'WO55G39M0&& OQ!86_1*`3%"#X_HZBZ%8 :^7&7,
M/CGJ"B(O9LX;A T&1(B6ME57.2@V5^B[)PQGRU5W&;0J%TEQ]J6 _IU<.!$<
MV)E9OC:Q3$@>):^W"62'$WM.UP$J@!T[;VNZQ#:O:_A$U?^H_(*IV]V.Z%SO
M\ S^8":EX-F<.9&YU$!_-BN\LHH\(=VY9$,HQ0QUI"O$Z$.N0'3L'338$F='
MVA^6=>&<)X1<[\KP+1)'5_!I%^)Z=P=BF:X<!7 &G'05D*5ST4Q([/(.ZR(!
M[?;!9G,+G<]5N7^KAQ<RGZ*JJ#)W:43L%I<S`TX@%) )$U>YA$>BY%CU1)&O
M!FP>&WI>Y#G7S9OZ=>C G:MH)E-MYR2[!7$*:4\D+ O!0F0JGU#M<70$N<WU
MEX)D0\K)9981*:AZ4D0PWKSK>A).J,M>^R#CUYSD?EU #2BSKPF1-$PD402"
M8$I0HF&\*(A,4(B2'C(@-:4B-2R68R$N-!F#VX&G$!1%UK1(5H$3?,I5PI5,
M3YRWVS<*M\=39SI63@BS8030%,D:Y9@@]<#)L9WE=WHF_G;R_LW9:,"V1 ?*
M! T*\&^6FRFJ8O0(CX'S6'1RU0T6X6VE%TRL)U01[6490ER2<W@F4Y.3C%;D
M%[D!8_.>$Q3Y4$E/)%FY4BPARS& 8#>4NG 5EL#>`HMC@W-+XAI5*EG>6$$=
MBK]%"=5ZA!BK\0(R@"M-D1];+2H%MWCV=*%1^W9^N3H?L7TXMX.C__/%\*?G
MSY[W^T<OGO=/CYX\&?WNZ,5/3W]_-'SV\MFK9\.STU'_Z;_:79?/-R-&-7IQ
MR=RZ2EF&>J(1KCCD;9QJE &QBE TJ#,V7RH`I*_72**0.L2"3PS(-D[2M(9
M2@?DW#85,W@"[ 487EF1B;D=52Y3[_**7,W-C2?@$MTS!*IBCL>^9=I=-@=:
M_W=E,WRW882..4Z)&S2*&RT'XJ+F\#X+5BKFS1.R=N0'Y!0:8GO"92.#Y%PG
M>%,0GVYI$+:P]E]M$.Y6897"_52X>6(O%?[_^-Q'@56FO (3;0LWFN!8D>7Z
M!D&(LV)JEQ0)!<T#D!AY@D ?*&T0F:%H"-3[-L%R, "8JQ00:BGPY,HG()\2
M0JT?0%#BXWOXAJK83R&H@*QDRFNULB=I_$$F"V69SP$>B<$-YBY?18?^T_8O
M.HW?3@:"(V@7\>T5,*GB#/ \NL"Y3U1\'GP.1'B)&$3RBC571$)5,+$(05B>
MRKA=CI<W'%01PJDEL'J:RF3== 9DS&8X4P1#B<"8`C&2,KW*;[UU@ESMK&>I
M*+M[NR@MB74C4&FX61Z;D[^G5ZI#%VPM5'?RU?6;[[0R%DZG[=C@7B1P@C:$
M.A$J>ZJ _'A+V])U(C$I*PEX+ 7^TK1#7RK/)-5&R%>U^J&1D@*10<YM/MM>
MR]D-HKB#P/9F@PAHWE!N+&!BU:K5YRZ3.I_A@1;C7JSF8Y-LD%Z9IGI]\+YO
M9,:A5;CQ:&AGPVQC&TOKT6/E3)TSSY6;=Y7:0$^-L!&[IQN\^;GQ':S4VH,=
M?#FDJI9J-XM8VRR1JUN9=%LWSV[E,]3L@5-\/]]DL!Q^[\$BGM_*8L"J,,F7
M[L5;(-=-:%&YH93RQYL&R@SZ!]A4F0-56,/PE]W<+'D&5'/SRF@EG':NVD@P
MLG^:F.B:D!7"[H*@_;/]VL]U^MLA59\-/3I%U6T9D:K39@]QPJF+IT^D1&1V
MUW97P4("\GV G%#3Y;+0(4^M7!/BVD!NW;POKWO_'NIFQ&)A,ZJL9ZB 0?(X
M7T 2V!]Y@?H+($]G%.N$2]IV<QF#48,N7,7L4E(0I9,:FN"#@X^\MU;>T]X#
M1_H._(..6T:'R71TD9 I:RJ)9/#5'=F(9K2(W,AJK]'6J'JJK<226J[OVD<0
M]82*,0Y'<>^L5J7TTJ>>.<@-B!>>/AWZ4TYA)5?EP0:WY5E04][H0E+SREI\
M#.?<`.L"-0%LHC$%*&/(NFP,-X25YAV-V%3CK''T*HMI-G3WX7+H?7O+"8B:
M>;6<\6,2$?,<VH>0/:'"('WWK'Q?"*J_[PW#L_?O`7)?:BH>VIJI!.,;^QLE
M2U78MQ_U.<GGH6_$J;G?_>RDZ9#W1:LZZ7VQZOYT/[20E5N</F2B__';,>I)
MN&6@.<YF4-]Z7GTW3"VHW\;55C"NC)LOGPBW6FZ4[2.:N/7TVS4A$4:;OCB@
M-%)F%#^4Q'$ZQ#^)B%UVV9PHAAB(CY4!-N;2.$WC)^I'"=N3Y#+-9]&Q"\B,
MB.I20-VHE#C,EF_W`VM^L2RAUZ..'X/+ZL\^FKU?X-Q-0TA-N]Z+U=GS'9I[
M'76($2M"()UVKV;J$B'.E:S6OG@#M$AB],3G\PQS6QB8?V.SZX<PS6B+?^$H
M7J#\$@1F?H>5[T*J$?M]4"$6O$AR7+J!?.#S=OR'#_ BL?Z#$?_S@O+''_[[
M?P!02P$"% `4````" !*:= J(5B5E[4*``#?) ``%0```````````" `````
M````0U4@4&%C:V%G92!&:6QE:6XN<&%C4$L%!@`````!``$`0P```.@*````
!````
`
end

Joseph

You wrote in message news:[hidden email]...
I think I may have misread your original message - reading it more carefully
I see you say that you "filed in" some code, which would definitely not give
a warning - the new definitions would just be taken as updates to the
existing methods. Having said that a file-in would not adjust the packaging
of the methods. Loading a package with clashing methods should, give you a
warning, however, and if it didn't, then that is something we need to look
into.

>...I have a solution for the save/restore problem, and
> would be happy to discuss it with you online or offline. - Joseph

I'd like to discuss that, but offline I think.

> > - Which brings me to my biggest complaint. Is there no way to file code
in
> > directly into a package? It's a pain to have to go and catch every
single
> > loose method individually and move it to the correct package.
>
>
> No. As we don't often file in chunk-format .st files from other
> environments, this isn't a big issue for us, but I can imagine that if you
> did it would be useful. Don't any of the SIF format writers/readers
provide
> a way to do this?
>
> Note: there is no support AFAIK. Since I'm currently contemplating moving
some
> *big* projects over to Dolphin, though, this is an issue. One of the first
> things I'm moving over is Ginsu, which should take away a good bit of the
pain.

Eric's SIF, and perhaps some of the others, definitely supports packages as
an annotation, and so it doesn't lose Dolphin packages when round tripping.
The problem of course is that you are bringing over the code from a system
with either no (Squeak?) or a different notion of packages. If the "source"
system has a package notion, then it should be possible to adapt the Dolphin
SIF reader to recognise the annotations and use them for packaging.

The problem with trying to do it from a file-in, of course, is that it is
not a declarative format. I suspect I'm teaching granny how to suck eggs
here, but this means that one doesn't know in advance what will be in the
file, and this makes it difficult to do useful things like spotting clashes,
pushing it all into one package, etc, without pre-parsing the whole thing. I
reckon it would be possible to "bodge" the SourceFiler and ChunkReader
mechanism to allocate loose methods to a package (simply by adding a package
inst. var. to ChunkSourceFiler, and then setting this into the ChunkReader,
and modifying the various chunking blocks - other solutions may occur to
you). Dealing with classes and globals is, ironically, somewhat harder to do
robustly, since these are just "evaluations". One idea for allocating these
into the package is to difference the uncommitted globals and classes before
and after the file-in, and then allocate the new uncommitted globals/classes
into the package (much the same way one might do it manually in fact).

Another approach, which is slightly cleaner (although nastily modal) would
be to use the events that are triggered off the system dictionary when new
classes and methods are added (there is no such event for global variables,
an omission). Since the package manager already observes these, it would be
quite easy to put it into a mode (aargh) such that it placed all newly
defined classes and methods into a default package. Perhaps better would be
to define a simple new class like the attached, driven as follows:

    ChunkFilePackager fileIn: <.st file name> into: <string package name>

I'd not really be happy about offering these sort of bodges an industrial
strength facility, but it might be useful nevertheless. If you have any
better ideas we'd be pleased to hear them.

>...
> > Other things:
> > - You're not up to date with SUnit. I'll get you the 3.1 code over the
> weekend.
>
>
> OK, thanks. We've been using the version we got from Jeffrey Odell with
his
> browser, at least I think we have.
>
> Note: I enjoy using Jeff's browser, but it requires a slightly different
> implementation of TestResource. Since it's rolled into the base product, I
have
> no problem with having that implementation in there. The 3.1 update deals
with a
> few other problems. - Joseph

Er, so does that mean it would be best to update SUnit, or that it would be
wise to remain on the version we have at the moment?

>
> > - Do you offer hooks to add items to browser menus?. If not, what is
> > standard procedure for doing so? I want to add an item to the package
list
> > pane in the Package Browser to let me file out a package in SmallScript
> format.
>
>
>> There are a number of ways you can do this, but the easiest is to edit
the
>> view ...[Blair's reply snipped]
>
> Note: speaking from my long history of trying to keep whole groups of
budding
> junior toolsmiths in line, I dare say that your solutions won't scale.
That was
> the motivation behind my implementing the VendorExtensions for ENVY. I
know
> easier ways to do it, though, and will post suggestions as soon as I can
test
> them. - Joseph
>

OK, looking forward to hearing them

Regards

Blair

Blair McGlashan wrote:

Thinking about it now, I do agree. Filing-in is a brute-force method of
installing code. Nevertheless, ENVY catches all changes to existing code, using
a method described further in this post.

> >...I have a solution for the save/restore problem, and
> > would be happy to discuss it with you online or offline. - Joseph
>
> I'd like to discuss that, but offline I think.

I'll get in touch.

> > > - Which brings me to my biggest complaint. Is there no way to file code
> in
> > > directly into a package? It's a pain to have to go and catch every
> single
> > > loose method individually and move it to the correct package.
> > [more snipped]
> >

I'll be looking into the SIF reader in the context of the Ginsu port - which BTW
is pretty much up and running.

No. Definitely not ;-)

I think that The Simplest Thing etc. would be to fully implement the concept of
default package. You have (I think) all the hooks needed there already. The
default package would be similar to a Change Set, or ENVY (Sub)App. When you
create a package, it automatically becomes the default. From the PackageBrowser,
you can also choose the default. All added definitions automatically go into
this package. When you change an existing definition (which, of course, is
already in an existing package), it seems you set a dirty flag. Hook into that
mechanism and warn the user that he's overriding existing code. (Sorry, my
thoughts are a bit jumbled. Did you understand all that?)

> [more snipped]
> Er, so does that mean it would be best to update SUnit, or that it would be
> wise to remain on the version we have at the moment?

Jeff dropped me a line yesterday. We'll coordinate, and get you the latest
stuff.

Hmmm...I started trying to dig into your window construction and opening code
yesterday, got confused and gave up. I could probably quickly flesh out the code
if I could figure out what's happening ;-) In any case, the idea would be to
trigger an event after the menu has been instantiated but before it's visible.
This event must carry 3 parameters:

* a Symbol (at best the menu selector) - so that listeners know which menu has
been realized, and can decide if it's the one that they want to hang in to (like
the aspect of a #changed event)
* the Menu itself - so that listeners can programmatically add items to it
* the Browser instance - because the Browser is the main source of state
information for menu selections, and will serve as receiver of most of the menu
callbacks.

This gives anyone the chance to hook into existing browser menus without people
stepping on each others' feet. I would deliver a tool in a package which had the
code for hooking the menu callbacks in its post-load initialization code.

In ENVY, I had to do it differently because OTI didn't have the event hooks in
there, and because they weren't going to put them in for me. I figure I'll have
better luck with you chaps ;-) Anyway, the years, and the success of the ENVY
version among third-party vendors, have shown this to be a viable mechanism, and
have shown that the 3 parameters are necessary.

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

"Joseph Pelrine" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> I think that The Simplest Thing etc. would be to fully implement the
concept of
> default package. You have (I think) all the hooks needed there already.
The
> default package would be similar to a Change Set, or ENVY (Sub)App. When
you
> create a package, it automatically becomes the default. From the
PackageBrowser,
> you can also choose the default. All added definitions automatically go
into
> this package. When you change an existing definition (which, of course, is
> already in an existing package), it seems you set a dirty flag. Hook into
that
> mechanism and warn the user that he's overriding existing code. (Sorry, my
> thoughts are a bit jumbled. Did you understand all that?)

We'd been thinking of removing the Default Package now that classes can have
the package specified at creation time (there will be a dialog in the next
release to replace the multiple prompters in the betas 1 and 2), but that
sounds like a sensible reason to keep it.

Would you propose that all new definitions (classes, methods, resources,
etc) be added to the default package even when defining things in the
browsers? I'm thinking in particular of methods, which would imply that
every time one added a method to a class not in the default package that it
would automatically become a loose method in the default package (rather
than a normal method in the package of its class)? I suppose that makes
sense in general, since one could easily turn it off when one didn't want
that behaviour.

I don't particularly like the idea of automatically making a new package the
default, but it could be optional.

> > > > - Do you offer hooks to add items to browser menus?.
>
> Hmmm...I started trying to dig into your window construction and opening
code
> yesterday, got confused and gave up. I could probably quickly flesh out
the code
> if I could figure out what's happening ;-) In any case, the idea would be
to
> trigger an event after the menu has been instantiated but before it's
visible.
> This event must carry 3 parameters:
>
> * a Symbol (at best the menu selector) - so that listeners know which menu
has
> been realized, and can decide if it's the one that they want to hang in to
(like
> the aspect of a #changed event)
> * the Menu itself - so that listeners can programmatically add items to it
> * the Browser instance - because the Browser is the main source of state
> information for menu selections, and will serve as receiver of most of the
menu
> callbacks.
>
> This gives anyone the chance to hook into existing browser menus without
people
> stepping on each others' feet. I would deliver a tool in a package which
had the
> code for hooking the menu callbacks in its post-load initialization code.

Actually there is already an event fired before a menu is "popped",
#aboutToDisplayMenu:. For the reasons discussed in the other thread (mainly
that the processing of commands in Dolphin is not hardwired as callbacks,
but dynamically determined by routing along a chain of responsibility), it
is probably not adequate in itself. #aboutToDisplayMenu: is typically used
for dynamic menu population. Since this is sent every time the menu is
popped, this may not be the best place to perform relatively static
additions for tool extensions, so it would probably be better to pick up the
view creation event and adjust the menus then.

>
> In ENVY, I had to do it differently because OTI didn't have the event
hooks in
> there, and because they weren't going to put them in for me. I figure I'll
have
> better luck with you chaps ;-) Anyway, the years, and the success of the
ENVY
> version among third-party vendors, have shown this to be a viable
mechanism, and
> have shown that the 3 parameters are necessary.

The one parameter to #aboutToDisplayMenu: should be adequate because it is
the Menu itself, from which one can easily determine the symbolic name of
the menu (although not all menus are named, and in fact they typically
aren't if they don't contain any dynamic content or one doesn't need to
control enablement/disablement of the entire menu, so one might have to rely
on the display name, e.g. 'File', or 'Help'). We typically don't pass the
source of the event (such as the Browser instance), since the observer would
have had to register an interest in the event with the specific browser
instance, and could add additional parameters at the time if it needed them
in the handler (i.e. the event you receive need not have the same number of
arguments as the event triggered, and the parameters supplied when triggered
can be supplemented by parameters supplied when registered).

Regards

Blair