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