all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jan D." <jan.h.d@swipnet.se>
Cc: m_wingert@sbcglobal.net, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: GtkPlug patch
Date: Wed, 4 Jan 2006 23:09:25 +0100	[thread overview]
Message-ID: <8E272012-0E75-4566-A9A6-F2BC92C43440@swipnet.se> (raw)
In-Reply-To: <85d5j9f99e.fsf@lola.goethe.zz>

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>>     But even if it is very simple in the Gtk+ case, and only a bit  
>> more
>>     complicated in the general case, there are other issues here.   
>> Like for
>>     instance, what should an embedded Emacs do when someone tries to
>>     move or resize the window from lisp?
>>
>> These operations could do nothing in a reparented window.
>>
>>       Therefore I think this should wait
>>     to the next release.
>>
>> Ok.
>
> 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?

No, Emacs has to be called with the --parent-id flag.  The  
specification is very unclear on how the two applications finds each  
other.  Basically they say that that is out of the scope for the  
XEMBED specification.


>
> 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.

Yes, that is true.  But I suspect that if we put this in now we will  
get bug reports about things like keyboard focus, which doesn't work  
correctly with this patch (due to the fact that Emacs isn't a "pure"  
GTK implementation).

But if the author is willing to handle those bug reports, we can put  
this patch in now.  It is a very small change, and very safe in that  
it does not alter the normal code path unless you use --parent-id.

>
> 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 suggested patches are very easy to integrate in just about any  
branch, they just add/modify one or two lines here and there. No big  
changes.

	Jan D.

  parent reply	other threads:[~2006-01-04 22:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-26 23:09 GtkPlug patch Timo Savola
2005-12-29  7:02 ` Timo Savola
2005-12-31 11:06   ` Jan Djärv
2005-12-31 11:23     ` Jan Djärv
2005-12-31 17:24     ` mr mike
2006-01-01  2:14       ` Richard M. Stallman
2006-01-01 15:57         ` Jan Djärv
2006-01-02  0:25           ` Richard M. Stallman
2006-01-02  9:18             ` Timo Savola
2006-01-02  9:51               ` Timo Savola
2006-01-02 23:48               ` Richard M. Stallman
2006-01-03  8:45                 ` Timo Savola
2006-01-03  7:53             ` Jan D.
2006-01-03 18:27               ` Richard M. Stallman
2006-01-03 18:37                 ` David Kastrup
2006-01-03 20:29                   ` Timo Savola
2006-01-04  6:15                     ` Richard M. Stallman
2006-01-04 22:11                     ` Jan D.
2006-01-04 22:09                   ` Jan D. [this message]
2006-01-05  6:13                     ` Timo Savola
2006-01-05 10:34                       ` Jan D.
2006-01-03 13:41 ` Lőrentey Károly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8E272012-0E75-4566-A9A6-F2BC92C43440@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=emacs-devel@gnu.org \
    --cc=m_wingert@sbcglobal.net \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.