Community
Participate
Working Groups
Build Identifier: 3.6.1.v3655c Currently it'd seem that GtkSocket's "plug-added" and "plug-removed" signals are not listened to; according to documentation [1] this leads to GtkWidget being destroyed when the client exists BEFORE the composite instance is disposed. 1 = http://developer.gnome.org/gtk/unstable/GtkSocket.html#GtkSocket-plug-removed A simple signal handler returning true would allow reusing the composite (and keep everything in sync). Currently if a client exists/dies before Composite being disposed and the shell is closed, message is printed to STDERR: (SWT:32606): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed Which is most likely cause of GtkWidget being destroyed and no-one actually listening for the fact. I guess this could be "easily" danced around by managing the external process from Java (I bet many have this in production) and simply disposing the composite after process has been told to exit, creating a new one if re-use is wanted. Filing this as a bug because it's nowhere documented that Composite w/ EMBEDDABLE is single-use. Best solution would be to provide SWT event for all client joins (on Windows I think there's an event if a Window is parented under our EMBEDDABLE) and parts but I'll file another one on that when I know more of same kind of win32 events. Reproducible: Always Steps to Reproduce: 1.Create simple app to provide Composite embeddableComposite with SWT.EMBEDDABLE 2.Get embeddableComposite.embeddableHandle, launch vlc -I dummy --drawable-xid ${embeddableHandle} <video-file> 3.Watch video, exit vlc (CTRL-C) 4.Close shell 5.Read STDERR for the assertion failure
I've tried to peek at the requirements for implementation: * os.h function: GTK_TYPE_SOCKET * OS.java signal constants: byte[] plug_added, plug_removed * Widget.java signal constants: PLUG_ADDED, PLUG_REMOVED * Widget.java increment Widget.LAST_SIGNAL to accomodate the two more sigs * Widget.java translate PLUG_ADDED, PLUG_REMOVED in windowProc(long,long) to new methods gtk_plug_added and gtk_plug_removed * Display.java closures for the signals, methods for closures * Composite.java override gtk_plug_removed to return GTK true (int=1) if embedded Could this be all? Altough Widget might be wrong place for PLUG_ADDED, PLUG_REMOVED as these are not signals of GtkWidget but GtkSocket; is there another common place for such signals?
Having just tested on Windows, if one should embed an app (for example VLC) on a surface it can be done any number of times without any SWT interference.
(In reply to comment #1) > I've tried to peek at the requirements for implementation: > * os.h function: GTK_TYPE_SOCKET > * OS.java signal constants: byte[] plug_added, plug_removed > * Widget.java signal constants: PLUG_ADDED, PLUG_REMOVED > * Widget.java increment Widget.LAST_SIGNAL to accomodate the two more sigs > * Widget.java translate PLUG_ADDED, PLUG_REMOVED in windowProc(long,long) to > new methods gtk_plug_added and gtk_plug_removed > * Display.java closures for the signals, methods for closures > * Composite.java override gtk_plug_removed to return GTK true (int=1) if > embedded > > Could this be all? Altough Widget might be wrong place for PLUG_ADDED, > PLUG_REMOVED as these are not signals of GtkWidget but GtkSocket; is there > another common place for such signals? Widget is the right place to put those constants? Please attach a patch and I will review it. Thanks!
I see there was some discussion on this back in 2011, but that nothing seems to have come of the problem. This problem is affecting my project and I'm wondering if any progress has been made. Thanks. Jim
(In reply to Jim Mayer from comment #4) > I see there was some discussion on this back in 2011, but that nothing seems > to have come of the problem. > > This problem is affecting my project and I'm wondering if any progress has > been made. Hi Jim, I did do some preliminary analysis but as we later decided to deploy only on Windows we never needed this implemented. Also I've personally been out of Java/SWT related application development for some time now. I think what I gathered in the comment #1 should still be valid, however the latest GTK versions might have move stuff around. It might even be that this feature has partially been implemented already -- I haven't checked. From what I understood implementing this shouldn't be too complicated, however there were some SWT building related issues back in the day.. Hopefully it's simpler today or at least more documented :)
Thanks Joonas, I'm using the SWT version from the Kepler Eclipse release on a Fedora 20 system, and neither the SWT nor the GTK+ behavior appears to have changed. It's still the case that GTK+ destroys the socket unless the PLUG_REMOVED handler returns true. From an SWT API perspective, the two problems I see are: (1) There's no way find out when the plug has been removed. (2) There's no option to keep the socket open when a plug has been removed. Jim
Is this still reproducible?
Hello there. Sorry, I haven't been paying much attention to this issue after I quickly worked around it way back when. I never managed to understand how to implement this in SWT, and failed to find any mentorship at the time. From what I've documented here, this was just a case of missing feature. What I can remember from this issue I would expect the reproduction guide to still be accurate. Unrelated to this issue I no longer do anything with SWT.
Re-assigning to the default assignee in case anyone wants to work on this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
