GLib 2.27.3
GLib 2.27.3 is now available for download at:
ftp://ftp.gtk.org/pub/glib/2.27/
http://download.gnome.org/sources/glib/2.27/
c44177b635e88639361eb1daf7aaa33315a00aaf46db5accf2f11920c7ff1919
glib-2.27.3.tar.bz2
2fa8cefaf8d03b6575690b7c8788ad6d703b7e590a0ba8cef29f32fd8013a038
glib-2.27.3.tar.gz
Another development release in the 2.27 development cycle.
Overview of Changes from GLib 2.27.2 to 2.27.3
==
* The GTimeSpec type that was introduced in the 2.27.2 has been
dropped again in favour of APIs that return microseconds as
64-bit integer.
Affected functions:
g_source_get_time
g_periodic_unblock
g_get_monotonic_time
g_get_real_time
The similar GTimeVal struct is still around, but its use is
discouraged.
* GTimer is now using monotonic time unconditionally
* There are some new functions to facilitate error reporting
in async GIO APIs:
g_simple_async_result_take_error
g_simple_async_result_new_take_error
g_simple_async_report_take_gerror_in_idle
* There is new convenience API to us GVariant dictionaries:
g_variant_lookup
* It is now possible to delay sending match rules to the
D-Bus daemon in GDBus:
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE
* Support has been added for XDG_RUNTIME_DIR:
g_get_user_runtime_dir
* Various fixes for Win64/MSVC builds have been committed
* Bugs fixed:
620263 Add g_clear_object, g_clear_pointer, g_clear_boxed
633075 update Project Files and sources for MSVC 2008/C89
633381 gsettings Makefile rules should handle empty list...
633685 Use g_simple_async_result_{new_,}take_error
633686 Add g_simple_async_report_take_gerror_in_idle
* Translation updates:
Belarusian
Galician
Hebrew
Punjabi
Spanish
Thanks to the people who have contributed to this release:
Christian Persch
Paolo Borelli
Ryan Lortie
Tor Lillqvist
Dan Winship
Chun-wei Fan
November 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
Re: Gtk:ERROR:gtkrecentmanager.c: get_icon_fallback: assertion failed: (retval != NULL), win32
Hello. It also happens after installing the hicolor icon theme. It is reported here: https://bugzilla.gnome.org/show_bug.cgi?id=629878 . My workaround was to disable the icons in the GtkRecentChooserMenu, then it works ok. Bye. El 29/10/10 09:21, Julius Mlich escribió: Hi all, I've tried to run an gtk application using latest win32 GTK bundle ( http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.0-20101016_win32.zip ) Application worked without crash with older GTK versions, now does terminate with assertion. If I remove GtkRecentChooserMenu sumbmenu usage from application, it does work correctly. stderr output: Gtk-WARNING **: Nepodarilo sa nájsť ikonu 'gtk-file'. Téma 'hicolor' (~ 'gtk-file' icon not found, 'hicolor' theme) Gtk:ERROR:gtkrecentmanager.c:1942:get_icon_fallback: assertion failed: (retval != NULL) Looks to me as an issue in GTK. Have you Thanks, Julo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with 64 bit gtk binaries in Win 7 (32 bit works fine)
Well, glib is just depency of GTK+, GTK+ uses glib for things like
event loop, objects ... anyway, can you test my code? It works for me.
Add -std=c++0x to compilers command line for it to compile.
Note that you shouldn't use fscanf to get strings as it is quite
dangerous, anyway I used it so it matches your stuff
On Sun, Nov 7, 2010 at 8:16 PM, Mario M wrote:
> Sorry about the confusion, I do mean in callbacks. I have a Room class and a
> global room instance, the Room class has mesh members which when initialized
> read a specified file.
>
> The callbacks areconnected with:
>
>
> g_signal_connect (grafWindow, "expose-event",
> G_CALLBACK (glDraw), NULL);
>
>
> in the main function, then the functions that read the files are called
> inside main from within the room instance with:
>
>
> room.Init();
>
>
>
> and then the glDraw function callback for the expose event is:
>
>
> gboolean glDraw(GtkWidget *win, GdkEventExpose *event, gpointer user_data)
> {
> while(gtk_events_pending())
> {
> gtk_main_iteration_do(FALSE);
> }
>
> grafWinGL.beginGL();
> room.Draw();
>
> grafWinGL.swapBuffers();
> grafWinGL.endGL();
> return TRUE;
> }
>
>
>
> Basically, the room.Init is:
>
>
> void Init()
> {
> mesh1.Init("3D/file1.obj");
> mesh2.Init("3D/file2.obj");
> ... etc
> }
>
>
>
> mesh1 and mesh2 are instances of a mesh class, and room.Draw()
> calls mesh1.Draw() mesh2.Draw() etc. The mesh class, which when reading a
> file in it's Init function, does basically:
>
>
>
> char token[100];
> scene = fopen(obj_file.c_str(),"r");
> float vec[3]={0,0,0};
>
>
> while(!feof(scene))
> {
> token[0] = NULL;
> fscanf(scene,"%s", token);
>
> if (!strcmp(token,"v"))
> {
> fscanf(scene,"%f %f %f",&vec[0],&vec[1],&vec[2]);
> vList.push_back(Vec3(vec));
> }
> ..etc
>
>
>
> And here is exactly where the problem is. When I used all of this in my 32
> bit system, everything worked fine. Then in the 64 bit system, fscanf works
> in reading the token, but then fscanf(scene,"%f %f
> %f",&vec[0],&vec[1],&vec[2]); is doing nothing! Apparently it is called the
> correct amount of times, but after returning, the values in vec[0], vec[1]
> and vec[2] are the same as before calling the function, always. Thus, the
> mesh isn't rendered correctly ( meaning it doesn't get rendered at all
> because all the vertices are garbage).
>
> Now, after everything I tried, I changed the previous code to work with
> fstream functions like this:
>
>
>
>
> char token[100];
> ifstream fin(obj_file.c_str());
> float vec[3]={0,0,0};
>
>
> while(!fin.eof())
> {
> token[0] = NULL;
> fin>>token;
>
> if (!strcmp(token,"v"))
> {
> fin>>vec[0]>>vec[1]>>vec[2];
> vList.push_back(Vec3(vec));
> }
>
> .etc
>
>
>
> And now it works fine! Although it takes a looot more time to read the
> files (containing a few thousand vertices), but that bit isn't a gtk+ issue
> but a c++ issue I guess (fstream being way slower than cstdio took me by
> suprise :S ).
>
> I am very confused as to why it doesn't work with cstdio functions.
>
> Of course, I might still be doing something wrong, I think I may have
> slipped some of the gtk+ 32 bit dependencies when compiling gtk+, do you
> think that might affect this problem? I think it shouldn't but who knows. I
> haven't read about any similar problems so far.
>
> I haven't tried only with glib, I don't know much about it and I will have
> to wait until I have finished this project to try that, but thanks for the
> suggestion, I will try when I have time.
>
>
> Thanks!
>
> Mario Maqueo
> _
Re: Strange display problem with gtk-win32 and VC++
On 7 Nov 2010, at 18:14, Jaroslav Šmíd wrote: > So try to set your desired font - edit or create > (GTKDIR)\etc\gtk-2.0\gtkrc and add line like > gtk-font-name = "Segoe UI" > Thanks for the tip. In fact it turned out to be due to the fact that an entry in my pango.modules file had spaces in its pathname (in fact, there was only one entry for my simple testing purposes). This was causing the file contents to be incorrectly hashed when the file was being processed. I don't quite understand why everything worked when I substituted the official GTK binaries but I'm guessing there might be some fallback mechanism which works when built with gcc but doesn't work in the VC++ build for some reason. Anyway, surrounding the path with quotation marks fixed the problem. Thanks. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
