Closed Bug 270892 Opened 21 years ago Closed 15 years ago

Freeze nsIAppShell

Categories

(Core Graveyard :: Embedding: APIs, defect)

Product:
Core Graveyard
Component:
Embedding: APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jhpedemonte, Unassigned)

References

Details

Freeze nsIAppShell.
Blocks: 268520
No way.
nsIAppShell::Create *must* not be frozen in its current form. What exact functionality do we need to freeze, and from what (to be frozen) source do you get this interface?
bsmedberg: our linux embedding samples tell people to use nsIAppShell. see gtkmozembed. eclipse simply copied that code :-( i suspect that we may need to support an obsolete, yet compatible version of this interface. just like nsIBaseWindow we screwed ourselves by not providing a means to embed gecko without touching nsIAppShell (under unix at least). that said, i suspect that we might be able to create an AppShell component that simply does nothing when these methods are called. An embedder should not have to create and spinup an appshell. That should happen automagically as gecko is used.
(In reply to comment #3) > bsmedberg: our linux embedding samples tell people to use nsIAppShell. see > gtkmozembed. eclipse simply copied that code :-( We can't just freeze this interface, we would have to freeze some path to get at this interface. Do you really want to freeze appShell = do_CreateInstance(kAppShellCID); ? > that said, i suspect that we might be able to create an AppShell component that > simply does nothing when these methods are called. An embedder should not have > to create and spinup an appshell. That should happen automagically as gecko is > used. That's not what gtkmozembed does now: http://lxr.mozilla.org/mozilla/source/embedding/browser/gtk/src/EmbedPrivate.cpp#510 Are you saying that some other magical entity should perform the initialization steps?
>Are you saying that some other magical entity should perform the initialization >steps? NS_InitEmbedding?
NS_InitEmbedding lives in a static lib that is linked by the embedder, not by moz :( And we're not going to be able to get a good-enough libxul for embedders to link against by 1.8, so we don't have a good place to export that kind of symbol.
Why can't the appshell initialization be triggered by XPCOM startup? The appshell is part of the native event queue implementation, so initialization of the main native event queue by XPCOM init could be sufficient to trigger appshell initialization. I haven't figured out what the best trigger mechanism should be.
could appshell observe xpcom-startup and use that to initialize itself? (I don't know anything about appshell or native event queues...)
I want to have a method in libxul NS_InitToolkit(int *argc, char ***argv); This method will be called before NS_InitXPCOM2 and will initialize GTK/QT/whatever. "XUL app embedders" would call this method, but "gtkmozembed embedders" wouldn't (since the embedder has already initialized GTK). This method will replace nsIAppShell::Create. An xpcom-startup observer won't help here at all. Spinup/Spindown are different, and xpcom-startup/shutdown observers might be appropriate there. I don't actually understand how spinup/spindown/run are intermingled with xpcom event queues, so I can't comment. If we can hookup xpcom-startup/shutdown observers and add the NS_InitToolkit call, I suspect that we could freeze nsIAppShellObsolete and make all of create/spinup/shutdown methods no-ops.
The widget-specific appshell classes are all about hooking up native event queues. Spinup ensures that the current thread has a native event queue that is properly configured. Remember those pesky nsIObserver events generated from nsEventQueueImpl? Perhaps we would do better to have an interface like nsINativeEventQueueProvider or something like that under a registered ContractID or something to allow XPCOM to call out directly to the "appshell" code. Then, we might be able to eliminate gtkmozembed's use of nsIAppShell. If we are successful at doing that, then nsIAppShell "as is" could be renamed to nsIAppShellObsolete. We could make the implementation of that interface do nothing, and then internally we would still have nsIAppShell for the other methods that it provides. I suspect this could be done independent of NS_InitToolkit.
nsIAppShell.Create has nothing to do with hooking up the event queue, and is all about initializing the toolkit using command-line args. It's a no-op on GTK/GTK2 because we special-case gtk_init() in nsAppRunner. I'm mentioning the problem here because I need to fix it for 1.8b to land the command-line-handling work.
It appears to be a no-op on Windows, OS/2, and Cocoa too. Hmm...
>I want to have a method in libxul NS_InitToolkit(int *argc, char ***argv); This >method will be called before NS_InitXPCOM2 and will initialize GTK/QT/whatever. that means if I want to use xpcom services in order to provide --help output, then --help needs a running X server? same for --CreateProfile...
or worse, on osx you can't do it if you ssh in and aren't the console user/root.
QA Contact: timeless
-> reassign to default owner
Assignee: darin.moz → nobody
QA Contact: timeless → apis
We no longer freeze interfaces.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.