Re: libegg: Removing old directories
On 2011-04-02 16:12, Murray Cumming murr...@murrayc.com wrote: On Fri, 2011-03-18 at 23:42 +0100, Murray Cumming wrote: libegg has lots of directories that have just a README saying how the code has successfully moved into GTK+. But that's mostly old news now. If there's no objection then I'll remove the directories so it's easier to see at a glance what's still interesting. Maybe GDL (used in Anjuta) http://git.gnome.org/browse/gdl is the more up-to-date equivalent for EggDock http://git.gnome.org/browse/libegg/tree/libegg/dock If there's no objection, I'm likely to remove EggDock too. I removed EggDock. See http://git.gnome.org/browse/libegg/commit/?id=6b18361ab8f462a8039c11f8d731e3f9110eefdd ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
handling of duplicate _STRING and _FILENAME options in GOption
Hi, I run into a problem with the error-handling of g_option_context_parse() and trying to understand the of the context-changes list. As far as I see the job of context-changes is to revert the changes applied to the arg_data's by the parsing to the original state in case of an error like specifying a unknown option. In case that a _STRING and _FILENAME option is specified twice restoring the original value fails and the arg_data points to a already freed memory location: ==53227== Invalid free() / delete / delete[] ==53227==at 0x1FC7C: free (vg_replace_malloc.c:366) ==53227==by 0x10DC1: main (goption-cli.c:46) ==53227== Address 0x1056dd870 is 0 bytes inside a block of size 7 free'd ==53227==at 0x1FC7C: free (vg_replace_malloc.c:366) ==53227==by 0x10005A623: parse_arg (in /opt/local/lib/libglib-2.0.0.dylib) ==53227==by 0x10005AA56: parse_long_option (in /opt/local/lib/libglib-2.0.0.dylib) ==53227==by 0x10005B553: g_option_context_parse (in /opt/local/lib/libglib-2.0.0.dylib) ==53227==by 0x10D77: main (goption-cli.c:34) The problem is in parse_arg() for G_OPTION_ARG_FILENAME that does: /* first value */ data = g_strdup (value); change = get_change (context, G_OPTION_ARG_FILENAME, entry-arg_data); change-prev.str = *(gchar **)entry-arg_data; /* sets the original value */ g_free (change-allocated.str); /* noop */ change-allocated.str = data; *(gchar **)entry-arg_data = data; /* second value */ data = g_strdup (value); change = get_change (context, G_OPTION_ARG_FILENAME, entry-arg_data); /* returns the same Change */ change-prev.str = *(gchar **)entry-arg_data; /* points to the 'data' of the previous round */ g_free (change-allocated.str); /* BUG: free's the previous data, makes change-prev.str pointing to a invalid location */ change-allocated.str = data; *(gchar **)entry-arg_data = data; in free_changes_list() it does: g_free (change-allocated.str); *(gchar **)change-arg_data = change-prev.str; /* change-prev.str is already invalid */ G_OPTION_ARG_STRING has the same problem. The test-case is attached. goption-cli.c Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston kean.johns...@gmail.com wrote: Last, but by no means least, is the reliance on compiled files, like compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where things are installed in a universally-accessible location, this isn't a problem, but on Win32, where multiple applications could all include their own private copies of the DLL's, this is a problem. Fixing this is a bit the same thing applies to anyone who wants to make a relocatable Unix bundle. i've demonstrated that this is entirely possible even without any win32-style mechanisms, although it breaks when GSettings has been used by the desktop to specify modules that GTK should load which are not included in the bundle. the new binary-only packages of Ardour3 use the bag of tricks i've come up with to make GTK, Glib, Gdk-Pixbuf and Pango all find files inside the bundle in preference to any outside of it. it doesn't require any changes to glib, or gtk etc, but the app has to do some stuff. see fixup_bundle_environment() (the OS X or linux cases) here: http://subversion.ardour.org/svn/ardour2/branches/3.0/gtk2_ardour/main.cc there is some other stuff in there but a good part has to do with making the bundle self-contained and self-referencing. Thank you for your time reading this, and I welcome comments and debate. i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues (b) file bug reports in bugzilla, and briefly mention them here (c) attach fixes where applicable --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[OT] n...@naver.com
can we remove n...@naver.com from the list? everytime i send a message to gtk-devel, his mail server refuses my message and sends me back a message telling me this. i don't care, and i think its rude. does this happen to anyone else? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [OT] n...@naver.com
On Wed, Apr 06, 2011 at 08:30:33PM -0400, Paul Davis wrote: can we remove n...@naver.com from the list? everytime i send a message to gtk-devel, his mail server refuses my message and sends me back a message telling me this. i don't care, and i think its rude. does this happen to anyone else? I'll do so if I get a message from him ;) -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
2011/4/6 Kean Johnston kean.johns...@gmail.com: Everyone, WARNING: long, detailed message. If you don't care about Win32, move on. Other annoying Windows issues specific to glib: 1. GOption fails hard for filenames which are in a language different than your Windows. E.g. Chinese or Russian filenames on English Windows. The arguments passed to main() contain ? in place of the Chinese / Russian characters and that's just not enough information to correctly identify the file. More detail in the bug: https://bugzilla.gnome.org/show_bug.cgi?id=522131 2. GApplication. Mentioned in the mail. This functionality is traditionally implemented using named mutexes and shared memory. http://stackoverflow.com/questions/2285110/restrict-application-to-one-instance-per-shell-session-on-windows 3. GSettings using the registry. This means portable apps (in the sense of apps that you can carry with you on an USB stick: http://portableapps.com/) cannot use it, because they have to store the settings somewhere on the USB stick, not in the registry. It should be possible to use dconf on Windows. Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
