GTK+ 2.24.8
GTK+ 2.24.8 is now available for download at: http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.24/ ac2325a65312922a6722a7c02a389f3f4072d79e13131485cc7b7226e2537043 gtk+-2.24.8.tar.bz2 8a3b29f667933cf52eea2db7b066723edbc80443ca9c75b7cd7cbe8c8b90b93c gtk+-2.24.8.tar.xz This is a bug fix release in the stable 2.24 series. 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. Overview of Changes from GTK+ 2.24.7 to 2.24.8 == * Win32 updates: Major update of the win32 backend, it now works at least as well as the old 2.16.x version that a lot of windows applications was forced to use Some particular highlights: - Tablet support (wintab) works - The MS-Windows theme works better, and is enabled by default on Windows - Pointer grabs on button press now works - Initial Window positioning is improved and now works very similarly to the X11 backend - Scrolling a window with another window overlapping it doesn't produce rendering artifacts on XP - Configure event delivery after window move or resize is much more robust, fixing a variety of rendering hangs and misbehaviours - Scrolling with synaptics touchpads work better * OS X updates: - Add Command-cursor keyboard navigation in text widgets - Fix loss of motion events after using the menu bar - Handle recursive CFRunLoops, fixing e.g. crashes when dropping files from finder - Set proper event-state values in all events * Ensure that the MOD1 modifier always means ALT, as this assumption is already used in many places in Gtk+ * Search engine backend updated to Tracker 0.12 * Bugs fixed: 84314 gdk_display_sync() and gdk_flush() 142874 use of SetWindowLong in gdkwindow-win32.c causes... 169811 configure_event and window-state-event are not... 171456 Keep Above option in Gimp broken on Win32 324254 Realizing a top-level window widget early positions... 516822 gtk_window_fullscreen does not resize correctly if... 537296 Maximizing a window larger than the screen makes... 542777 Scroll-Wheel doesn't scroll (Win) 552041 Windows' System Menu from taskbar is buggy 574935 win32: gtk_window_set_geometry_hints() has no effect... 604156 gtk_window_set_modal() freezes application completely 612359 Dialog positioning hints fail on Windows 7 631384 Images pasted from clipboard are shifted/wrapped 647460 typo in msw_style.c? 650300 Notebook tabs are incorrectly displayed with the... 658272 Port gtksearchenginetracker.c to tracker 0.11/0.12 659565 unbreak compilation on OpenBSD 661997 Gtk crashes when changing the TreeView model while ... 662633 Scheduled transaction editor crashes with gtk+-2.24.7 662670 Pressing Enter in print dialog box will not cause... 663138 iconview: layout items immediately when setting... 663182 NSImage throws an exception from _gtk_quartz_... 663543 Huge memory leak while using MS-Windows theme (gtk-demo) 663605 Fix event-state of many event types on quartz November 10, 2011 Alexander Larsson ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Tue, 2008-12-30 at 21:47 -0500, Yu Feng wrote: Dear Devels: I am having troubles because the GMutex used gdk_threads_enter/leave can be non-recursive. I have a piece of code (g_module_check_init) to either be called from an event dispatched by GDK(if the module is loaded via GtkSettings) or be called directly without entering the GDK critical section(if the module is loaded via GTK_MODULE). The code need to be protected so that its execution is not interrupted by GDK activities in other threads. How can I do this without a recursive gdk critical section? IMHO that is a Gtk+ bug. When loading the modules from GTK_MODULE it should take the Gdk lock in order to provide the same behaviour in both cases. The way its currently set up means its impossible to get module loadind gdk-thread-safe in all cases. Its not really possible to drop the lock in the other case, so the only solution is to take the lock in this case. Its also in line with general Gtk+ behaviour to automatically have the gdk lock held when calling out to external code. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Asyncronous life helper (Was: EggDBus)
On Sat, 2008-12-27 at 04:21 -0500, Freddie Unpenstein wrote: This is a side-topic, raised by developments in handling DBus, but something I feel is worth asking... Is there any mechanism for making working with asynchronous stuff easier? Quite often I've had a situation where I've needed to collect several pieces of information from various asynchronous sources, and then act on them as a group only once some portion of that information is available. This is becoming increasingly important as we start working with more and more remote DBus services, web services, Corba/Orb/whatever-its-presently-called services, and the list goes on. Data life cycle and flow management keeps being a problem. You need to: - use a signal to catch data when it becomes available - store that data somewhere - distribute that data to other places when it becomes available - clean up the data when it's no longer needed - safely handle data sources failing or disappearing - manage re-try timeouts, age invalidation timeouts, etc. I sort of feel that what's needed, is a GWish which is a higher-level GBoxed embodying the whole data life cycle management, and I'm wondering whether there are any plans or similar ideas in the works, or even just whether anyone else has a working example of tackling a similar situation. My starter concept is this; GWish will - hold a piece of data, when it's available - can be asked to obtain its data if it doesn't have it - can be dependant on other GWish's (dependant data) - ask any depedant GWishes for theirs when it is asked - invoke a callback when ALL dependant data is available - can be given the data to hold at any time (usually by the callback) - signal when its data is ready (ie. when its data is set) - only ask dependant GWish's when it itself is asked - provide a helper function to perform the ask, and then wait - allow the data to be invalidated without destroying the GWish - be used internally (or at least faked externally) by async properties - propagate data invalidation (unless blocked by a flag or ignored) - allow some dependant data to be flagged as optional - allow the data set callback to fail after requesting more data - optionally count a dependency as a reference on that GWish - use weak references to clean up non-referencing dependencies - support relevant timeouts with automatic timeout cleanup - optionally destroy itself if a dependancy gets destroyed An application can then tie together various pieces of required data from any source (either GWish-compatible or wrapped in an external GWish), even user interaction, by having the final GWish dependant on other GWishes, some representing other intermediate shared data, and others representing source data, or simply stages of processing to ensure certain events occur in order regardless of what order their data becomes available. This sounds quite nice actually. There are many cases where something like this would have helped me. Another possible name for this is GFuture, as such objects are about information or other things that'll be availible in the future. One major problem about doing things like this in C is that you constantly have to define and allocate small structs to keep the data you need for the completo operation. If we could somehow make this easier that would be a large win. I don't know a great approach to do that offhand though. Some form of user data is one possibility, but I'd really like it to betype safe and without using strings as API. I guess a GFuture/GWish needs to be some form of container that you can grow in size by adding a struct of your own data to it. Maybe we can do it via a macro g_future_push_struct (future, struct LocalOpData, free_op_data) which grows the size of the object and puts the struct at the end. You'll pop it at end to free it. Of course, such serial/stack-like data management might not be general enought to handle things like parallel async operations. Maybe just a way to add the struct (undefined where) to the GFuture and then you'll get a pointer to the struct inside the GFuture in the completion callback... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
