Re: Problem with stopModalWithCode on a different thread
Re: Problem with stopModalWithCode on a different thread
- Subject: Re: Problem with stopModalWithCode on a different thread
- From: Bill Appleton <email@hidden>
- Date: Tue, 22 Jun 2010 14:36:06 -0700
all that stuff in the docs you mention is about interacting with the browser
now the browser is a whole separate application, its talking to the
WebKitPluginHost through ports
so thats what they are talking about -- if you want a popup menu on the
browser screen you have to call their API
but invoking an open file dialog from a plugin should be fine, its all a
separate window ,separate process etc.
this is much more solid than the carbon/quickdraw/x manager stuff we used to
use
thx
bill
On Tue, Jun 22, 2010 at 2:19 PM, Charles Srstka <email@hidden>wrote:
> On Jun 22, 2010, at 4:14 PM, Bill Appleton wrote:
>
> > Not sure I understand all the issues but this should be good news for
> Cocoa lovers:
> >
> > 1) When Safari runs as 64 bit it loads and runs a 32 bit or 64 bit Cocoa
> NPAPI plugin just fine. The 32 bit version of Safari will only run 32 bit
> NPAPI plugins.
> >
> > 2) The exact same 32 bit plugin for Safari will work great in FireFox 32,
> although you need to ask for the Carbon Event model. That is pretty amazing
> -- FireFox hasn't released a Cocoa version yet!
> >
> > 3) The FireFox 64 bit release candidate (minefield) runs the 64 bit
> version just great. I'm not sure if 64 bit firefox will run a 32 bit plugin,
> I will find out.
> >
> > At runtime there is nothing strange going on anymore since they fixed
> these bugs. You are running on the main thread in your own process. NPApp is
> initialized for you. Actually the "out of process" security thing is really
> cool, it is a more isolated & predictable environment for us to run in.
>
> The problem is that this isn’t a bug that was fixed. It’s undocumented
> behavior that just *happens* to do what you want in *this* particular
> version. It might not in the next version. Apple’s guidelines recommend
> against doing this, so it’s not at all guaranteed that it will work. On
> Firefox, it *certainly* isn’t guaranteed to work.
>
> I maintain that the best option is to fork/exec a background app (with
> LSUIElement set to 1 in its Info.plist) to do your AppKit stuff, which seems
> to be what Apple’s recommending:
>
> > • Avoid creating windows. The intent is for plug-ins to operate
> within the browser window. Although some plug-ins have historically done so,
> creating windows in your plug-in is not recommended. If you need to maintain
> separate windows, you should consider starting a separate application.
>
>
> Charles
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden