Re: GtkGLExt (was Re: Gtk 3.0)
Emmanuele Bassi wrote: On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote: Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... I guess that you'll have to patch GtkGLExt, and submit patches for integration upstream. We're interested. We're currently planning what might go into the next GtkGLExt release. We probably need to have a discussion about whether there should be another release targeting Gtk+ 2.x. I'll open this up on the gtkglext-list shortly. 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. people flee from OpenGL in disgust, and it's just OpenGL 3.x that's making some progress towards fixing the insane API that it exposes - unfortunately, no GL implementation provides the 3.x API yet. For a lot of people using OpenGL (or various engines/wrappers like OpenSceneGraph and OGRE), there's no practical alternative to flee to. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. even if (and I'm saying *if*) GTK+ provided GL integration for GdkWindows it would basically boil down to two functions: void gdk_window_gl_begin (GdkWindow *window); void gdk_window_gl_end (GdkWindow *window); plus a way to set up the GL context. that's mostly agreed upon, if you read the bug that Javier linked in his email. that's not even close to the API exposed by GtkGLExt. This is certainly a conversation that I'm interested in having. We're certainly aware that there's a good deal of chaff in the GtkGLExt API needs culling. On the other hand, what you're describing isn't *that* far from the parts of GtkGLExt that people actually use. (Well, currently the API has users make_current and then do the begin/end stuff at the GL level.) But I'd like to get us a bit farther along in doing that paring down before discussing this in depth. -- Braden McDaniel e-mail: bra...@endoframe.com http://endoframe.com Jabber: bra...@jabber.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Crash processing g_object_new arguments
Does this backtrace suggest anything reasonably concrete to anyone here? #0 strchr () at ../sysdeps/x86_64/strchr.S:33 #1 0x003834814e1d in IA__g_param_spec_pool_lookup (pool=0x6cc500, param_name=0x7fff Address 0x7fff out of bounds, owner_type=140737085709488, walk_ancestors=1) at gparam.c:1053 #2 0x0038348122c7 in IA__g_object_new_valist (object_type=6785536, first_property_name=0x7fff Address 0x7fff out of bounds, var_args=0x7fffefa53250) at gobject.c:1287 #3 0x0038348126ac in IA__g_object_new (object_type=140737085709488, first_property_name=0x459479 control-host-proxy) at gobject.c:1060 #4 0x0044125b in openvrml_xembed_browser_new (host_proxy=0x7fffe8006870, expect_initial_stream=0, dbus_thread_context=0x73ab40, gtk_thread_context=0x6ea5c0, host_name=0x7fffe8007800 org.openvrml.BrowserHost-18834, socket_id=0) at .././../src/openvrml-xembed/browser.cpp:378 Clearly the Address ... out of bounds looks fishy; but I'm just not seeing what could be a problem there; and I'm wondering if gdb isn't just messing with me. The call site for openvrml_xembed_browser_new looks like this: OpenvrmlXembedBrowser * const browser = OPENVRML_XEMBED_BROWSER( g_object_new(OPENVRML_XEMBED_TYPE_BROWSER, control-host-proxy, host_proxy, control-host-name, host_name, dbus-thread-context, dbus_thread_context, expect-initial-stream, expect_initial_stream, 0)); This started happening when I added the construction parameter control-host-name; so I've been looking intently at my _class_init to see if I botched something in the parameter specs; but I'm just not seeing anything. That code looks like this: GParamSpec * pspec = g_param_spec_object( control-host-proxy, BrowserHost proxy, DBusGProxy for a BrowserHost, DBUS_TYPE_G_PROXY, GParamFlags(G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE)); g_object_class_install_property(g_object_class, control_host_proxy_id, pspec); pspec = g_param_spec_string( control-host-name, BrowserHost name, Well-known (nonunique) name for a BrowserHost, , GParamFlags(G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE)); g_object_class_install_property(g_object_class, control_host_name_id, pspec); pspec = g_param_spec_pointer( dbus-thread-context, D-Bus thread context, GMainContext for the D-Bus connection thread, GParamFlags(G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE)); g_object_class_install_property(g_object_class, dbus_thread_context_id, pspec); pspec = g_param_spec_boolean( expect-initial-stream, expect an initial stream, The VrmlControl will be delivered an initial stream, false, GParamFlags(G_PARAM_CONSTRUCT_ONLY | G_PARAM_WRITABLE)); g_object_class_install_property(g_object_class, expect_initial_stream_id, pspec); Clues appreciated. -- Braden McDaniel bra...@endoframe.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Crash processing g_object_new arguments
On Mon, 2009-11-09 at 09:32 +0100, Nicola Fontana wrote: Il giorno Mon, 09 Nov 2009 03:24:04 -0500 Braden McDaniel bra...@endoframe.com ha scritto: Clearly the Address ... out of bounds looks fishy; but I'm just not seeing what could be a problem there; and I'm wondering if gdb isn't just messing with me. The call site for openvrml_xembed_browser_new looks like this: OpenvrmlXembedBrowser * const browser = OPENVRML_XEMBED_BROWSER( g_object_new(OPENVRML_XEMBED_TYPE_BROWSER, control-host-proxy, host_proxy, control-host-name, host_name, dbus-thread-context, dbus_thread_context, expect-initial-stream, expect_initial_stream, 0)); Change 0 to NULL: on 64 bit platforms 0 != NULL, hence the property list is not terminated. Argh. Of course. 0L would presumably have worked fine--until the code was compiled on a platform where sizeof (long) != sizeof (void*). (Hence Murray's comment.) Thanks, folks. -- Braden McDaniel bra...@endoframe.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: trauma spliting source into multiple files and applying autotools
On Wed, 2009-07-22 at 12:41 +1000, Mick wrote: [snip] Now the source compiles but linking produces: gcc -Wall -g -O2 -export-dynamic -o nuchimp callback.o main.o callback.o: In function `on_panicbutton_clicked': As I mentioned in my initial message, you need to add $(GTK_LIBS) to AM_LDFLAGS. -- Braden McDaniel bra...@endoframe.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: trauma spliting source into multiple files and applying autotools
On Mon, 2009-07-20 at 11:22 +1000, Mick wrote: [snip] compiling with: gcc -Wall -g -o tutor main.c -export-dynamic `pkg-config --cflags --libs gtk+-2.0` produces an executable that runs just as expected. When I split the .c file into the main function as main.c and the 'callbacks' into callback.c and create the Makefile.am, configure.in, etc compilation runs without error and the exec runs but hangs after displaying: Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed on: gtk_widget_show(chat_window); You need to add -export-dynamic to AM_LDFLAGS in Makefile.am. A few more notes... configure.in The filename configure.ac is preferred for modern autoconf. code AC_PREREQ([2.63]) AC_INIT([nuchimp], [0.1], [cheifch...@myemail]) AM_INIT_AUTOMAKE([nuchimp], [0.1]) This is the old-style invocation of AM_INIT_AUTOMAKE. You don't need any arguments here. (You can provide a list of options as the argument instead; see the manual for details.) AC_PREFIX_DEFAULT([$HOME]) AC_CONFIG_SRCDIR([config.h.in]) AC_CONFIG_HEADERS([config.h]) # Checks for programs. AC_PROG_CC GTK_CFLAGS=$GTK_CFLAGS `pkg-config --cflags --libs gtk+-2.0` -export-dynamic CFLAGS= -g -O2 FYI, your use of -export-dynamic isn't getting applied because it winds up in INCLUDES, which are C preprocessor flags and thus not applied during linking. (Or maybe it's getting overwritten by your subsequent use of AM_PATH_GTK_2_0 before that can happen.) # Checks for libraries. AM_PATH_GTK_2_0(2.2.0,,AC_MSG_ERROR(BUMMER, I needs GTK+ 2.2.0)) Use PKG_CHECK_MODULES instead of this macro. See man pkg-config for more information; but this should be sufficient: PKG_CHECK_MODULES([GTK], [gtk+-2.0 = 2.2]) And you don't need to set GTK_CFLAGS explicitly. # Checks for header files. # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. AC_CONFIG_FILES([Makefile src/Makefile]) AC_OUTPUT /code Makefile.am code ## Process this file with automake to produce Makefile.in bin_PROGRAMS = nuchimp nuchimp_SOURCES = \ callback.c callback.h \ main.c main.h INCLUDES= @GTK_CFLAGS@ INCLUDES has been deprecated in favor of AM_CPPFLAGS. Also, you should generally prefer using the make variable rather than using the autoconf substitution directly (i.e., $(GTK_CFLAGS) instead of @GTK_CFLAGS@). The advantage of the former is that it can be overridden at make time (should that be convenient or necessary). LDADD = @GTK_LIBS@ You should use AM_LDFLAGS for this instead of LDADD. CLEANFILES = *~ As a matter of practice, I advise against having make clean remove files that are not the product of a make invocation. DISTCLEANFILES = .deps/*.P I don't know why this would be necessary. -- Braden McDaniel bra...@endoframe.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: trauma spliting source into multiple files and applying autotools
On Tue, 2009-07-21 at 12:20 +1000, Mick wrote: On Mon, 20 Jul 2009 12:17:32 -0400 Braden McDaniel bra...@endoframe.com wrote: On Mon, 2009-07-20 at 11:22 +1000, Mick wrote: [snip] compiling with: gcc -Wall -g -o tutor main.c -export-dynamic `pkg-config --cflags --libs gtk+-2.0` produces an executable that runs just as expected. When I split the .c file into the main function as main.c and the 'callbacks' into callback.c and create the Makefile.am, configure.in, etc compilation runs without error and the exec runs but hangs after displaying: Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed on: gtk_widget_show(chat_window); Thanks for your help and critique, I've taken your advice on board: You need to add -export-dynamic to AM_LDFLAGS in Makefile.am. src/Makefile.am code bin_PROGRAMS = nuchimp nuchimp_SOURCES = \ callback.c callback.h \ main.c main.h AM_CPPFLAGS $(GTK_CFLAGS) AM_LDFLAGS -export-dynamic You're missing some '=' signs here; e.g.: AM_CPPFLAGS = $(GTK_CFLAGS) That's probably the source of your error. I removed several paragraphs that defined install/uninstall after getting this error but it remains. Looking at Automake's output can be very educational; but unless you really know what you're doing, you probably shouldn't bother editing it. If the generated Makefile has errors, it's almost certainly because there were errors in the input. -- Braden McDaniel bra...@endoframe.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Why isn't my custom widget getting mapped?
On Tue, 2008-08-19 at 00:19 -0400, Braden McDaniel wrote: [snip] What might I have neglected to do (or unwittingly done) that would result in this? The problem here was that I thought GtkBin was doing more for me than it actually does and I wasn't overriding a few necessary functions. As it turns out I wasn't really benefiting from using the GtkBin at all. I switched to deriving from GtkSocket instead; it gets mapped just fine now. (The plug, unfortunately, still has issues.) -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Why isn't my custom widget getting mapped?
I have the following GtkBuilder XML: object class=GtkVBox id=vbox1 property name=visibleTrue/property child object class=GtkMenuBar constructor=uimanager1 id=menubar1 property name=visibleTrue/property /object packing property name=expandFalse/property /packing /child child object class=GtkHBox id=hbox1 property name=visibleTrue/property child object class=GtkEntry id=locationentry property name=visibleTrue/property signal handler=openvrml_player_on_locationentry_activated name=activate/ signal handler=locationentry_map_event name=map-event/ /object /child /object packing property name=expandFalse/property property name=position1/property /packing /child child object class=VrmlControlHost id=controlhost property name=visibleTrue/property property name=can-focusTrue/property property name=has-focusTrue/property signal handler=controlhost_map_event name=map-event/ /object packing property name=expandTrue/property property name=position2/property /packing /child child object class=GtkStatusbar id=statusbar1 property name=visibleTrue/property /object packing property name=expandFalse/property property name=position3/property /packing /child /object VrmlControlHost is a custom widget that is derived from GtkBin. For some reason, it doesn't seem to get mapped. It does get created and realized. But I don't see it. And while the locationentry_map_event function attached to the locationentry widget does get called, the controlhost_map_event function similarly attached to controlhost never gets called. What might I have neglected to do (or unwittingly done) that would result in this? -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Custom widgets with GtkBuilder
I'm migrating some code from libglade to GtkBuilder.
I have inherited GtkFileChooserDialog in order to perform some setup
when creating it (i.e., set title, set the default response, and add
some filters). With libglade, I was performing this logic in a _new
function; I delegated to the _new function in the callback supplied to
glade_register_widget.
When migrating to GtkBuilder, I didn't find an equivalent of
glade_register_widget. I concluded that GtkBuilder must simply use
g_object_new and decided that the most convenient way to do the
initialization I want to do would be to move it to the _init function.
That function now looks like this:
void
openvrml_player_file_chooser_dialog_init(
OpenvrmlPlayerFileChooserDialog * dialog)
{
gtk_dialog_add_buttons(GTK_DIALOG(dialog),
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_dialog_set_default_response(GTK_DIALOG(dialog),
GTK_RESPONSE_ACCEPT);
GtkFileFilter * const world_filter = gtk_file_filter_new();
g_return_if_fail(world_filter);
scope_guard world_filter_guard = make_guard(g_object_unref,
world_filter);
boost::ignore_unused_variable_warning(world_filter_guard);
gtk_file_filter_set_name(world_filter, VRML/X3D worlds);
gtk_file_filter_add_mime_type(world_filter, x-world/x-vrml);
gtk_file_filter_add_mime_type(world_filter, model/vrml);
gtk_file_filter_add_mime_type(world_filter, model/x3d+vrml);
gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dialog), world_filter);
world_filter_guard.dismiss();
GtkFileFilter * const all_filter = gtk_file_filter_new();
g_return_if_fail(all_filter);
scope_guard all_filter_guard = make_guard(g_object_unref,
all_filter);
boost::ignore_unused_variable_warning(all_filter_guard);
gtk_file_filter_set_name(all_filter, All files);
gtk_file_filter_add_pattern(all_filter, *);
gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dialog), all_filter);
all_filter_guard.dismiss();
}
But since moving the code and having GtkBuilder create the widget, I'm
now getting these assertion failures:
(openvrml-player:25152): Gtk-CRITICAL **: gtk_file_chooser_add_filter:
assertion `GTK_IS_FILE_CHOOSER (chooser)' failed
(openvrml-player:25152): Gtk-CRITICAL **: gtk_file_chooser_add_filter:
assertion `GTK_IS_FILE_CHOOSER (chooser)' failed
I have a feeling that I've overlooked something and GtkBuilder isn't
creating the widget correctly; any ideas?
--
Braden McDaniel e-mail: [EMAIL PROTECTED]
http://endoframe.comJabber: [EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFileChooserDialog: response from Location
On Wed, 2007-02-07 at 20:56 -0500, Braden McDaniel wrote: It seems that--by default, at least--pressing Enter in the Location entry of a GtkFileChooserDialog does not constitute a response (that is, it does not close the dialog). Can this be changed? Or can it be fudged? Nevermind. I just needed to do: gtk_dialog_set_default_response(GTK_DIALOG(file_chooser_dialog), GTK_RESPONSE_ACCEPT); -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Attaching an event source to a GMainLoop in a thread
I have a GMainLoop that I want to run in its own thread. But I seem to b
doing something horribly wrong with the event source I'm trying to
attach to it (all as part of the same thread). My thread function
includes this code:
GMainContext * main_context = g_main_context_new();
GMainLoop * main_loop = g_main_loop_new(main_context, false);
GSource * quit = g_idle_source_new();
g_source_set_callback(quit,
::openvrml_player_command_channel_loop_quit_event,
main_loop,
notify);
guint source_id = g_source_attach(quit, main_context);
g_assert(source_id != 0);
g_main_loop_run(main_loop);
g_source_unref(quit);
g_main_loop_unref(main_loop);
g_main_context_unref(main_context);
If I do not attach the event source, the code runs. But if I do attach
it, as above, I crash as soon as I start to run the main loop:
#0 0x in ?? ()
#1 0x003c9242cf6a in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#2 0x003c9242fd7d in g_main_context_check () from
/lib64/libglib-2.0.so.0
#3 0x003c9243008a in g_main_loop_run () from
/lib64/libglib-2.0.so.0
#4 0x0040b02d in operator() (this=0x6bec30) at
../.././../src/openvrml-gtkplug/main.cpp:322
#5 0x0040b099 in invoke (function_obj_ptr={obj_ptr = 0x6bec30,
const_obj_ptr = 0x6bec30, func_ptr = 0x6bec30, data = 0}) at
/usr/include/boost/function/function_template.hpp:136
#6 0x2c923d4f in boost::function0void,
std::allocatorboost::function_base ::operator() () from
/usr/lib64/libboost_thread.so.2
#7 0x2c9238df in boost::thread_group::add_thread () from
/usr/lib64/libboost_thread.so.2
#8 0x003c90006305 in start_thread () from /lib64/libpthread.so.0
#9 0x003c8f4cd62d in clone () from /lib64/libc.so.6
#10 0x in ?? ()
I figure I'm probably missing something about the proper way to attach
the event source, perhaps related to the fact that I'm not doing this in
the main thread.
--
Braden McDaniel e-mail: [EMAIL PROTECTED]
http://endoframe.comJabber: [EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Attaching an event source to a GMainLoop in a thread
On Sun, 2006-12-03 at 19:05 +, Chris Vine wrote:
On Sunday 03 December 2006 10:26, Braden McDaniel wrote:
I have a GMainLoop that I want to run in its own thread. But I seem to b
doing something horribly wrong with the event source I'm trying to
attach to it (all as part of the same thread). My thread function
includes this code:
GMainContext * main_context = g_main_context_new();
GMainLoop * main_loop = g_main_loop_new(main_context, false);
GSource * quit = g_idle_source_new();
g_source_set_callback(quit,
::openvrml_player_command_channel_loop_quit_event,
main_loop,
notify);
guint source_id = g_source_attach(quit, main_context);
g_assert(source_id != 0);
g_main_loop_run(main_loop);
g_source_unref(quit);
g_main_loop_unref(main_loop);
g_main_context_unref(main_context);
If I do not attach the event source, the code runs. But if I do attach
it, as above, I crash as soon as I start to run the main loop:
Wouldn't unreferencing main_context cause it to be freed? (And does
g_main_loop_run() increement the reference count of main_loop? If not then
unreferencing main_loop that will also destroy the main loop). The call to
g_source_unref() is correct (g_source_attach will increment the reference
count of quit).
I'm not getting past the call to g_main_loop_run, so the *_unref calls
aren't the problem.
I've gotten closer to the problem; but it's just mysteriouser.
The callback looks like this:
gboolean openvrml_player_command_channel_loop_quit_event(const gpointer
data)
{
GMainLoop * const main_loop = static_castGMainLoop *(data);
if (::quit_flag.value()) {
g_main_loop_quit(main_loop);
return false;
}
return true;
}
quit_flag is just a boolean flag protected by a mutex:
class flag : boost::noncopyable {
mutable boost::mutex mutex_;
bool value_;
public:
flag(bool init = false);
bool value() const;
void value(bool val);
};
It appears that the core dump happens in the first call to
openvrml_player_command_channel_loop_quit_event. But here things get
murky because the problem seems to be very timing-sensitive. If I put a
print statement at the beginning of
openvrml_player_command_channel_loop_quit_event, it starts working. And
if I instead put a print statement at the beginning of flag::value(), it
starts working.
This points, I think, to something being wrong with the state of
quit_flag at the time I try to use it in
openvrml_player_command_channel_loop_quit_event--like it's not fully
initialized. Though I don't understand why that would be the case--my
thread is being started from main() quit_flag is a global variable (in
the same translation unit as main()).
I'll continue to experiment.
--
Braden McDaniel e-mail: [EMAIL PROTECTED]
http://endoframe.comJabber: [EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Calling g_main_loop_quit from another thread
Is it safe to call g_main_loop_quit from another thread? I have a GMainLoop that is watching a GIOChannel for input in a thread. I am trying to end this thread by calling g_main_loop_quit from a different thread. But when I do this, the thread running the GMainLoop deadlocks in a call to poll from g_main_context_check. My workaround for the moment has been to add an idle callback that checks a boolean flag to the thread running the GMainLoop and call g_main_loop_quit in the callback function. Though this is rather annoying; particularly considering calling gtk_main_quit from another thread seems to work fine. Is there some way to get the call to g_main_loop_quit from another thread to work? -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Callback on GIOChannel shutdown?
On Mon, 2006-01-16 at 10:13 +0200, Tor Lillqvist wrote: Braden McDaniel writes: I expected the callback associated with this watch to be called after I shut down data.command_channel with g_io_channel_shutdown; however, that doesn't appear to be the case. You misunderstood what G_IO_HUP means. Indeed I did. Thanks for the explanation. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Callback on GIOChannel shutdown?
I've created a GIOChannel watch like this: GSource * const command_watch = g_io_create_watch(data.command_channel, GIOCondition(G_IO_IN | G_IO_HUP)); I expected the callback associated with this watch to be called after I shut down data.command_channel with g_io_channel_shutdown; however, that doesn't appear to be the case. Is there some other way I can receive notification that the channel has been shut down? -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
