Re: GtkPlug patch

[Timo Savola <timo.savola@iki.fi>]

> Question: would this stuff make any difference unless Emacs was called
> in a special way?  Is there some protocol advertising the possibility
> for embedding that might be used by window managers or other
> applications to check for embeddability?

Emacs becomes embeddable only if parent-id is passed to a frame.  A
normally created frame's window doesn't get the _XEMBED_INFO property.
(This is the "alternate method of beginning the protocol" mentioned in
the "Embedding life cycle" section of the XEmbed spec.)

> If all of this is not the case, then the respective code paths would
> basically just get exercised when one explicitly does something that
> one could not do before.  If there are just a few such code spaces,
> the impact on the general release quality would be negligible.

I was thinking that perhaps the functionality could be implemented
internally (emacs-gtkplug.patch, emacs-parent-fix.patch) even if the
command-line interface change (emacs-parentid.patch) is too radical at
this point.

Is modifying the initial-frame-alist using --eval or some other means
possible before the frame is created?  Is it possible to use --batch to
bootstrap and run the Emacs main loop?  If so, embedders could set the
parent-id manually while the XEmbed functionality is experimental.

> How hard will it be to integrate those patches (or the respective
> functionality) after the release?  Would it make sense to integrate
> them already in the multi-tty branch, or should we rather store them
> somewhere separately after the release?  Separate branch?

The current patches are quite trivial.  I guess a bigger question is:
against which branch should the Xlib/Xt version be implemented?

(A decentralized revision control system would help here.)

> Does this make sense?  Or would the authors of this patch prefer to
> try their hand again from a clean head after release?

I prefer to do what's best...

timo