unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* GtkPlug patch
@ 2005-12-26 23:09 Timo Savola
  2005-12-29  7:02 ` Timo Savola
  2006-01-03 13:41 ` Lőrentey Károly
  0 siblings, 2 replies; 22+ messages in thread
From: Timo Savola @ 2005-12-26 23:09 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

Hi.

I wanted to add XEmbed[1] support to Emacs and noticed that it's really
easy to accomplish with the new GTK support.  The attached patches
implement that:

emacs-parentid.patch
	Add the --parent-id command-line option to set the parent-id
	frame option (which was already implemented).

emacs-parent-fix.patch
	For some reason x-create-frame resets parent_desc to the root
	window after first setting it according to the parent-id
	option.  This patch removes that seemingly redundant assignment.

emacs-gtkplug.patch
	Creates a GtkPlug instead of GtkWindow when parent_desc is set.

I created the patches against the CVS version dated 2005-12-19 because I
failed to "make bootstrap" for HEAD (batch-update-autoloads failed at
vc-annotate-car-last-cons).

embedder.py is a PyGTK test program that can be used with command:
	./embedder.py path/to/patched/emacs

I'm looking forward to getting this feature into Emacs.  Please
criticize my implementation (I've never hacked Emacs before) or provide
instructions if I can do something more to help.

(Please put me to CC when replying.)

timo

[1] http://freedesktop.org/Standards/xembed-spec


[-- Attachment #2: emacs-gtkplug.patch --]
[-- Type: text/x-patch, Size: 435 bytes --]

diff -u -r1.70 gtkutil.c
--- src/gtkutil.c	20 Sep 2005 20:07:15 -0000	1.70
+++ src/gtkutil.c	26 Dec 2005 19:49:12 -0000
@@ -716,7 +716,11 @@
 
   BLOCK_INPUT;
 
-  wtop = gtk_window_new (GTK_WINDOW_TOPLEVEL);
+  if (f->output_data.x->explicit_parent)
+    wtop = gtk_plug_new (f->output_data.x->parent_desc);
+  else
+    wtop = gtk_window_new (GTK_WINDOW_TOPLEVEL);
+
   xg_set_screen (wtop, f);
 
   wvbox = gtk_vbox_new (FALSE, 0);

[-- Attachment #3: emacs-parentid.patch --]
[-- Type: text/x-patch, Size: 2035 bytes --]

diff -u -r1.390 startup.el
--- lisp/startup.el	22 Nov 2005 03:32:50 -0000	1.390
+++ lisp/startup.el	26 Dec 2005 19:48:55 -0000
@@ -149,7 +149,8 @@
     ("--vertical-scroll-bars" 0 x-handle-switch vertical-scroll-bars t)
     ("--line-spacing" 1 x-handle-numeric-switch line-spacing)
     ("--border-color" 1 x-handle-switch border-color)
-    ("--smid" 1 x-handle-smid))
+    ("--smid" 1 x-handle-smid)
+    ("--parent-id" 1 x-handle-parent-id))
   "Alist of X Windows options.
 Each element has the form
   (NAME NUMARGS HANDLER FRAME-PARAM VALUE)
diff -u -r1.184 x-win.el
--- lisp/term/x-win.el	2 Nov 2005 21:43:21 -0000	1.184
+++ lisp/term/x-win.el	26 Dec 2005 19:48:59 -0000
@@ -181,6 +181,15 @@
   (setq initial-frame-alist (cons (cons 'name x-resource-name)
 				  initial-frame-alist)))
 
+;; Handle the --parent-id option.
+(defun x-handle-parent-id (switch)
+  (or (consp x-invocation-args)
+      (error "%s: missing argument to `%s' option" (invocation-name) switch))
+  (setq parent-id (string-to-number (car x-invocation-args))
+	x-invocation-args (cdr x-invocation-args))
+  (setq initial-frame-alist (cons (cons 'parent-id parent-id)
+				  initial-frame-alist)))
+
 (defvar x-display-name nil
   "The X display name specifying server and X frame.")
 
diff -u -r1.380 emacs.c
--- src/emacs.c	23 Nov 2005 07:19:03 -0000	1.380
+++ src/emacs.c	26 Dec 2005 19:49:03 -0000
@@ -322,6 +322,7 @@
 --title, -T TITLE               title for initial Emacs frame\n\
 --vertical-scroll-bars, -vb     enable vertical scroll bars\n\
 --xrm XRESOURCES                set additional X resources\n\
+--parent-id XID                 set parent window\n\
 --help                          display this help and exit\n\
 --version                       output version information and exit\n\
 \n"
@@ -1859,6 +1860,7 @@
   { "-title", 0, 10, 1 },
   { "-name", "--name", 10, 1 },
   { "-xrm", "--xrm", 10, 1 },
+  { "-parent-id", "--parent-id", 10, 1 },
   { "-r", "--reverse-video", 5, 0 },
   { "-rv", 0, 5, 0 },
   { "-reverse", 0, 5, 0 },

[-- Attachment #4: emacs-parent-fix.patch --]
[-- Type: text/x-patch, Size: 439 bytes --]

diff -u -r1.649 xfns.c
--- src/xfns.c	8 Dec 2005 15:48:56 -0000	1.649
+++ src/xfns.c	26 Dec 2005 20:50:33 -0000
@@ -3265,8 +3265,6 @@
   x_default_parameter (f, parms, Qfullscreen, Qnil,
                        "fullscreen", "Fullscreen", RES_TYPE_SYMBOL);
 
-  f->output_data.x->parent_desc = FRAME_X_DISPLAY_INFO (f)->root_window;
-
   /* Compute the size of the X window.  */
   window_prompting = x_figure_window_size (f, parms, 1);
 

[-- Attachment #5: embedder.py --]
[-- Type: text/x-python, Size: 1020 bytes --]

#!/usr/bin/env python

import sys
import os
import gobject
import gtk

failure = False
child = None

def on_socket_map(socket, command):
	global child, failure

	try:
		child = os.spawnvp(os.P_NOWAIT, command[0], command + ['--parent-id', str(socket.get_id())])
		gobject.child_watch_add(child, on_child_exited)
	except:
		failure = True
		raise

def on_child_exited(pid, condition):
	gtk.main_quit()
	print 'Child exit condition:', condition

def on_window_delete(window, event):
	gtk.main_quit()
	os.kill(child, 15)
	return False

def main(args):
	window = gtk.Window()
	window.set_default_size(640, 480)
	window.set_title('Embedder')
	window.set_property('border-width', 4)
	window.connect('delete-event', on_window_delete)

	frame = gtk.Frame()
	frame.set_property('shadow-type', gtk.SHADOW_IN)
	window.add(frame)

	socket = gtk.Socket()
	socket.connect_after('map', on_socket_map, args)
	frame.add(socket)

	window.show_all()

	if failure:
		sys.exit(1)

	gtk.main()

if __name__ == '__main__':
	main(sys.argv[1:])

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2005-12-26 23:09 GtkPlug patch Timo Savola
@ 2005-12-29  7:02 ` Timo Savola
  2005-12-31 11:06   ` Jan Djärv
  2006-01-03 13:41 ` Lőrentey Károly
  1 sibling, 1 reply; 22+ messages in thread
From: Timo Savola @ 2005-12-29  7:02 UTC (permalink / raw)


> I created the patches against the CVS version dated 2005-12-19 because I
> failed to "make bootstrap" for HEAD (batch-update-autoloads failed at
> vc-annotate-car-last-cons).

The patches seem to apply against HEAD which is now working.

(Has anyone looked at this stuff yet?)

timo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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
  0 siblings, 2 replies; 22+ messages in thread
From: Jan Djärv @ 2005-12-31 11:06 UTC (permalink / raw)
  Cc: emacs-devel

Timo Savola wrote:
>>I created the patches against the CVS version dated 2005-12-19 because I
>>failed to "make bootstrap" for HEAD (batch-update-autoloads failed at
>>vc-annotate-car-last-cons).
> 
> 
> The patches seem to apply against HEAD which is now working.
> 
> (Has anyone looked at this stuff yet?)

Yes.  But we should make it work for all Emacs X variants, not just GTK, if 
that is possible.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2005-12-31 11:06   ` Jan Djärv
@ 2005-12-31 11:23     ` Jan Djärv
  2005-12-31 17:24     ` mr mike
  1 sibling, 0 replies; 22+ messages in thread
From: Jan Djärv @ 2005-12-31 11:23 UTC (permalink / raw)
  Cc: emacs-devel

Jan Djärv wrote:
> Timo Savola wrote:
> 
>>> I created the patches against the CVS version dated 2005-12-19 because I
>>> failed to "make bootstrap" for HEAD (batch-update-autoloads failed at
>>> vc-annotate-car-last-cons).
>>
>>
>>
>> The patches seem to apply against HEAD which is now working.
>>
>> (Has anyone looked at this stuff yet?)
> 
> 
> Yes.  But we should make it work for all Emacs X variants, not just GTK, 
> if that is possible.

As for the patch itself, it looks fine.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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
  1 sibling, 1 reply; 22+ messages in thread
From: mr mike @ 2005-12-31 17:24 UTC (permalink / raw)


from http://www.freedesktop.org/wiki/Standards_2fxembed_2dspec 

XEmbed is a protocol that uses basic X mechanisms such as client
messages and reparenting windows to provide embedding of a control from
one application into another application.

So, theoretically, there is nothing that stops it from being adapted the
other X variants.

Thanks to Timo Savola for the work!  

mike


On Sat, 2005-12-31 at 12:06 +0100, Jan Djärv wrote:
> Timo Savola wrote:
> >>I created the patches against the CVS version dated 2005-12-19 because I
> >>failed to "make bootstrap" for HEAD (batch-update-autoloads failed at
> >>vc-annotate-car-last-cons).
> > 
> > 
> > The patches seem to apply against HEAD which is now working.
> > 
> > (Has anyone looked at this stuff yet?)
> 
> Yes.  But we should make it work for all Emacs X variants, not just GTK, if 
> that is possible.
> 
> 	Jan D.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2005-12-31 17:24     ` mr mike
@ 2006-01-01  2:14       ` Richard M. Stallman
  2006-01-01 15:57         ` Jan Djärv
  0 siblings, 1 reply; 22+ messages in thread
From: Richard M. Stallman @ 2006-01-01  2:14 UTC (permalink / raw)
  Cc: emacs-devel

    XEmbed is a protocol that uses basic X mechanisms such as client
    messages and reparenting windows to provide embedding of a control from
    one application into another application.

    So, theoretically, there is nothing that stops it from being adapted the
    other X variants.

Does anyone know what we need to do
to make the Xt versions of Emacs handle XEmbed?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-01  2:14       ` Richard M. Stallman
@ 2006-01-01 15:57         ` Jan Djärv
  2006-01-02  0:25           ` Richard M. Stallman
  0 siblings, 1 reply; 22+ messages in thread
From: Jan Djärv @ 2006-01-01 15:57 UTC (permalink / raw)
  Cc: m_wingert, emacs-devel

Richard M. Stallman wrote:
>     XEmbed is a protocol that uses basic X mechanisms such as client
>     messages and reparenting windows to provide embedding of a control from
>     one application into another application.
> 
>     So, theoretically, there is nothing that stops it from being adapted the
>     other X variants.
> 
> Does anyone know what we need to do
> to make the Xt versions of Emacs handle XEmbed?

Since Emacs has its own event loop, the implementation for non-Xt (i.e. pure 
Xlib) would be the same as for Xt.  Like the drop part of drag and drop is now.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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-03  7:53             ` Jan D.
  0 siblings, 2 replies; 22+ messages in thread
From: Richard M. Stallman @ 2006-01-02  0:25 UTC (permalink / raw)
  Cc: m_wingert, emacs-devel

    > Does anyone know what we need to do
    > to make the Xt versions of Emacs handle XEmbed?

    Since Emacs has its own event loop, the implementation for non-Xt (i.e. pure 
    Xlib) would be the same as for Xt.  Like the drop part of drag and drop is now.

So much the better--but still, does someone know how to make the event loop
handle these?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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  7:53             ` Jan D.
  1 sibling, 2 replies; 22+ messages in thread
From: Timo Savola @ 2006-01-02  9:18 UTC (permalink / raw)
  Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

>     > Does anyone know what we need to do
>     > to make the Xt versions of Emacs handle XEmbed?
> 
>     Since Emacs has its own event loop, the implementation for non-Xt (i.e. pure 
>     Xlib) would be the same as for Xt.  Like the drop part of drag and drop is now.
> 
> So much the better--but still, does someone know how to make the event loop
> handle these?

I guess I could take a look at it unless someone more familiar with the
Emacs X code (or the existing XEmbed implementations in GTK+ or Qt) is
willing to.

Is there a chance of getting the GTK version into Emacs 22?

timo



[-- Attachment #2: Type: text/plain, Size: 595 bytes --]


This message has been scanned by F-Secure Anti-Virus

###  OXFORD INSTRUMENTS   http://www.oxford-instruments.com/  ###

Unless stated above to be non-confidential, this E-mail and any
attachments are private and confidential and are for the addressee
only and may not be used, copied or disclosed save to the addressee.
If you have received this E-mail in error please notify us upon receipt
and delete it from your records. Internet communications are not secure
and Oxford Instruments is not responsible for their abuse by third
parties nor for any alteration or corruption in transmission.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-02  9:18             ` Timo Savola
@ 2006-01-02  9:51               ` Timo Savola
  2006-01-02 23:48               ` Richard M. Stallman
  1 sibling, 0 replies; 22+ messages in thread
From: Timo Savola @ 2006-01-02  9:51 UTC (permalink / raw)
  Cc: emacs-devel

> Unless stated above to be non-confidential, this E-mail and any
> attachments are private and confidential and are for the addressee
> only and may not be used, copied or disclosed save to the addressee.

Sorry about this; I didn't realize what sort of smtp server was going to
be used.  Will not happen again.

timo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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
  1 sibling, 1 reply; 22+ messages in thread
From: Richard M. Stallman @ 2006-01-02 23:48 UTC (permalink / raw)
  Cc: emacs-devel

    I guess I could take a look at it unless someone more familiar with the
    Emacs X code (or the existing XEmbed implementations in GTK+ or Qt) is
    willing to.

Thank you.  Please do.

    Is there a chance of getting the GTK version into Emacs 22?

It already is!

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-02  0:25           ` Richard M. Stallman
  2006-01-02  9:18             ` Timo Savola
@ 2006-01-03  7:53             ` Jan D.
  2006-01-03 18:27               ` Richard M. Stallman
  1 sibling, 1 reply; 22+ messages in thread
From: Jan D. @ 2006-01-03  7:53 UTC (permalink / raw)
  Cc: m_wingert, emacs-devel

>     > Does anyone know what we need to do
>     > to make the Xt versions of Emacs handle XEmbed?
> 
>     Since Emacs has its own event loop, the implementation for non-Xt (i.e. pure 
>     Xlib) would be the same as for Xt.  Like the drop part of drag and drop is now.
> 
> So much the better--but still, does someone know how to make the event loop
> handle these?

We have to take care of some SendEvent:s and PropertyNotify regarding
focus and keyboard/mouse input, as well as reacting slightly different
to ReparentNotify.

Basically XEMBED spcifies how an embedder shall forward events (key, mouse)
to the embedded application (Emacs in this case).  It also specifies how
the embedder tells the embedded application when it has focus or not, and
when it should move the focus to the next member in a TAB-group (like
tabbing to the next button in a toolbar).  The embedded application can
also register accelerator keys so when the embedder has focus it knows when
an accelerator key is pressed that it should go to the embedded application.

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?  The code in general assumes Emacs
is not embedded, but a free standing application.  I suspect if we put this
in now, we will find several such issues.  Therefore I think this should wait
to the next release.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-02 23:48               ` Richard M. Stallman
@ 2006-01-03  8:45                 ` Timo Savola
  0 siblings, 0 replies; 22+ messages in thread
From: Timo Savola @ 2006-01-03  8:45 UTC (permalink / raw)
  Cc: emacs-devel

>     Is there a chance of getting the GTK version into Emacs 22?
> 
> It already is!

I meant the GTK XEmbed support, but Jan D. already answered that.

timo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2005-12-26 23:09 GtkPlug patch Timo Savola
  2005-12-29  7:02 ` Timo Savola
@ 2006-01-03 13:41 ` Lőrentey Károly
  1 sibling, 0 replies; 22+ messages in thread
From: Lőrentey Károly @ 2006-01-03 13:41 UTC (permalink / raw)



[-- Attachment #1.1: Type: text/plain, Size: 765 bytes --]

Timo Savola <timo.savola@iki.fi> writes:
> I wanted to add XEmbed[1] support to Emacs and noticed that it's really
> easy to accomplish with the new GTK support.  The attached patches
> implement that:
>
> I'm looking forward to getting this feature into Emacs.  Please
> criticize my implementation (I've never hacked Emacs before) or provide
> instructions if I can do something more to help.

This is most welcome, and I am happy to note that it seems really easy
to implement support for it in emacsclient as well.  Excellent work!

I noticed, though, that I get "*** glibc detected *** corrupted
double-linked list: 0xb79c9898 ***" messages after I do a C-x 5 2 and
then close the new standalone frame.  (Emacs dies after this.)

-- 
Károly

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-03  7:53             ` Jan D.
@ 2006-01-03 18:27               ` Richard M. Stallman
  2006-01-03 18:37                 ` David Kastrup
  0 siblings, 1 reply; 22+ messages in thread
From: Richard M. Stallman @ 2006-01-03 18:27 UTC (permalink / raw)
  Cc: m_wingert, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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 22:09                   ` Jan D.
  0 siblings, 2 replies; 22+ messages in thread
From: David Kastrup @ 2006-01-03 18:37 UTC (permalink / raw)
  Cc: Jan D., m_wingert, emacs-devel

"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?

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.

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?

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  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.
  1 sibling, 2 replies; 22+ messages in thread
From: Timo Savola @ 2006-01-03 20:29 UTC (permalink / raw)
  Cc: JanD., rms, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-03 20:29                   ` Timo Savola
@ 2006-01-04  6:15                     ` Richard M. Stallman
  2006-01-04 22:11                     ` Jan D.
  1 sibling, 0 replies; 22+ messages in thread
From: Richard M. Stallman @ 2006-01-04  6:15 UTC (permalink / raw)
  Cc: jan.h.d, emacs-devel

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

Either the trunk, or the Unicode-2 branch, since we plan to merge that
in after the release.

But I think it would be better if you work from the trunk.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-03 18:37                 ` David Kastrup
  2006-01-03 20:29                   ` Timo Savola
@ 2006-01-04 22:09                   ` Jan D.
  2006-01-05  6:13                     ` Timo Savola
  1 sibling, 1 reply; 22+ messages in thread
From: Jan D. @ 2006-01-04 22:09 UTC (permalink / raw)
  Cc: m_wingert, rms, emacs-devel

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-03 20:29                   ` Timo Savola
  2006-01-04  6:15                     ` Richard M. Stallman
@ 2006-01-04 22:11                     ` Jan D.
  1 sibling, 0 replies; 22+ messages in thread
From: Jan D. @ 2006-01-04 22:11 UTC (permalink / raw)
  Cc: Emacs-Devel Devel


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

If you can #ifdef it with USE_GTK, I think it would be OK.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-04 22:09                   ` Jan D.
@ 2006-01-05  6:13                     ` Timo Savola
  2006-01-05 10:34                       ` Jan D.
  0 siblings, 1 reply; 22+ messages in thread
From: Timo Savola @ 2006-01-05  6:13 UTC (permalink / raw)
  Cc: emacs-devel

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

A weird thing about the GtkPlugged Emacs is that it seems to work
perfectly when some window managers (Ion) are used, but not that well
with others (Openbox, Metacity).  Perhaps this can be addressed in a
hand-written XEmbed 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.

I wonder if this is the case with the emacs-parent-fix.patch.  I don't
understand what the code was trying to do, unless it was simply buggy.

timo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: GtkPlug patch
  2006-01-05  6:13                     ` Timo Savola
@ 2006-01-05 10:34                       ` Jan D.
  0 siblings, 0 replies; 22+ messages in thread
From: Jan D. @ 2006-01-05 10:34 UTC (permalink / raw)
  Cc: emacs-devel

>
>> 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.
>
> I wonder if this is the case with the emacs-parent-fix.patch.  I don't
> understand what the code was trying to do, unless it was simply buggy.

It is a leftover from older versions.  The line your patch removes  
was the original line.  When the test for explicit parent was added,  
that line was not removed.  x_create_tip_frame also has two  
assignments to parent_desc.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2006-01-05 10:34 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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.
2006-01-05  6:13                     ` Timo Savola
2006-01-05 10:34                       ` Jan D.
2006-01-03 13:41 ` Lőrentey Károly

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).