Re: GTK Widget assertion problem
In case anyone's interested I solved the problem with a little hack.
I create the progress bar this way:
progBar = gtk_progress_bar_new();
gtk_box_pack_start (GTK_BOX (vboxGr), GTK_PROGRESS_BAR(progBar), FALSE, FALSE,
0);
gtk_widget_show (progBar));
progressBarHack(progBar);
the function progressBarHack() looks like this:
void progressBarHack(GtkWidget* bar)
{
progBar = bar;
}
progBar is a global variable. I get an assertion error when I try to work with
it outside the function where the bar was created.
When I use my hack, which does nothing except some pointer work, everything
works fine.
I don't know why the hack was needed because I've worked with several widgets
with no problems at all. But this thing works.
Cheerz,
Michael
___
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: GTK Widget assertion problem
On Thu, Jun 10, 2010 at 01:31:33PM +0200, Michael T. wrote:
In case anyone's interested I solved the problem with a little hack.
I create the progress bar this way:
progBar = gtk_progress_bar_new();
gtk_box_pack_start (GTK_BOX (vboxGr), GTK_PROGRESS_BAR(progBar), FALSE,
FALSE, 0);
gtk_widget_show (progBar));
progressBarHack(progBar);
the function progressBarHack() looks like this:
void progressBarHack(GtkWidget* bar)
{
progBar = bar;
}
progBar is a global variable. I get an assertion error when I try to work
with it outside the function where the bar was created.
When I use my hack, which does nothing except some pointer work, everything
works fine.
I don't know why the hack was needed because I've worked with several widgets
with no problems at all. But this thing works.
Hello, this all looks like utter voodoo. You have probably a trivial
bug somewhere (elsewhere) in your code, maybe some
extern/static/initialization confusion? Or you overwrite the stack and
calling progressBarHack() causes a change of the layout so that you
overwrite a less sensitive place now? Anyway, it is recommended fix to
avoid global variables, they are evil, and externs are double-evil. But
perhaps if you show a minimal *complete* example that exhibits the error
some will be able to help you. Or, likely, you will find the root cause
while trying to extract the bad behaviour into a simple example...
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GKeyFile memory leak on Windows ?
Fixed now in git, bug #621168. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK Widget assertion problem
Hi,
Hello, this all looks like utter voodoo.
Yes it does. I tried 10 other ways and they didn't work. This one works
perfectly (so far).
You have probably a trivial
bug somewhere (elsewhere) in your code, maybe some
extern/static/initialization confusion?
All initialization was shown in the previous examples. All my initializations
are taken directly from the GTK+ documentation and I never had one problem.
More people have been developing this very same application and there was no
problem until I needed to work with the progress bar widget.
There is no static identifier used because it is not needed. The extern
identifier is used only, when the widget is accessed from other files which is
precisely what this identifier was designed for.
Or you overwrite the stack and
calling progressBarHack() causes a change of the layout so that you
overwrite a less sensitive place now?
progressBarHack() does nothing with the layout. All it does is a proper
initialization of the global variable which should work without the hack, but
doesn't.
Anyway, it is recommended fix to
avoid global variables, they are evil, and externs are double-evil.
Why? I've personally read the first book on C called The C programming language
from 1978 written by the inventor of the language and using global variables is
explained there as a proper way to implement things. I wonder what is the
source of the 'evil global variables' legend, but if I'm wrong, please correct
me. The extern identifier is just a way to access the global variable from a
different file. I don't see why it should be a double-evil.
But
perhaps if you show a minimal *complete* example that exhibits the error
some will be able to help you. Or, likely, you will find the root cause
while trying to extract the bad behaviour into a simple example...
I tried to do so in my first email (not the one you responded to). I also
mentioned that I use several widgets as global variables because I need to
access them from multiple functions. Hence, callbacks are not sufficient, in my
opinion.
There was never one problem with using widgets as global variables and the
application uses a lot of them. That's why I think there's a problem
particularly with the Progress bar widget.
My hack just initializes the global variable properly, all it does is
re-initializing the global variable outside the current function stack.
Anywayz, a another simple example:
// global variables
GtkWidget *combobox;
GtkWidget *textField;
GtkWidget *progBar;
GtkWidget* create_main_window (void)
{
//necessary window initializations, vertical boxes, tables etc.
combobox = gtk_combo_box_new_text();
gtk_combo_box_append_text(GTK_COMBO_BOX (combobox), (const char*) U/t);
gtk_combo_box_append_text(GTK_COMBO_BOX (combobox), (const char*) Q/t);
gtk_combo_box_set_active(GTK_COMBO_BOX (combobox), 0);
gtk_widget_show(combobox);
gtk_box_pack_start (GTK_BOX (vbox3), combobox, FALSE, FALSE, 0);
textField = gtk_text_view_new ();
gtk_widget_show (textField);
gtk_table_attach_defaults(table, textField, 3, 5, 0, 1);
progBar = gtk_progress_bar_new();
gtk_box_pack_start (GTK_BOX (vboxGr), GTK_PROGRESS_BAR(progBar), FALSE,
FALSE, 0);
gtk_widget_show (progBar);
// progressBarHack(progBar);
...
}
All the widgets are used as global variables due to reasons I have explained.
All of them work perfectly and can be accessed from various functions except
the progress bar widget. With the hack, progress bar works perfectly, too.
There are about twenty or more widgets in the application that are used the
same way - as global variables, there's never been one single problem.
Please correct me, if I'm wrong anywhere.
Thanks,
Michael
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.21.2 released
GTK+ 2.21.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.21/ http://download.gnome.org/sources/gtk+/2.21/ 48f0466e8149159523cd999f6b12561e3ba9e9d3effd5927641d80f8c9f83fdd gtk +-2.21.2.tar.bz2 17ba1e1ef1122be9e845a1d1e520b82a3a7d5231365956e7c7754312f28aa5c3 gtk +-2.21.2.tar.gz This is the third development release leading toward 2.22. Notes: * GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3. * Installing this version will overwrite your existing copy of GTK+ 2.20. If you have problems, you'll need to reinstall GTK+ 2.20. * GTK+ 2.22 will be source and binary compatible with the GTK+ 2.20 series; however, the new API additions are not yet finalized, so there may be incompatibilities between this release and the final 2.22 release. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.21.1 to 2.21.2 == * The newly added gdk_drag_context_get_action function has been renamed to gdk_drag_context_get_selected_action to make the name less confusing. * Introspection annotations have been added in many places * New accessors for sealed struct members: gtk_viewport_get_view_window gdk_drag_context_get_source_window * Bug fixes: 608218 GtkOffscreenWindow causes bad window with GtkEntry 611709 Add gtk_statusbar_remove_all 596428 GtkAssistant: Support ending with a progress page 620511 Use g_source_set_name for all custom GSources in GTK+ 608537 Make the file chooser's sort arrows consistent 620863 Unable to select GtkMenu item above the current one... Thanks to all contributors: Cody Russell Garret Regier Didier Roche Michael Natterer Colin Walters Javier Jardón Stanislas Marquis John Palmieri Steve Frécinaux Hib Eris Federico Mena Quintero Benjamin Otte Cosimo Cecchi June 8, 2010 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk-CRITICAL - getting meaningful information
I've been using gtk for a while and frequently get messages like this:
(nuchimp2:2621): Gtk-CRITICAL **: gtk_text_view_get_buffer: assertion
`GTK_IS_TEXT_VIEW (text_view)' failed
some times I can stumble over the cause and solution but the rest of
the time I'm left to blindly grope around in the dark.
Is there any way to get something meaningful that will point to a real
world location. I assume the :2621 points to a location in the code but
two successive compilations with the source unchanged (eg: make clean;
make; make install; run; make clean; make; make install; run) results
in a different number.
I used glade to define the interface:
...
object class=GtkWindow id=chimp_window
property name=title translatable=yesChimp for
chatmunkees/property property name=default_width640/property
property name=default_height400/property
property name=iconpixmaps/chimp2.xpm/property
signal name=destroy handler=gtk_main_quit/
child
object class=GtkVBox id=vbox1
property name=visibleTrue/property
property name=orientationvertical/property
...
child
object class=GtkNotebook id=notebook1
property name=visibleTrue/property
property name=can_focusTrue/property
child
object class=GtkVBox id=vbox2
property name=visibleTrue/property
property name=orientationvertical/property
child
object class=GtkHPaned id=hpaned1
property name=visibleTrue/property
property name=can_focusTrue/property
child
object class=GtkTextView id=chat_view
property name=visibleTrue/property
property name=can_focusTrue/property
property name=bufferchat_buffer/property
/object
packing
property name=resizeTrue/property
property name=shrinkFalse/property
/packing
/child
...
/object
packing
property name=position0/property
/packing
/child
...
object class=GtkTextTagTable id=chattexttagtable/
...
object class=GtkTextBuffer id=chat_buffer
property name=tag_tablechattexttagtable/property
/object
/interface
the code snippet this particular instance comes from is:
GtkTextView *chat_view;
GtkTextBuffer *chat_buffer;
GtkTextIter start, end;
GtkTextIter iter;
main()
{
...
chimp_window = GTK_WIDGET(gtk_builder_get_object(builder,
chimp_window)); gtk_builder_connect_signals(builder, NULL);
gtk_widget_show(chimp_window);
chat_buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(chat_view));
gtk_text_buffer_create_tag(chat_buffer, blue_fg, foreground,
blue, NULL); gtk_text_buffer_insert_with_tags_by_name(chat_buffer,
iter, Colored Text\n, -1, blue_fg, lmarg, NULL); ...
}
which gives these:
(nuchimp2:2621): Gtk-CRITICAL **: gtk_text_view_get_buffer: assertion
`GTK_IS_TEXT_VIEW (text_view)' failed
(nuchimp2:2621): Gtk-CRITICAL **: gtk_text_buffer_create_tag: assertion
`GTK_IS_TEXT_BUFFER (buffer)' failed
(nuchimp2:2621): Gtk-CRITICAL **:
gtk_text_buffer_insert_with_tags_by_name: assertion `GTK_IS_TEXT_BUFFER
(buffer)' failed
the tarball of the package (the small part I've done so far) can be d/l
from http:/www.junkyardalchemy.org/nuchimp2-0.1.tar.gz in case I've
snipped something critical.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Is it a bug in Gio::FileMonitor?
On Thu, 2010-06-10 at 04:23 +0300, Владимир wrote: I said I listened to all the events, not just some, in particular IN_ATTRIB stands for File's metadata (inode or xattr) was changed.. That is, I used IN_ALL_EVENTS which stands for Bitwise OR of all events.. Then its a bit weird that you got zero IN_MODIFY events as 500 megs of data was written to the file. From the inotify faq: Q: What is the difference between IN_MODIFY and IN_CLOSE_WRITE? The IN_MODIFY event is emitted on a file content change (e.g. via the write() syscall) while IN_CLOSE_WRITE occurs on closing the changed file. It means each change operation causes one IN_MODIFY event (it may occur many times during manipulations with an open file) whereas IN_CLOSE_WRITE is emitted only once (on closing the file). So, if the copy was done with say a 64k buffer you should have gotten 8000 IN_MODIFY events. You may of course chose to not look for IN_NOTIFY, but (just like I said before) the inotify faq says: Q: Is it better to use IN_MODIFY or IN_CLOSE_WRITE? It varies from case to case. Usually it is more suitable to use IN_CLOSE_WRITE because if emitted the all changes on the appropriate file are safely written inside the file. The IN_MODIFY event needn't mean that a file change is finished (data may remain in memory buffers in the application). On the other hand, many logs and similar files must be monitored using IN_MODIFY - in such cases where these files are permanently open and thus no IN_CLOSE_WRITE can be emitted. For gio its a bit worse here, because we can't rely on the existence of IN_CLOSE_WRITE as many backends don't have that (they only have the equivalent of IN_MODIFY). I also think it's sad that instead of a reaction like hey, he's got a point, this issue does make apps feel sluggish so we should investigate into it, after all even Java (7) which is also cross-platform doesn't suffer from this, there's instead quite the opposite reaction to not improve, like if we do this, a bad side effect will happen (and if you prove we're wrong about it we'll find another noble excuse) or just say nothing is perfect. I did say you had a point (we should look into why the delay is so large and i did say the inotify code was not ideal), but that doesn't mean I have time to dig into this immediately. Also, it doesn't mean that the issues I've talked about are without merit. But I have no interest in further arguing this with you. And thanks, I already went for inotify because clients/users want quality, not noble excuses. Good for you. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fast talking overambitious farmboy searching for his wife's true killer. She's a green-fingered mutant former first lady from beyond the grave. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print dialog hangs for several seconds before activating
On Wed, 2010-06-09 at 20:20 -0400, David A Benjamin wrote: I've run into this issue (and have been poking at it recently). The core problem appears to be that, although GTK+ is using CUPS and setting things like httpBlocking off, the CUPS non-blocking API isn't. See conversations with CUPS developers at [1,2,3]. Yeah, it seems like threads are the way to go. It appears that the only sane way to interact with CUPS in a GUI application is to use separate threads. If folks do not object the change, I'll try my hand at them. Historically gtk+ could not depend on threads being enabled, leaving it up to apps to call g_thread_init() and gdk_thread_init(). However, as of glib 2.24 gobject now calls g_thread_init(), so it should be safe to use threads in gtk+. You can't call gtk+ widget code from a thread though, as apps may still not have called gdk_thread_init(), so you need to marshal any thread results back to the mainloop (via e.g. g_idle_add()). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an unconventional coffee-fuelled vagrant on the run. She's a transdimensional snooty mercenary who can talk to animals. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GApplication and GtkApplication oddness
2010/6/9 Richard Hughes hughsi...@gmail.com: With GApplication we have: application = g_application_new_and_register (org.gnome.ColorManager.Prefs, argc, argv); and with GtkApplication we have: application = gtk_application_new (argc, argv, org.gnome.ColorManager.Prefs); It does seem slightly odd that the former has the appid first, and the latter has it last. I'm not sure it matters much, but I figured feedback might be useful. I do think it matters a lot, there should be consistency between calls, good catch. Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.25.8 released
O Mar, 08-06-2010 ás 01:20 -0400, Matthias Clasen escribiu: * Bugs fixed: I had submitted this bug as an enhancement and it was not taken into account. I expected that it could be included in the next release, but it wasn't and I guess it is because you didn't have any spare time to do it, but I just wanted to remind that I wrote a patch to make g_utf8_make_valid a public function, with tests and so on: https://bugzilla.gnome.org/show_bug.cgi?id=610969 Br. -- Xabier Rodríguez Calvar Enxeñeiro en Informática IGALIA http://www.igalia.com signature.asc Description: Esta é unha parte de mensaxe asinada dixitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GApplication and GtkApplication oddness
On 10 June 2010 10:34, Alberto Ruiz ar...@gnome.org wrote: I do think it matters a lot, there should be consistency between calls, good catch. For what it's worth, I prefer the glib style, so the app-id goes first. Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[patch] stray commas
Hi,
File gio/gioenums.h b/gio/gioenums.h in glib-2.25.7.tar.bz2 has some
stray commas at the end of enums that gcc 4.5 does not like. This patch
removes them.
-Mark
diff -urN a/gio/gioenums.h b/gio/gioenums.h
--- a/gio/gioenums.h 2010-05-24 18:39:22.0 +0200
+++ b/gio/gioenums.h 2010-06-05 20:37:07.923709408 +0200
@@ -770,7 +770,7 @@
{
G_BUS_NAME_OWNER_FLAGS_NONE = 0,/* nick=none */
G_BUS_NAME_OWNER_FLAGS_ALLOW_REPLACEMENT = (10), /* nick=allow-replacement */
- G_BUS_NAME_OWNER_FLAGS_REPLACE = (11),/* nick=replace */
+ G_BUS_NAME_OWNER_FLAGS_REPLACE = (11)/* nick=replace */
} GBusNameOwnerFlags;
/**
@@ -804,7 +804,7 @@
{
G_DBUS_PROXY_FLAGS_NONE = 0,/* nick=none */
G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES = (10), /* nick=do-not-load-properties */
- G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS = (11), /* nick=do-not-connect-signals */
+ G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS = (11) /* nick=do-not-connect-signals */
} GDBusProxyFlags;
/**
@@ -949,7 +949,7 @@
G_DBUS_ERROR_INVALID_FILE_CONTENT, /* org.freedesktop.DBus.Error.InvalidFileContent */
G_DBUS_ERROR_SELINUX_SECURITY_CONTEXT_UNKNOWN, /* org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown */
G_DBUS_ERROR_ADT_AUDIT_DATA_UNKNOWN, /* org.freedesktop.DBus.Error.AdtAuditDataUnknown */
- G_DBUS_ERROR_OBJECT_PATH_IN_USE, /* org.freedesktop.DBus.Error.ObjectPathInUse */
+ G_DBUS_ERROR_OBJECT_PATH_IN_USE /* org.freedesktop.DBus.Error.ObjectPathInUse */
} GDBusError;
/* Remember to update g_dbus_error_quark() in gdbuserror.c if you extend this enumeration */
@@ -988,7 +988,7 @@
*/
typedef enum {
G_DBUS_CAPABILITY_FLAGS_NONE = 0,
- G_DBUS_CAPABILITY_FLAGS_UNIX_FD_PASSING = (10),
+ G_DBUS_CAPABILITY_FLAGS_UNIX_FD_PASSING = (10)
} GDBusCapabilityFlags;
/**
@@ -1004,7 +1004,7 @@
*/
typedef enum {
G_DBUS_CALL_FLAGS_NONE = 0,
- G_DBUS_CALL_FLAGS_NO_AUTO_START = (10),
+ G_DBUS_CALL_FLAGS_NO_AUTO_START = (10)
} GDBusCallFlags;
/**
@@ -1088,7 +1088,7 @@
{
G_DBUS_PROPERTY_INFO_FLAGS_NONE = 0,
G_DBUS_PROPERTY_INFO_FLAGS_READABLE = (10),
- G_DBUS_PROPERTY_INFO_FLAGS_WRITABLE = (11),
+ G_DBUS_PROPERTY_INFO_FLAGS_WRITABLE = (11)
} GDBusPropertyInfoFlags;
/**
@@ -1105,7 +1105,7 @@
typedef enum
{
G_DBUS_SUBTREE_FLAGS_NONE = 0,
- G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES = (10),
+ G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES = (10)
} GDBusSubtreeFlags;
/**
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
installation glib
Hello, I installed libiconv-1.13.1 for glib-2.24.1. And when i make, i got the following: make all-recursive make[1]: Entering directory `/opt/gtk/glib-2.24.1' Making all in . make[2]: Entering directory `/opt/gtk/glib-2.24.1' make[2]: Leaving directory `/opt/gtk/glib-2.24.1' Making all in m4macros make[2]: Entering directory `/opt/gtk/glib-2.24.1/m4macros' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/opt/gtk/glib-2.24.1/m4macros' Making all in glib make[2]: Entering directory `/opt/gtk/glib-2.24.1/glib' make all-recursive make[3]: Entering directory `/opt/gtk/glib-2.24.1/glib' Making all in libcharset make[4]: Entering directory `/opt/gtk/glib-2.24.1/glib/libcharset' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/gtk/glib-2.24.1/glib/libcharset' Making all in pcre make[4]: Entering directory `/opt/gtk/glib-2.24.1/glib/pcre' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/gtk/glib-2.24.1/glib/pcre' Making all in update-pcre make[4]: Entering directory `/opt/gtk/glib-2.24.1/glib/update-pcre' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/gtk/glib-2.24.1/glib/update-pcre' Making all in . make[4]: Entering directory `/opt/gtk/glib-2.24.1/glib' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -g -O2 -Wall -MT gconvert.lo -MD -MP -MF .deps/gconvert.Tpo -c -o gconvert.lo gconvert.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -g -O2 -Wall -MT gconvert.lo -MD -MP -MF .deps/gconvert.Tpo -c gconvert.c -fPIC -DPIC -o .libs/gconvert.o gconvert.c:55:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv make[4]: *** [gconvert.lo] Error 1 make[4]: Leaving directory `/opt/gtk/glib-2.24.1/glib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/gtk/glib-2.24.1/glib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/gtk/glib-2.24.1/glib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/gtk/glib-2.24.1' make: *** [all] Error 2 Regards, Jinhee ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib
Hello, I installed the latest version of glib on my ubuntu 9.10 machine patched the kernel version of 2.6.32. After making glib before installing, my machine does not boot. What could be the problem? Regards, Jinhee ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print dialog hangs for several seconds before activating
On Thu, Jun 10, 2010 at 9:38 AM, Alexander Larsson al...@redhat.com wrote: On Wed, 2010-06-09 at 20:20 -0400, David A Benjamin wrote: I've run into this issue (and have been poking at it recently). The core problem appears to be that, although GTK+ is using CUPS and setting things like httpBlocking off, the CUPS non-blocking API isn't. See conversations with CUPS developers at [1,2,3]. Yeah, it seems like threads are the way to go. Dunno if this is related, but there is also bug 614581 that may help as well: https://bugzilla.gnome.org/show_bug.cgi?id=614581 which was committed as http://git.gnome.org/browse/gtk+/commit/?id=33097d65 HTH, Olivier. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print dialog hangs for several seconds before activating
Le mercredi 09 juin 2010 à 20:20 -0400, David A Benjamin a écrit : It appears that the only sane way to interact with CUPS in a GUI application is to use separate threads. If folks do not object the change, I'll try my hand at them. I would suggest to write a very thin layer that wraps the API and make it asynchronous the GLib way. See GAsyncResult/GSimpleAsyncResult with help of g_simple_async_result_run_in_thread(). Note that it won't make your API cancellable, I think that GResolver implement a solution to that. regards, Nicolas p.s. You could also simplement a DBus API for CUPS. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GApplication and GtkApplication oddness
2010/6/10 Richard Hughes hughsi...@gmail.com: On 10 June 2010 10:34, Alberto Ruiz ar...@gnome.org wrote: I do think it matters a lot, there should be consistency between calls, good catch. For what it's worth, I prefer the glib style, so the app-id goes first. I guess it makes sense since a lot of people are going to go for NULL, NULL in argv, argc. I can even see those being an optional argument in the python bindings for example, whereas the app id is mandatory I would assume. Richard. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-engines for GNOME 3 now on master
The code for GTK+ 2.22 is on the gtk-engines-2-22 branch. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.21.2 released
GTK+ 2.21.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.21/ http://download.gnome.org/sources/gtk+/2.21/ 48f0466e8149159523cd999f6b12561e3ba9e9d3effd5927641d80f8c9f83fdd gtk +-2.21.2.tar.bz2 17ba1e1ef1122be9e845a1d1e520b82a3a7d5231365956e7c7754312f28aa5c3 gtk +-2.21.2.tar.gz This is the third development release leading toward 2.22. Notes: * GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3. * Installing this version will overwrite your existing copy of GTK+ 2.20. If you have problems, you'll need to reinstall GTK+ 2.20. * GTK+ 2.22 will be source and binary compatible with the GTK+ 2.20 series; however, the new API additions are not yet finalized, so there may be incompatibilities between this release and the final 2.22 release. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.21.1 to 2.21.2 == * The newly added gdk_drag_context_get_action function has been renamed to gdk_drag_context_get_selected_action to make the name less confusing. * Introspection annotations have been added in many places * New accessors for sealed struct members: gtk_viewport_get_view_window gdk_drag_context_get_source_window * Bug fixes: 608218 GtkOffscreenWindow causes bad window with GtkEntry 611709 Add gtk_statusbar_remove_all 596428 GtkAssistant: Support ending with a progress page 620511 Use g_source_set_name for all custom GSources in GTK+ 608537 Make the file chooser's sort arrows consistent 620863 Unable to select GtkMenu item above the current one... Thanks to all contributors: Cody Russell Garret Regier Didier Roche Michael Natterer Colin Walters Javier Jardón Stanislas Marquis John Palmieri Steve Frécinaux Hib Eris Federico Mena Quintero Benjamin Otte Cosimo Cecchi June 8, 2010 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: [Gtk-osx-users] Print dialog hangs for several seconds before activating
Thanks Guys! This looks like it solved my problem. I had to apply the patch manually (GTK 2.18 on OS X 10.6.3 using jhbuild). No more hangs in the print dialog... my users will be singing your blessing. So the patch works, and from the bug it is has already been committed since 2.22. If it works, don't add more layers. Shawn Date: Thu, 10 Jun 2010 10:11:41 +0200 From: four...@gmail.com To: gtk-devel-list@gnome.org; gtk-osx-us...@lists.sourceforge.net CC: david...@mit.edu; al...@redhat.com Subject: Re: [Gtk-osx-users] Print dialog hangs for several seconds before activating On Thu, Jun 10, 2010 at 9:38 AM, Alexander Larsson al...@redhat.com wrote: On Wed, 2010-06-09 at 20:20 -0400, David A Benjamin wrote: I've run into this issue (and have been poking at it recently). The core problem appears to be that, although GTK+ is using CUPS and setting things like httpBlocking off, the CUPS non-blocking API isn't. See conversations with CUPS developers at [1,2,3]. Yeah, it seems like threads are the way to go. Dunno if this is related, but there is also bug 614581 that may help as well: https://bugzilla.gnome.org/show_bug.cgi?id=614581 which was committed as http://git.gnome.org/browse/gtk+/commit/?id=33097d65 HTH, Olivier. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Gtk-osx-users mailing list gtk-osx-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-osx-users _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
