I have the solution, and it is potentially of general interest. It seems
that the GtkPrintOperation widget is interacting with the (Unix) SIGUSR1
signal, which our program started using a while ago to do the client
thing. Dropping the (unix) signal handler for that signal made the
(glib) signals
Hi,
I am cross compiling Glib to arm target platform,but when i run to
g_thread_init(NULL),segmentation fault occured,i have noticed that somebody
else has also encounter the same problem.
Is there any solution?Thank you in advance.
___
Hello everyone,
According to http://developer.gnome.org/gtk3/3.0/GtkWidget.html#GtkWidget-draw:
Signal handlers connected to this signal can modify the cairo context
passed as cr in any way they like and don't need to restore it. The
signal emission takes care of calling cairo_save() before and
GLib 2.31.2 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b
glib-2.31.2.tar.xz
Overview of changes from GLib 2.31.0 to 2.31.2
GTK+ 3.3.4 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/3.3/
http://download.gnome.org/sources/gtk+/3.3/
bca709da29aecda87421eadd6762a0aac05fa5422b983b4a798957089a23a2e6 gtk
+-3.3.4.tar.xz
76f08e8aae8ab18865593163c2ee0b694b9618a81536fd56c76ddf124a0df669 gtk
+-3.3.4.tar.bz2
A
I know window-state-event is used to check whenever a window is
maximized. But is there a way to check whether a window has been
unmaximized. I don't want to check a window is in unmaximized state or
not. I want to check a window has been unmaximized when the
window-state-event is emitted. Any
On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote:
So; what say you? If there is interest I'll gladly polish it up for
inclusion. There are also tonnes of other low hanging fruits like
freeing other ref counted types, closing of streams, etc.
How about a g_autorelease_pool() or something
Le lundi 21 novembre 2011 à 00:00 -0800, Hub Figuière a écrit :
On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote:
So; what say you? If there is interest I'll gladly polish it up for
inclusion. There are also tonnes of other low hanging fruits like
freeing other ref counted types,
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many
On 11/21/2011 03:45 PM, Morten Welinder wrote:
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.
On Mon, Nov 21, 2011 at 10:34
On 21 November 2011 15:43, Dominic Lachowicz domlachow...@gmail.com wrote:
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C
On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote:
This is precisely my motivation for introducing this; ie. not to catch
leaks, but to tidy the code. Bigger code bases almost always grow
functions with multiple returns - notably when error handling is
introduced. Automatic freeing can cut
On 21/11/11 07:51 AM, Ross Burton wrote:
We need a micro-C++ binding that looks exactly like traditional
GObject C but also hooks up the nice features like stack allocated
objects. I don't like C++ but I'd consider a C++ compiler to compile
my C code if it could simplify memory management
GLib 2.31.2 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b
glib-2.31.2.tar.xz
Overview of changes from GLib 2.31.0 to 2.31.2
dconf 0.11.2 is released:
http://download.gnome.org/sources/dconf/0.11/
4625978257cd8c273a4d31ea7a8788326df63267fc0236b6d879e891cd48fad9
dconf-0.11.2.tar.xz
This is a point release leading up to what will become 0.12.0.
Changes in dconf 0.11.2
===
- many bugfixes
GTK+ 3.3.4 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/3.3/
http://download.gnome.org/sources/gtk+/3.3/
bca709da29aecda87421eadd6762a0aac05fa5422b983b4a798957089a23a2e6 gtk
+-3.3.4.tar.xz
76f08e8aae8ab18865593163c2ee0b694b9618a81536fd56c76ddf124a0df669 gtk
+-3.3.4.tar.bz2
A
On Mon, 2011-11-21 at 00:00 -0800, Hub Figuière wrote:
On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote:
So; what say you? If there is interest I'll gladly polish it up for
inclusion. There are also tonnes of other low hanging fruits like
freeing other ref counted types, closing of
18 matches
Mail list logo
