GLib 2.31.18
Live from the Czech Republic, it's GLib 2.31.18! This release is an unstable release on the way to 2.32.0. http://download.gnome.org/sources/glib/2.31/ 1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa glib-2.31.8.tar.xz This release is aimed at being used as part of GNOME 3.3.90. You will need this to build the just-released Gtk+ 3.3.16. Overview of changes from GLib 2.31.16 to 2.31.18 * GDBusProxy has now a flag, G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES, which can be set to make GDBus automatically reload changed properties even if the propertychanged signal does not contain the new values. * GApplication puts non-unique applications on the bus * GApplication now has g_application_quit() * g_async_queue_timed_pop has been deprecated in favor of the new g_async_queue_timeout_pop, which uses relative delays in microseconds instead of a GTimeVal. * a huge number of API documentation fixes * Bugs fixed: 647986 put non-unique apps on D-Bus 658484 vpn connection vs NetworkSecretDialog 664237 GDateTime falls back to UTC if TZ is set 669329 gthread-win32: update for g_get_monotonic_time() changes 669330 glocalfile: fix error code when opening a directory on win32 669372 glib/tests memory leaks. 669412 mem leak in g_environ_unsetenv 669538 Fix compilation of glib-compile-resources.c on Windows 669544 gdbus-codegen example introspection XML is not complete 669595 glib-mkenums: fix handling of forward enum declarations 669670 gasyncqueue: don't use deprecated g_cond_timed_wait() 669671 gobject: use #pragmas to avoid deprecated function warnings 669689 Retrieve cwd and environ in local GApplicationCommandLine 669810 socket/win32: flush pending read before signaling HUP 669865 g_regex_fetch() 670085 memory leak in g_output_stream_write_async 670138 gbytes.h is missing the G_BEGIN/END_DECL guards 670485 Simplify session API (shared bug with gtk+) * Updated translations: Belarusian Danish Galician Serbian Telugu Hebrew Thanks to the contributors to this release: Ask H. Larsen Christian Persch Christophe Fergeau Chun-wei Fan Dan Winship Daniel Mustieles David King David Zeuthen Fran Diéguez Giovanni Campagna Javier Jardón Jesse van den Kieboom Kasia Bondarava Kjartan Maraas Luca Ferretti Marc-André Lureau Matthias Clasen Murray Cumming Peter Kjellerstedt Ravi Sankar Guntur Richard Hughes Swecha Localization Team Yaron Shahrabani Мирослав Николић Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reducing unncessary string copying
Hi folks, I've observed in many C applications, often compile-time defined data like strings are copied unnecessarily. For example, if you pass names to certain objects (eg. opening a file, creating a window, etc) that will never change of disappear during the process' lifetime (eg. compiled-in), those strings dont need to be copied. Now the big question becomes: how to decide this ? I'm currently experimenting with a new string reference datatype that has an extra bit which tells whether the string is static. Essentially a struct consisting of the char* pointer and an extra byte for the flag. That struct then will be used instead of the const char* pointers. A few inline functions handle the conversion from/to normal const char* and on-demand copying. Just some theoretical example: Some function FOO* create_foo(const char* name) now becomes FOO* create_foo(GCStr name) and the call now would be create_foo(G_CSTR_STATIC(hello world)); in case we dont have an static string, but something with limited lifetime, it could look like this: create_foo(G_CSTR_DYNAMIC(bar)); Inside create_foo() we'll then replace g_strdup() by some G_CSTR_COPY() and g_free() by G_CSTR_FREE(). These functions will know whether the string has to be copied/free'd. Let's just leave the question of API-compatibility aside, what do you think about this idea ? greets -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gnome-db] GDA as Gee.Collection Reched Milestone 1
On 13 January 2012 17:53, Daniel Espinosa eso...@gmail.com wrote: 2012/1/13 Vivien Malerba vmale...@gmail.com On 13 January 2012 00:51, Daniel Espinosa eso...@gmail.com wrote: Here is what I propose to you: - remove the generated files from git - add to git the reference of these files along with a test script (sh, python, perl, ...) which can then compare (or other) the generated files with the expected reference files to enable you to detect any problem. The advantage of having a script to detect problems is that it can be documented (in its header for example) and run by anybody who thinks there is a problem. for example copy Gda-5.0.gir to libgda/gir ? And then a script to check diffs? Yes, for example create a libgda/girtest to store the expected GIR file (managed using git), let the build mechanism create the GIR file in libgda/, and then have a script in libgda/girtest (also managed by git) which compares (or does other tests) the two GIR files after compilation (maybe executed when make check is run). This could be Ok if you always know the file format and what contents might be in. GIR format is undocumented and in GDA depends on API additions or minor improvements. One of the aditional goals of GObject Introspectio is API verification, I would like to try on GDA and get a first hit. I filed bug 667837 to notify API break in GDA-5.0.gir generated by GI master, the problem comes when check Vala extensions and fails to find a function on Gda.DataProxy. As explained on GI website, we could hold GIR versions for each release, not each time we compile, because the resulting GIR could include API breaks that must be fixed before release. To deal with bug 667837, I can make use on Vala of custom code or metadata, but on Python or JavaScript, witch depends directly on GIR, I can't do that. Another is to autogenerate GIR files but not install them. Instead we can send a patch to Vala or fix our code to make sure we will get not API break but API additions and improvements. When a new release is ready, we can check for API breaks by manually or include Unit Tests cases for the whole API in Python. Ok, I see it's a bit more complicated than I had anticipated. Then I'll let you do what you think is the best. However please add some doc (even as a README.GIR file for example) to tell how and when GIR files are generated, checked, updated, validated, whatever, so that other developers can understand what's going on. Thanks, Vivien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK theme engines slow ?
Hello, This is not a bug report as the relation to GTK is neither fully confirmed nor understood. But may i point you to this issue, and leave it to you if there's something substantial for you, or not ? key mail: http://lists.claws-mail.org/pipermail/users/2012-January/001204.html thread start: http://lists.claws-mail.org/pipermail/users/2012-January/001164.html original bug posting: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2584 Kind regards, Micha ps. If there would be something worth to reply, would you mind take me into CC ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK theme engines slow ?
Ah, and before you just skip it, pls read at least this bit too, about QT / Plasma not showing the issue even in the same running system. http://lists.claws-mail.org/pipermail/users/2012-January/001182.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_signal_handlers_block_matched() prototype
Hi, The func argument passed to g_signal_handlers_block_matched() is currently a gpointer, which causes a warning when GCC is in strict C99 mode, since C99 does not allow converting a function pointer to an object pointer. Wouldn't it make more sense for func to have GCallback type? -- John Lindgren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ design meetup in Brno
Hi. I was planning to come on Monday, but I can change to Sunday to make it. -- Jakub Steiner jim...@gmail.com http://jimmac.musichall.cz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ design meetup in Brno
Apologies for the slow response. I've just extended my trip to Brno so I will be there for more of the Gtk+ hackfest. I'm free any time Sunday, or I could do it later in the week if that would help (I'm there until Thursday 23rd). Allan On Mon, Feb 6, 2012 at 7:31 PM, Jakub Steiner jim...@gmail.com wrote: Hi. I was planning to come on Monday, but I can change to Sunday to make it. -- Jakub Steiner jim...@gmail.com http://jimmac.musichall.cz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Algorithm for drawing triangles in latest release of gtk+
Hi, Could anyone please confirm whether in the latest release of gtk+ (2.24.9, C/C++ binding), triangles are drawn as polygons or more optimized (in terms of speed) algorithms are used for drawing of triangles. I guess earlier versions of gtk+ (=2.4) used the same algorithms for general polygons and triangles. Thanks for your time. Regards, Debarshi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
* André Gillibert metaentr...@gmail.com schrieb:
This adds some level of indirection to access the data bytes, and some
space overhead.
For example, the string hello is 6 bytes long (including the zero
terminator), with GLIBC's malloc, it may occupy 8 bytes (or maybe 16
bytes).
With your implementation, it would occupy twice as much memory.
No. With my approach, strings aren't a single bit longer.
References to them require one more byte. (well, maybe more due padding).
On certain platforms/architectures (eg. 64bit), we maybe even could put
that single bit directly into the pointer (using the MSB if we can be
sure the upper half is never used).
Moreover, the binary code using strings would be larger of a few bytes too.
No. Plain access is not is not a single bit larger, ist just an offset.
My string reference looks like this:
typedef struct
{
gchar* str;
unsigned char flags;
}
And so, once g_strdup() has been called, a new dynamic string is
created. Consequently, very few strings would be static.
g_strdup() wont be called (directly) very often.
Code that is operating on my GCStry wont use that function, unless
it really wants a physical copy (eg. as buffer, etc)m instead if
uses G_CSTRY_COPY() which only copies non-static strings.
Storing the string as an array of bytes. The first byte of the array
would be the static bit, and the rest would be the string data.
Yep, also a good idea. Makes the required stack space smaller than
my approach. Perhaps could also be extended to do reference counting.
But: I'm currently lacking sufficient coffeine level to type down
a typedef+macro that a) makes writing string literals easy and
b) make it compile-type typesafe.
Perhaps something like:
typedef {
unsigned char flags;
unsigned char str[1];
} GCStr;
#define G_CSTR_LITERAL(s) (\1 s)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
2012/2/20, Enrico Weigelt weig...@metux.de:
* André Gillibert metaentr...@gmail.com schrieb:
This adds some level of indirection to access the data bytes, and some
space overhead.
For example, the string hello is 6 bytes long (including the zero
terminator), with GLIBC's malloc, it may occupy 8 bytes (or maybe 16
bytes).
With your implementation, it would occupy twice as much memory.
No. With my approach, strings aren't a single bit longer.
References to them require one more byte. (well, maybe more due padding).
On certain platforms/architectures (eg. 64bit), we maybe even could put
that single bit directly into the pointer (using the MSB if we can be
sure the upper half is never used).
Ok. If you pass around this structure as a value.
This indirectly increases the size of a data structure such as:
struct MyClass
{
GCStr some_string;
GCStr another_string;
} ;
And there are a lot of them...
Moreover, the binary code using strings would be larger of a few bytes
too.
No. Plain access is not is not a single bit larger, ist just an offset.
Copying a pointer (e.g. 8 bytes on 64 bits platform) requires less
code than copying a pointer and a char (which may occupy 16 bytes for
alignment purposes).
--
André Gillibert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.31.18
Live from the Czech Republic, it's GLib 2.31.18! This release is an unstable release on the way to 2.32.0. http://download.gnome.org/sources/glib/2.31/ 1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa glib-2.31.8.tar.xz This release is aimed at being used as part of GNOME 3.3.90. You will need this to build the just-released Gtk+ 3.3.16. Overview of changes from GLib 2.31.16 to 2.31.18 * GDBusProxy has now a flag, G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES, which can be set to make GDBus automatically reload changed properties even if the propertychanged signal does not contain the new values. * GApplication puts non-unique applications on the bus * GApplication now has g_application_quit() * g_async_queue_timed_pop has been deprecated in favor of the new g_async_queue_timeout_pop, which uses relative delays in microseconds instead of a GTimeVal. * a huge number of API documentation fixes * Bugs fixed: 647986 put non-unique apps on D-Bus 658484 vpn connection vs NetworkSecretDialog 664237 GDateTime falls back to UTC if TZ is set 669329 gthread-win32: update for g_get_monotonic_time() changes 669330 glocalfile: fix error code when opening a directory on win32 669372 glib/tests memory leaks. 669412 mem leak in g_environ_unsetenv 669538 Fix compilation of glib-compile-resources.c on Windows 669544 gdbus-codegen example introspection XML is not complete 669595 glib-mkenums: fix handling of forward enum declarations 669670 gasyncqueue: don't use deprecated g_cond_timed_wait() 669671 gobject: use #pragmas to avoid deprecated function warnings 669689 Retrieve cwd and environ in local GApplicationCommandLine 669810 socket/win32: flush pending read before signaling HUP 669865 g_regex_fetch() 670085 memory leak in g_output_stream_write_async 670138 gbytes.h is missing the G_BEGIN/END_DECL guards 670485 Simplify session API (shared bug with gtk+) * Updated translations: Belarusian Danish Galician Serbian Telugu Hebrew Thanks to the contributors to this release: Ask H. Larsen Christian Persch Christophe Fergeau Chun-wei Fan Dan Winship Daniel Mustieles David King David Zeuthen Fran Diéguez Giovanni Campagna Javier Jardón Jesse van den Kieboom Kasia Bondarava Kjartan Maraas Luca Ferretti Marc-André Lureau Matthias Clasen Murray Cumming Peter Kjellerstedt Ravi Sankar Guntur Richard Hughes Swecha Localization Team Yaron Shahrabani Мирослав Николић Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
High Quality Icon For GtkWindow
Hi Everybody in the mailing list I’m trying to set icon for my GtkWindow but why the quality decrease when it show in Dash(overview in gnome shell) ? i use gtk_window_set_icon and use gdk_pixbuf_new_from_file for loading my icon and my icon size is 128x128 and the type is png also i resize it to 64x64 but it didn't have any influence Regard Bijan Binaee ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Glib linking error: undefined reference to ...
Hi, I am not sure if this is the correct way of asking my question, but I nevertheless hope someone can help me... I just tried to solve the problem for 4 hours, and I am extremely frustrated right now... I have the following issue: I installed Ubuntu 11.10 and some libraries and packages afterwards. I then installed glib 2.30. Everything went fine, I got no errors when doing ./configure, make, or make install. However, when I try to compile a test file in C, I can compile without errors, but I get the following errors: glibTest.c:24: undefined reference to `g_timer_new' glibTest.c:32: undefined reference to `g_random_double' glibTest.c:36: undefined reference to `g_timer_stop' glibTest.c:55: undefined reference to `g_str_hash' ... I compile with: gcc `pkg-config --cflags --libs glib-2.0` -g3 -O2 -std=c99 -Wall -pedantic glibTest.c -o glibTest pkg-config --cflags --libs glib-2.0 gives me: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -L/usr/local/lib -lglib-2.0 This all worked on my old laptop with Ubuntu 10.04, and I have no idea what the issue is. I tried to install glib 2.28 and the newest 2.31 version, with the same error messages. I am no real expert, so please try to help me and let me know as precisely as possible how I can address the issue, I would greatly appreciate it. Thanks, Christian ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib linking error: undefined reference to ...
On Fri, Feb 17, 2012 at 12:20:22AM +0100, Christian Arnold wrote: glibTest.c:24: undefined reference to `g_timer_new' glibTest.c:32: undefined reference to `g_random_double' glibTest.c:36: undefined reference to `g_timer_stop' glibTest.c:55: undefined reference to `g_str_hash' ... I compile with: gcc `pkg-config --cflags --libs glib-2.0` -g3 -O2 -std=c99 -Wall -pedantic glibTest.c -o glibTest pkg-config --cflags --libs glib-2.0 gives me: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -L/usr/local/lib -lglib-2.0 Maybe we need to check that what is in /usr/local/lib is the new ?2.30? version you expect? e.g. ls /usr/local/lib/libglib-2.0* nm -g /usr/local/lib/libglib-2.0.3000.2 | grep g_timer_new (or whatever the library ends up being called) ? Cheers, Patrick ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib linking error: undefined reference to ...
On 17 February 2012 00:20, Christian Arnold chrarn...@web.de wrote: Hi, I am not sure if this is the correct way of asking my question, but I nevertheless hope someone can help me... I just tried to solve the problem for 4 hours, and I am extremely frustrated right now... I have the following issue: I installed Ubuntu 11.10 and some libraries and packages afterwards. I then installed glib 2.30. Everything went fine, I got no errors when doing ./configure, make, or make install. However, when I try to compile a test file in C, I can compile without errors, but I get the following errors: glibTest.c:24: undefined reference to `g_timer_new' glibTest.c:32: undefined reference to `g_random_double' glibTest.c:36: undefined reference to `g_timer_stop' glibTest.c:55: undefined reference to `g_str_hash' ... I compile with: gcc `pkg-config --cflags --libs glib-2.0` -g3 -O2 -std=c99 -Wall -pedantic glibTest.c -o glibTest pkg-config --cflags --libs glib-2.0 gives me: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/**include -L/usr/local/lib -lglib-2.0 This all worked on my old laptop with Ubuntu 10.04, and I have no idea what the issue is. I tried to install glib 2.28 and the newest 2.31 version, with the same error messages. I am no real expert, so please try to help me and let me know as precisely as possible how I can address the issue, I would greatly appreciate it. Could it be possible that you try to use the static version of glib and, because you pass it 1st on the command line, the symbols you use are not there in the final exe? Can you try the command like: gcc -g3 -O2 -std=c99 -Wall -pedantic glibTest.c -o glibTest `pkg-config --cflags --libs glib-2.0` Vivien ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GLib 2.31.18
Live from the Czech Republic, it's GLib 2.31.18! This release is an unstable release on the way to 2.32.0. http://download.gnome.org/sources/glib/2.31/ 1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa glib-2.31.8.tar.xz This release is aimed at being used as part of GNOME 3.3.90. You will need this to build the just-released Gtk+ 3.3.16. Overview of changes from GLib 2.31.16 to 2.31.18 * GDBusProxy has now a flag, G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES, which can be set to make GDBus automatically reload changed properties even if the propertychanged signal does not contain the new values. * GApplication puts non-unique applications on the bus * GApplication now has g_application_quit() * g_async_queue_timed_pop has been deprecated in favor of the new g_async_queue_timeout_pop, which uses relative delays in microseconds instead of a GTimeVal. * a huge number of API documentation fixes * Bugs fixed: 647986 put non-unique apps on D-Bus 658484 vpn connection vs NetworkSecretDialog 664237 GDateTime falls back to UTC if TZ is set 669329 gthread-win32: update for g_get_monotonic_time() changes 669330 glocalfile: fix error code when opening a directory on win32 669372 glib/tests memory leaks. 669412 mem leak in g_environ_unsetenv 669538 Fix compilation of glib-compile-resources.c on Windows 669544 gdbus-codegen example introspection XML is not complete 669595 glib-mkenums: fix handling of forward enum declarations 669670 gasyncqueue: don't use deprecated g_cond_timed_wait() 669671 gobject: use #pragmas to avoid deprecated function warnings 669689 Retrieve cwd and environ in local GApplicationCommandLine 669810 socket/win32: flush pending read before signaling HUP 669865 g_regex_fetch() 670085 memory leak in g_output_stream_write_async 670138 gbytes.h is missing the G_BEGIN/END_DECL guards 670485 Simplify session API (shared bug with gtk+) * Updated translations: Belarusian Danish Galician Serbian Telugu Hebrew Thanks to the contributors to this release: Ask H. Larsen Christian Persch Christophe Fergeau Chun-wei Fan Dan Winship Daniel Mustieles David King David Zeuthen Fran Diéguez Giovanni Campagna Javier Jardón Jesse van den Kieboom Kasia Bondarava Kjartan Maraas Luca Ferretti Marc-André Lureau Matthias Clasen Murray Cumming Peter Kjellerstedt Ravi Sankar Guntur Richard Hughes Swecha Localization Team Yaron Shahrabani Мирослав Николић Cheers ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
