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, Nov 09, 2009 at 03:24:04AM -0500, Braden McDaniel wrote: 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)); 0 is not NULL. 0 has the size of int while NULL has the size of void*. Matters a lot in vararg list. Yeti ___ 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
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. Ciao. -- Nicola ___ 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. And if you are compiling as C++, don't use NULL (ever) either, because it has a different meaning in C++ . Use (void*)0. -- murr...@murrayc.com www.murrayc.com www.openismus.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: Change 0 to NULL: on 64 bit platforms 0 != NULL, hence the property list is not terminated. Even better, in C, is to use (void *)0 or (void *)NULL, since in C it is acceptable for NULL to be #defined as 0, even though that tends to make people angry when they encounter situations like this. (I don't know enough C++ to say what the situation is there.) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Control what happens when GtkTextView is resized: keep the bottom part visible
I have a question concerning how to set which part of a GtkTextBuffer is
displayed when a GtkTextView is resized.
To explain the situation, consider this sample code:
8
/* gcc -o tvtest tvtest.c `pkg-config --libs --cflags gtk+-2.0` */
#include gtk/gtk.h
int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *vpaned;
GtkWidget *text1;
GtkWidget *scr1;
GtkTextBuffer *buffer;
GtkWidget *text2;
GtkWidget *scr2;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request(window, 500, 300);
g_signal_connect(G_OBJECT(window), delete-event,
G_CALLBACK(gtk_main_quit), NULL);
vpaned = gtk_vpaned_new();
text1 = gtk_text_view_new();
buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(text1));
gtk_text_buffer_set_text(buffer,
Lorem ipsum dolor sit amet,\n
consectetur adipisicing elit,\n
sed do eiusmod tempor incididunt\n
ut labore et dolore magna aliqua.\n
Ut enim ad minim veniam,\n
quis nostrud exercitation ullamco laboris\n
nisi ut aliquip ex ea commodo consequat.\n
Duis aute irure dolor in reprehenderit\n
in voluptate velit esse cillum dolore\n
eu fugiat nulla pariatur.\n
Excepteur sint occaecat cupidatat non
proident,\n
sunt in culpa qui officia\n
deserunt mollit anim id est laborum., -1);
text2 = gtk_text_view_new_with_buffer(buffer);
scr1 = gtk_scrolled_window_new(NULL, NULL);
gtk_container_add(GTK_CONTAINER(scr1), text1);
gtk_paned_add1(GTK_PANED(vpaned), scr1);
scr2 = gtk_scrolled_window_new(NULL, NULL);
gtk_container_add(GTK_CONTAINER(scr2), text2);
gtk_paned_add2(GTK_PANED(vpaned), scr2);
gtk_container_add(GTK_CONTAINER(window), vpaned);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
8
When the division in the GtkPaned is moved, what happens is that the top
of the GtkTextViews remains the same (thus keeps displaying the same
thing), while the bottom part shrinks, hiding some text at the bottom if
the widget gets smaller, or displaying more text at the bottom if it is
enlarged.
What I would like to do is the opposite: for the GtkTextView in the
bottom, I'd like that the bottom of the widget remains the same, but
changes in size are reflected at the top: if the widget shrinks, then
less text at the top should be displayed, if it grows, then more text at
the top should be displayed. The bottom should remain fixed displaying
always the same part.
Another way to visualize is that by changing the division in the
GtkPaned it should cover more of the top of the bottom GtkTextView,
instead of pushing it down.
Does anyone have a solution for that?
--
Money is truthful. If a man speaks of his honor, make him pay cash.
-- Lazarus Long
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: adding transparency to Gtk widgets
Hi Ce, Thanks for your help. It is working fine. Now i could able to display my application with transparancy support. But is there any way to add this into gtkrc file. I mean some thing like alpha =0.6 so that for all the applications the alpha value will be 0.6. and all the applications will be transparent. so that explicitly we need not to supply the alpha value programmatically. I try to put alpha = 0.6 in my gtkrc file inside style default structure. But it is not working. If you can provide me some input inthis regard it will be helpful. Thank you, Regards, Hvr On Sat, Nov 7, 2009 at 4:50 AM, cet cet xni...@yahoo.com wrote: Check out the link below; http://mikehearn.wordpress.com/2006/03/26/gtk-windows-with-alpha-channels/ --- On Fri, 11/6/09, harshavardhanreddy mandeepala hvreddy1...@gmail.com wrote: From: harshavardhanreddy mandeepala hvreddy1...@gmail.com Subject: Re: adding transparency to Gtk widgets To: gtk-app-devel-list@gnome.org Date: Friday, November 6, 2009, 4:08 AM Hi Friends, Any ideas on this? Any suggestions are welcome. Harsha On Wed, Nov 4, 2009 at 7:09 PM, harshavardhanreddy mandeepala hvreddy1...@gmail.com wrote: Hi, Is there any way to make Gtk widgets transparent. By using Murrine theme engine and little modifications to my gtk application i could do. In my application I added the following lines For my main window/widget i did the fallowing( as per Cimi's update). /*** screen = gtk_widget_get_screen (totem-win); colormap = gdk_screen_get_rgba_colormap (screen); if (colormap) gtk_widget_set_default_colormap (colormap); **/ It's working fine. But If I don't use murrine theme engine the effect(transparancy/glassy) will not be seen. I don't want to use murrine theme engine. Instead i want to modify in Gtk library. Is there any update on this. Thanks in advance. Regards, HVR ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ 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
David Nečas wrote: On Mon, Nov 09, 2009 at 03:24:04AM -0500, Braden McDaniel wrote: 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)); 0 is not NULL. 0 has the size of int while NULL has the size of void*. Matters a lot in vararg list. This requires clarification. 0 *is* NULL, in pointer contexts. In fact, some compilers define NULL using #define NULL 0 So using NULL instead of 0, by itself, won't necessarily address the problem, although it will if the definition happens to be #define NULL (void *)0 The problem is that this particular NULL appears in the arguments of a function that accepts a variable number of arguments. The compiler therefore doesn't know that any particular argument is a pointer and can't perform the proper type conversion. Arguably, the real problem is the design of g_object_new(), and another way to avoid it is the use of g_object_newv(). - Ernie ___ 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
I've never come across this problem since I've never used any headers that re-define NULL, nor have I used gobject with C++, but it seems like enough of a gotcha that it might make sense to define another constant (G_ARG_TERM?) that always maps to (void *) and use that with all the glib functions that expect a (void *) to terminate the argument list. -Jim On Mon, Nov 9, 2009 at 8:17 AM, ern...@comcast.net wrote: David Nečas wrote: On Mon, Nov 09, 2009 at 03:24:04AM -0500, Braden McDaniel wrote: 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)); 0 is not NULL. 0 has the size of int while NULL has the size of void*. Matters a lot in vararg list. This requires clarification. 0 *is* NULL, in pointer contexts. In fact, some compilers define NULL using #define NULL 0 So using NULL instead of 0, by itself, won't necessarily address the problem, although it will if the definition happens to be #define NULL (void *)0 The problem is that this particular NULL appears in the arguments of a function that accepts a variable number of arguments. The compiler therefore doesn't know that any particular argument is a pointer and can't perform the proper type conversion. Arguably, the real problem is the design of g_object_new(), and another way to avoid it is the use of g_object_newv(). - Ernie ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ 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, Nov 09, 2009 at 03:17:24PM +, ern...@comcast.net wrote: 0 *is* NULL, in pointer contexts. In fact, some compilers define NULL using #define NULL 0 So using NULL instead of 0, by itself, won't necessarily address the problem, although it will if the definition happens to be #define NULL (void *)0 The problem is that this particular NULL appears in the arguments of a function that accepts a variable number of arguments. The compiler therefore doesn't know that any particular argument is a pointer and can't perform the proper type conversion. Technically, you are right (show me a modern system that defines NULL as plain 0 though). The C++ people were trying to pretend 0 is a good substitute for null pointer for years and now they introduce nullptr (wonder, wonder) because it isn't and it only led to troubles. I expect the (or some) next C standard to require NULL to evaluate to something pointer-sized and disallow #define NULL 0 Arguably, the real problem is the design of g_object_new(), and another way to avoid it is the use of g_object_newv(). While g_object_newv() is better and I typically use it, NULL termination is a pretty standard and nice vararg idiom. The real problem is `pointers are integers' from the dark times of C. Without that everyone would see the need for distinguishing between 0 and null pointer and #define NULL 0 would be immediately seen as broken. Yeti ___ 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
David Nečas wrote: The real problem is `pointers are integers' from the dark times of C. BCPL created many positive influences but this wasn't its finest feature. At least as seen with the benefit of hindsight! Cheers, Dave ___ 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: Unsubscribe
Am Mon, 9 Nov 2009 03:28:57 -0800 schrieb Shashidhara B shashidhar...@mphasis.com: Hi, Kindly unsubscribe from the mailing list. Regards, Shashi Please use http://mail.gnome.org/mailman/listinfo/gtk-devel-list like everyone else to unsubscribe yourself. You managed to subscribe on your own as well, didn't you? Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:23 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: Obviously some could could be shared, but a straight dependency on libgio isn't necessary. Eh, some code could be shared is what i meant. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of unimportant document files. Thats obviously nice to have, but not as important as reliable compression support. Could this be used by libsoup for websites that zlib-compress their data? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus API Questions; was: GDBus/GVariant plans for next GLib release
Hey Mikkel, Sorry for not replying sooner! On Wed, 2009-10-28 at 21:23 +0100, Mikkel Kamstrup Erlandsen wrote: Attached is a series of patches (0001 should be identical to my previous) implementing what you describe, except adding the gboolean enumerated arg to @introspect and @dispatch. I will get around to that. Yeah, on second thought, it's probably best to skip that. The failing unit tests I described was really just me b0rking up the linking between some installed gdbus components and my devel version. I have them running now[1] and I added some testing for the dynamic objects as well (see 0003). Some more tests to go with the other patches attached. And of course the attachment :-S This looks great, thanks for working on it and for writing unit tests too. I've committed the patches with a small patch for white-space / style fixes on top! Thanks, David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
Hey Ryan,
Sorry for the lag,
On Sat, 2009-10-31 at 17:27 -0400, Ryan Lortie wrote:
On Tue, 2009-10-20 at 11:17 -0400, David Zeuthen wrote:
So how about something like 1. and 2. below? We'd put
g_dbus_connection_get_handle_for_unix_fd()
g_dbus_connection_set_handle_for_unix_fd()
I was actually thinking that we could introduce a GDBusFDSet:
gint g_dbus_fd_set_add_fd (gint fd) {
list_of_fds[fd_count] = dup (fd);
return fd_count++;
}
gint g_dbus_fd_set_get_fd (gint index) {
return dup (list_of_fds[index]);
}
g_dbus_fd_set_finalize () {
foreach (fd in list_of_fds) close (fd);
}
You'd add fds to that and get ints back (starting at 0 per the set).
Then when sending the dbus message you'd give the GVariant and the
DBusFDSet to the appropriate function.
var fd = open(file);
var fdset = new FDSet ();
var message = new GVariant ((sh),
hello world,
fdset.add_fd (fd));
g_dbus_proxy_invoke_with_fds (proxy, Foo, message, fdset, ...);
When receiving messages, you get a DBusFDSet handed to you in the event
that there were file descriptors (or just %NULL in case not).
The fds held in the GDBusFDSet are closed when the set is finalized.
There is no doubt about who owns which fd in this case -- and in the
case you elect to ignore fds that were sent to you then everything is
still cleaned up properly.
Hmm, I don't like this approach. It means you'd have to pass this
GDBusFDSet object around in code you use to build/parse the GVariant. In
particular, your proposed GTypeSerializer would need support for it.
That's problematic because that one lives in libgobject, not libgio
(where GDBusFDSet would live).
I still think the approach I described works better.
For example, suppose I have a C type mapping that maps a{sh} to a
GHashTable from strings to gint. I'd like to write code like this
my_hash = g_hash_table_new (g_str_hash, g_str_equal);
g_hash_table_insert (my_hash,
fd-for-client,
GINT_TO_POINTER (fd_for_client));
/* need to keep fd_for_client alive until we hand off the hash */
other code
foo_bar_invoke_process_client (proxy, my_hash, async stuff);
g_hash_table_unref (my_hash);
/* it's now safe to close the fd, the dbus stuff has already dupped
* it... note that we could have just used a GDestroyNotify for the
* values in my_hash to do this.
*/
close (fd_for_client);
where the latter function represents a generated function for the
ProcessClient() method on the foo.Bar interface that takes a single
a{sh} parameter represented by a GHashTable.
On the receiving end it would look like this. Suppose the GimmeFds
function returns a a{sh}:
my_hash = foo_bar_invoke_gimme_fds_sync (proxy, cancelable, error);
fd = GPOINTER_TO_INT (g_hash_table_lookup (my_hash, stream1));
if (fd 0)
{
fd_for_stream1 = dup (fd);
}
/* the value destroy notifier on my_hash closes all fds */
g_hash_table_unref (my_hash);
now use fd_for_stream1 and close it when done
Thoughts?
Thanks,
David
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus/GVariant plans for next GLib release
Hey Alex, On Fri, 2009-11-06 at 21:05 +0100, Alexander Larsson wrote: On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote: http://cgit.freedesktop.org/~david/gdbus-standalone/ I just read through this for basic review, and I must say that I like it. Very nice stuff. Some comments: Thanks for reading through it! In nautilus I'd like to have an object path which is basically a pointer to another object. Say I have these objects: /nautilus/window/1/tabs/1/view /nautilus/window/1/tabs/2/view Then i want something like: /nautilus/window/1/active_view That always points to the view object in the active tab. Now, i could constantly be re-creating this object all the time, but thats not really very nice. What i instead want to do is basically register a subtree at /nautilus/window/1/active_view which dynamically looks up which tab is active and then re-routes to the right tab. To implement this cleanly I would need to be able to lookup an object at a given path (returning the ifaces, vtables and user data) and to enumerate the children of a given path. All this would be in-client registered objects/subtrees only, and is enough to implement GDBusSubtreeVTable for the pointer subtree. Yeah, I guess that's a reasonable thing to add. How about? gboolean g_dbus_connection_lookup_object (GDBusConnection *connection, const gchar *object_path, const gchar *interface_name, GDBusInterfaceInfo **out_introspection_data, GDBusInterfaceVTable **out_vtable, gpointer *out_user_data, guint *out_id); gboolean g_dbus_connection_lookup_subtree (GDBusConnection *connection, const gchar *object_path, GDBusInterfaceVTable **out_vtable, GDBusSubtreeFlags *out_flags, gpointer *out_user_data, guint *out_id); I don't see any call to dbus_threads_init() or dbus_threads_init_default(). Surely this should be done if gthread is enabled. Ideally in g_thread_init_glib(), but thats a bit hard for something in libgio... Yeah, oops, good point - I guess we should do this in gdbusconnection.c I'd like it to be possible to specify a non-default main context when creating a connection with g_dbus_connection_new() or g_dbus_connection_bus_get_private(). Hmm, yeah, I was thinking about that. It's for specifying the mainloop for processing D-Bus messages, right? I was actually thinking that it might be nicer to always have a dedicated thread for handling D-Bus messages. This would be shared by all connections and it would just pop messages to the mainloops for method invocations and signals. This is feasible even if g_thread_init() has not be called, we'd just use libpthread directly (which libdbus-1 pulls in already). g_dbus_connection_send_dbus_1_message_with_reply() has a race condition if called on a thread other than the one dispatching the reply. The pending call may be completed before dbus_pending_call_set_notify() is reached. See _g_dbus_connection_call_async in gvfs/common/gdbusutils.c for a possible workaround. Will do. The way e.g. properties are implemented is very static. There is no way to expose an object with a dynamic set of properties (apart from removing and re-adding the object with new introspection data each time dynamic properties/methods can't be implemented? (lazy, i.e. not remove and re-add each time they change). I guess this is sort of weird wrt how dbus usually works, but might be useful when exporting an object from a more dynamic language like javascript or python. Hmm, yeah, but remember that D-Bus properties (like GObject properties) is part of the actual type - e.g. they are declared in introspection data. So it would be very weird to have dynamic properties, it would be similar to having dynamic properties on GObject. If you want dynamic properties it's much better to just define your own interfaces/methods for this (like e.g. HAL does). Maybe we should not claim to implement org.freedesktop.DBus.Properties if set/get_property are NULL? Yeah, probably not. I'm not sure if I missed it, because i didn't try it out, but how do registered object with a a child that is specified by registering a subtree get enumerated when introspecting the registered object? I'm not sure I understand this question - can you clarify? The foo_bar_error_quark example in gdbuserror.c clearly should just call a standard helper that does all this, just given the pointer to an array of data. Yeah, I guess we can add some convenience for that. org.gtk.GDBus.UnmappedGError.Quark0xHEXENCODED_QUARK_NAME_.Code_ERROR_CODE Why use a hex encoding for the quark name? Most gerror quark names are quite
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 12:23 PM, Alexander Larsson al...@redhat.com wrote: On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson al...@redhat.com wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps already pull this in, however there could be non-gtk+ using glib apps that now get an additional dependency. Its a very small (74K .so) and very widely availible/used library though, so I don't think this is a huge deal. Anyone who thinks this is a bad idea? Well - as I already said earlier, I think GIO - in the long run - has a potential of becomming *the* free desktop API for file-management. Simply because it's design is modern, universal and reminiscent of IO APIs, which people already know from other programming languages (i.e. Java). And it's sitting very low in the stack. Such an API is hard to design and takes long to consolidate. I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. Just like Qt contains all that Qt developers want/need. We will never artificially limit our platform just because of cross-desktop compatibility. And additionally, I don't see GIO as the thing that should really be shared between glib and Qt, but rather GVFS. I'd much rather see some cooperation between the gvfs and Qt people to stabilize the gvfs protocols such that Qt could directly talk to gvfs mounts. Obviously some could could be shared, but a straight dependency on libgio isn't necessary. Hmm... I don't really understand the neccessity to rewrite the entire GVFS client in Qt/C++. All the other programming languages use bindings, therefore why should Qt/C++ be different? * While writing a pure Qt/C++ client would certainly be possible (apart from the issue with the UriMappers), it would be a huge effort. * With one disadvantage: Standardizing all the D-Bus mechanics inside GVFS would probably make it harder to move forward. My feeling is that it's always the best approach to define the stable public interface at the narrowest part of the chain. Which not neccessarily has to be the IPC part. * Just compare this to libdbus: The IPC protocol is standardized, but almost everyone uses the libdbus as the real interface. * libGIO is an important part of the Gtk development stack. Yes, but - at least at the moment - it doesn't carry a lot of things in it, which are Gnome/Gtk specific. Most of the things are either the implementation of freedesktop-standards, or GVFS related. So it just looks like the all you need for file-management API, I just can't help it. And in my opinion it's a really cool one. Sorry, Alexander, that i'm asking to put a different label on it. I think GIO deserves to be more than a detail in the Gtk stack. :-) * I think if GIO/GVFS can pull Qt and KDE into their boat, this would be an important signal for all the 3rd party applications to link a proper VFS interface. Because at the moment many of them won't, as this implies deciding for a certain desktop environment. * Hopefully, one day people will realize, that KDE, Gnome and Qt are kind of living in the same appartment. There is no way to escape from that - independence is a dream. For one simple reason: applications, applications, applications. They are the most important desktop feature, the primary reason to buy a computer. So what's the point of having all the infrastructure duplicated: The toaster, the dish-washer, the washing-machine... ;-) This duplication just causes an enormous amount of chaos. However, i think a pure Qt implementation of GVFS would definitely be a very important move into the right direction. Cheers, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On 11/09/2009 07:53 AM, Bastien Nocera wrote: Could this be used by libsoup for websites that zlib-compress their data? It could (and eventually would), but passing data to zlib isn't the hard part of the problem there. (And this will actually be working in libsoup in 2.28.2.) -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of unimportant document files. Thats obviously nice to have, but not as important as reliable compression support. That sounds fair. Right now, Yelp will happily build without bzip2 and lzma support if you don't have them. I consider it a distro problem: if distros want to ship man and info pages compressed with bzip2 or lzma, then they need to make sure their Yelp is built right. I have no problems pushing that policy decision lower. How do you envision the optional extra support being provided? Would there be extension points that GVFS could plug into? Or compile-time optional modules like the GdkPixbuf loaders? Or would applications be expected to provide the extra juice? I'm willing to do the grunt work to add these. It's work I'd have to do in Yelp anyway to fully transition to GIO. Thanks for tackling the hard part of the problem. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
On Mon, 2009-11-09 at 08:21 -0500, David Zeuthen wrote:
Sorry for the lag,
No problems :)
Hmm, I don't like this approach. It means you'd have to pass this
GDBusFDSet object around in code you use to build/parse the GVariant. In
particular, your proposed GTypeSerializer would need support for it.
That's problematic because that one lives in libgobject, not libgio
(where GDBusFDSet would live).
I disagree. I'd actually like to keep support for file descriptors out
of the type serialiser entirely. It's just a little bit too magic for
my tastes.
A file descriptor is not normally considered to be a serialisable
object.
I still think the approach I described works better.
For example, suppose I have a C type mapping that maps a{sh} to a
GHashTable from strings to gint. I'd like to write code like this
my_hash = g_hash_table_new (g_str_hash, g_str_equal);
g_hash_table_insert (my_hash,
fd-for-client,
GINT_TO_POINTER (fd_for_client));
/* need to keep fd_for_client alive until we hand off the hash */
This, for example, is *way* too magic. I can't ever think of a case
where I store fds in hash tables, much less want to send a hash table
full of fds over DBus.
{
fd_for_stream1 = dup (fd);
}
/* the value destroy notifier on my_hash closes all fds */
g_hash_table_unref (my_hash);
I agree with the general idea of file descriptor ownership you expose
here. Does that imply that if you send a single file descriptor over
DBus to a handler function that takes an 'int' then you'll have to
close() the fd in the same way as you're responsible to free the hash
table?
Thoughts?
In general, I think that sending file descriptors over DBus is done
sufficiently rarely that it is not worth it to have support for it *this
deeply* integrated. In particular, I think that it's definitely not
appropriate to support it in the GTypeSerialiser code.
I also can never imagine a (non-hypothetical) case of wanting to send an
entire hash table of file descriptors over DBus. Even if I could
imagine one, it would be highly specialised, and I wouldn't mind writing
the code to do it myself -- and it wouldn't be hard to do.
One reason that I particularly like the GDBusFdSet approach is that, on
receive, it allows the user to give a NULL pointer for the out
parameter. In that case, the file descriptors received from the bus
will be automatically closed and the user needn't worry about doing
anything at all (ie: no fd leaks).
I appreciate that doing the GDBusFdSet thing results in some
uglification of the GDBus API (ie: addition of a new type and some new
functions call variants in some places) but I think this is the
reasonable thing to do. fd-passing is *very* DBus-specific. Please
remember that GVariant and GTypeSerialiser are general purpose datatypes
with many potential uses (eg: dconf, GSettings, mmap files, etc) and
that for these other uses, serialising a file descriptor makes no sense
at all.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why are no developers completing/maintaining native Gtk+ for OS X?
Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. I must say I find this rather baffling. I would have thought a platform like OS X to be a priority? I know that solutions like MacPorts provide Gtk+ for the X server in OS X, but I strongly doubt that the average OS X user would know where to begin with a project like MacPorts, and to be honest the look 'N feel * compared to native OS X. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. I would urge anyone with the time and knowledge to consider helping complete Gtk+ for native OS X. Sincerely Jacob Juul Kolding Juvul Tech ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 2009-11-09 at 19:10 +0100, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. I must say I find this rather baffling. I would have thought a platform like OS X to be a priority? Why do you think that? I know that solutions like MacPorts provide Gtk+ for the X server in OS X, but I strongly doubt that the average OS X user would know where to begin with a project like MacPorts, and to be honest the look 'N feel * compared to native OS X. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. I would urge anyone with the time and knowledge to consider helping complete Gtk+ for native OS X. Someone like for example you? This is a mostly volunteer driven project, and people usually tend to scratch their itches first before they do stuff that needs to be done. So if it's itching you, please help completing and fixing OS X support. regards, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira thi...@kde.org wrote: Besides, glib is only a dependency of Qt on the X11 platform. I can justify a VFS API that requires D-Bus to work properly (with some effort, on some platforms other IPC mechanisms would be preferable), but I cannot do it if it requires using glib gobject in platforms that its own maintainers currently don't support. Hmm ... I think a VFS API shouldn't even require D-Bus to work. Just like GIO only uses D-Bus/GVFS on X11. I agree that a QtVFS shouldn't depend on GIO in the API. But perhaps it would make sense to design it close to GIO so that it can act as a thin binding when GIO is available. My feeling is that the tough part of a new QtVFS is designing and consolidating the API. Therefore my thought was: If GIO has proven to be portable, an API which is designed to wrap GIO should be portable itself. Without necessarly depending on GIO. So this approach might save lot's of time. Cloning GIO in QObject/C++ style should save months racking one's brain about little details like which virtual methods and signals are required in which class. And if such an API moves towards a pure QDBus implementation later, why not. But starting with that might be putting the cart before the horse. Because I'm a bit worried that a complete rewrite of GVFS in Qt/C++ is just a too ambitios undertaking to get started. Regards, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 9 Nov 2009, Kristian Rietveld wrote: No, [the Quartz port of GTK+] is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches [and other good stuff] ... I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it. It's good to hear that GTK on Quartz has not gone to sleep; thanks very much for your work on this! Unfortunately this is not immediately clear if you google, say, gtk osx. Top of the search is the defunct Immendio page; if you follow that link you get a redirect to live.gnome.org, which is pretty much a placeholder. Finally you get to gtk-osx.sourceforge.net, but this page is a bit scatter-gun and, unlike the old Immendio page, there's no link (that I can find) to download a current build of GTK for OS X. You get a d/l link if you go to www.gtk-osx.org, but this offers GTK 2.14 which is quite dated by now, and gives the impression there can't be anything going on. I suspect that many GTK app developers (who probably work on Linux by preference) really don't want to build the GTK stack for OS X themselves (any more than they want to build the stack for win32). So if there's no reasonably current d/l available one assumes support is lacking. Bottom line: If there's any way to improve the web presence of GTK/OS X, and to provide a current pre-built GTK framework for downloading, that could make a big difference. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it. Well, let me be the first to thank you for all you efforts Kris, you have been extremely helpful to me, and I am actively developing a ERP (Ordering, purchasing, Inventory, CRM) for the company I work for. The work you and John Ralls et al. have done has made it possible for me to do my work. So keep up the good work. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. http://gtk-osx.sourceforge.net/ I have successfully used this on OS X Leopard (build the framework and app using jhbuild, with ige-mac-integration), and have been able to build the framework on SN (but my application crashes out, I think because of libglade which I really need to move away from, fix it for GtkBuilder). I to wish it was more complete (window transparency and shaping, is what I'm looking for), but I do not have a good enough grasp of Cocoa and Carbon (Not very familiar with Next Step windowing system) to be of any use, but I will certainly try to help were I can. Two years moving from Windows to Linux, and now OS X, V1 to be deployed in 010110. I'm not quite sure what you mean (Jacob) when you say native implementation, if you look at the quartz backend it looks pretty close to me, again with a lot of FIXME's in non-essential areas such as (window shaping), but that is not at all important for our functionality. It works, and it works well on OS X, just follow the jhbuild procedures form the above link. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? From: ja...@juvul.com Date: Tue, 10 Nov 2009 00:35:44 +0100 To: k...@gtk.org CC: gtk-devel-list@gnome.org On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 9 Nov 2009, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ App developer here again: Right now I can get a fully functional GTK+ framework (but one that relies on X11, not native) from http://r.research.att.com/ . It's stable, and does what I need, so that's what I use when packaging my project for OS X. I'd much prefer to use a native (non-X11) OS X GTK+ framework, but not if I have to build it myself (sorry, life is too short). I've tried what I think is the only downloadable native package (namely, the old Imendio one) but it's not good enough for production use. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about jhbuild + URL, could you please list all commands needed? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? From: ja...@juvul.com Date: Tue, 10 Nov 2009 00:35:44 +0100 To: k...@gtk.org CC: gtk-devel-list@gnome.org On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_test_find_widget bug?
On Mon, Nov 9, 2009 at 3:57 PM, Michael Libby michael.c.li...@gmail.com wrote:
This seems to be either a bug in my understanding of how to use this
functionality or a bug in the gtk_test_find_widget function itself.
After reading the source for the various gtk_test_find_* functions and
the documentation over again, the bug was my own understanding.
The function gtk_test_find_widget() is trying to find a widget *near*
a label with the text in question, whereas I was thinking it would
find the widget that *contained* the text in question.
No surprise that the existing function has somewhat strange behavior
when attempting to locate menu items.
Suggest to add something like to find the widget with the actual text:
GtkWidget*
gtk_test_find_widget_by_text (GtkWidget *widget,
const gchar *label_pattern,
GType widget_type)
{
if (GTK_IS_LABEL (widget))
{
const gchar *text = gtk_label_get_text (GTK_LABEL (widget));
if (g_pattern_match_simple (label_pattern, text))
return widget;
}
if (GTK_IS_CONTAINER (widget))
{
GList *node, *list = gtk_container_get_children (GTK_CONTAINER (widget));
for (node = list; node; node = node-next)
{
GtkWidget *label = gtk_test_find_widget_by_text (node-data,
label_pattern, widget_type);
if (label)
{
if (g_type_is_a (G_OBJECT_TYPE (widget), widget_type))
{
return widget;
}
else
{
return label;
}
}
}
g_list_free (list);
}
return NULL;
}
--
Michael C. Libby
www.mikelibby.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 3:34 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about jhbuild + URL, could you please list all commands needed? Please forgive me if it sounded bossy, that wasn't the plan... I've tried following the instructions on the gtk+osx sourceforge page, but jhbuild bootstrap fails because tex is missing. Anyone know where I can get that? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? From: ja...@juvul.com Date: Tue, 10 Nov 2009 00:35:44 +0100 To: k...@gtk.org CC: gtk-devel-list@gnome.org On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 4:03 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 3:34 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about jhbuild + URL, could you please list all commands needed? Please forgive me if it sounded bossy, that wasn't the plan... I've tried following the instructions on the gtk+osx sourceforge page, but jhbuild bootstrap fails because tex is missing. Anyone know where I can get that? Nevermind the tex thing, the actual problem is that glib fails to build because gettext is missing? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? From: ja...@juvul.com Date: Tue, 10 Nov 2009 00:35:44 +0100 To: k...@gtk.org CC: gtk-devel-list@gnome.org On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross- platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson al...@redhat.com wrote: I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. i've written some relatively big GTK apps. i've never wanted to use any of the facilities that GIO offers me. how is it central to GTK? maybe to GNOME apps? i don't know - I don't target GNOME at all. Just like Qt contains all that Qt developers want/need. This was one of the primary reasons I chose GTK over Qt. I'll make my own choices about libraries for IPC, sockets, UUIDs and the like, thank you very much. I was looking for a widget-based GUI toolkit, not MFC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
