Re: [MACTCL] Re: carbon events in libraries?

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

I think the WindowServer doesn't like applications that aren't put in 
.app wrappers, with the proper Info.plist, etc goop (or equivalent 
resource stuff if you are a CFM app).  So if pd is just a raw binary, I 
don't think it will ever come to the foreground.  We had this problem 
with Wish as well, which is one of the reasons (besides that the App 
packages are kind of cool and we can use them in other ways) that Wish 
on X is a .app...  It was a long time ago, but IIRC one of the symptoms 
was that none of the windows would ever come to the foreground.

So try taking your pd app, and making it into an App wrapper.  One 
really easy way to do this is to make an app target in PB/Xcode, set 
the Name, and doc  types, etc. correctly in the GUI, and then just 
blast the pd binary on top of the little sample one that the App target 
makes.  You can even add a "Copy Files" build phase to do this if you 
are really ambitious.

See if this works any better...

Jim

On Jan 15, 2004, at 10:55 AM, ti...@ma... wrote:

>
> On Wednesday, January 14, 2004, at 03:54  PM, Eric Schlegel wrote:
>> Maybe call SetFrontProcess on your process serial number?
>>
>> ProcessSerialNumber psn = { 0, kCurrentProcess };
>> SetFrontProcess( &psn );
>
> ...well, now I've tried this, but it doesn't seem to have an effect:  
> the window still remains in the background...I then thought to look in 
> the tk code for SetFrontProcess(), and found it in tkMacOSXHLEvents.c; 
> it is used in a callback which is installed in the following manner:
>
>     RappHandlerUPP = NewAEEventHandlerUPP(RappHandler);
>     err = AEInstallEventHandler(kCoreEventClass, kAEReopenApplication,
>             RappHandlerUPP, (long) interp, false);
>
> ...since I'm not familiar with this kind of event, I'm kinda lost at 
> what the effect would be?  Could this be the manner in which the Wish 
> Shell maintains it's "foreground"-ness?
>
> ...in another line of thinking, is there any api for registering an 
> application with the operating system/window manager?  Since pd never 
> shows up in the dock, perhaps by making it behave properly (or even 
> forcing it to happen when GEM is loaded) would solve this?
>
>> Is there any way that you can have pd run as a part of the tck/tk 
>> process, instead of a separate process?
>
> ...I'm not sure about this;  pd is started from the terminal, then 
> starts wish shell, and then the two apps communicate on port 
> 5400...I've started looking at the cocoa sample code "Moriarity", 
> which is a gui wrapper around the "locate" program; this may be a way 
> around, but I'm not entirely optimistic, since pd has it's own event 
> routines and is quite a bit more complex than "locate"...is there a 
> similar method for doing this kind of "wrapping" via carbon?
>
> ...To finish, some good news:  even with the above complaints, I've 
> been able to get a form of mouse input via the GEM-window (by 
> click-drag), and the standardhandlers for closewindow and minimize 
> work...it'd just be great to get the stupid thing to the front!
>
> thanx,
> jamie
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
--
Jim Ingham                                   ji...@ap...
Developer Tools
Apple Computer