[MACTCL] Re: Option key in Tk for MacOSX

[Jim I. <ji...@ap...>]

On Wednesday, February 12, 2003, at 01:54  PM, Benjamin Riefenstahl  
wrote:

> Hi Jim, all,
>
>
> Jim Ingham <ji...@ap...> writes:
>> Yes.  But I think it is also just going to require a bit of
>> experimentation first.  We should try to craft a policy, but expect
>> that the first couple of times we are going to be wrong (Carbon will
>> smack us in the face to let us know this, from my experience...)
>
> In this vein I made a new version of the event handling patch that
> does nothing else so that this can be tested without any baggage.
> It's at
> http://sourceforge.net/tracker/ 
> download.php?group_id=12997&atid=312997&file_id=42231&aid=622582
> It is based on the CVS HEAD plus the latest patch to
> tkMacOSXKeyEvent.c.  If you don't have that other patch, just replace
> all occurences tkMacOSXKeyEvent.c of handledByTk with stopProcessing,
> and it should compile.
>
> It basically starts with a clean slate.  It works for a simple
> exercise of the widgets demo, including the Navigation Services.
> Please test and report any problems, preferably with reproducible test
> cases.
>
> Vince Darley wrote:
>> (I assume small details like the '+' '-' etc appearing on the
>> traffic light when you mouse-over will be fixed with this)
>
> Actually I found that these indeed work with this.
>
>

This is kind of spooky.  I explicitly DON'T add the standard window  
handler to new windows when I create them.  So what is the handler that  
is running the stoplights, then???  For now, your patch is pretty  
benign, because nobody (except for this mysterious stoplight handler)  
is really listening to the events we forward at present.  I wouldn't  
mind actually putting it in, if we can get a little more testing, with  
the proviso that as it stands now if you add Carbon event handlers you  
could very easily mess everything up...

For instance, suppose we (or some other component for its own reasons)  
HAD installed the standard window event handler and and we forwarded  
all mouse click events on to the event target.  In that case, if you  
clicked on the red traffic light button, Tk gets this click, and closes  
the window, then you send the event to the target, which - were the  
window to still exist - would ALSO try to close it.

In fact, if you want a little laugh, try changing tkMacOSXWm.c:4919 to

         err = CreateNewWindow(wmPtr->macClass, wmPtr->attributes |  
kWindowStandardHandlerAttribute,
                 &geometry, &newWindow);

Ooh, that doesn't work very well...

For sure when Tk does it's window management thing it doesn't want  
somebody else to get in there & mess it up.  So in general, I would  
tend to be more conservative than you are.  So, for instance, if a  
mouse up or down event occurs in a window made by Tk, I would NOT pass  
it on to whatever other handler might have registered itself with this  
window.

I don't intend to sound negative, however.  Your idea is a good  
foundation for doing experiments.  As there start to be other folks  
trying to use the events we forward, we will figure out which things Tk  
can afford to pass on and which it can't, and set up the code  
accordingly.

Jim



> so long, benny
>
>
--
Jim Ingham                                   ji...@ap...
Developer Tools
Apple Computer