GTK+ 2.8.6
GTK+ 2.8.6 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.6.tar.bz2 md5sum: 2bcb9e3feb62ac895101cb8ee87ca49a gtk+-2.8.6.tar.gzmd5sum: daf2b9cd4e29c8cb770828f9d7705796 This is a bugfix release in the 2.8.x series. 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.8 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/ Overview of Changes from GTK+ 2.8.5 to GTK+ 2.8.6 = * GtkFileChooser - Don't reload the current folder unnecessarily on map [Federico Mena Quintero] * Revert a change from 2.8.5 that could lead to assertion failures when finalizing GtkStyles [Matthias Clasen] * Remove context prefixes from Portugese translations [Duarte Henriques] Matthias Clasen October 4, 2005 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
how to termlessly *enforce* crosscompile mode ?
Hi folks, I need to *enforce* the crosscompiling mode even when building for the same target architecture. It mostly works fine by passing the right toolchain commands via environment (in fact: pure-make / non-autoconf applications work almost perfectly with that), but configure is too stupid to recognize that I'm crosscompiling. Is there any way for enforcing it to work in crosscompile mode, aka never ever attempt to run anything of the freshly compiled code, absolutely termless ? I'm tired of fixing these overbloatet configure scripts by hand for every new version. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: (gtk) bug and win98
On 03.10.2005 22:44, Adib Taraben wrote: Hello gtk-team, Inkscape is a SVG vector graphics editor that uses gtk and gtkmm. Currently with the 2.8 libs there is a problem starting on win98. http://bugzilla.gnome.org/show_bug.cgi?id=316878 Is it possible from you guys to investigate in this bug and find out wether it is a real gtk bug or not? No need to investigate. Cairo - which gtk+-2.8 depends on - is known not to work on win32. This is due to using only the unicode APIs for win32 font access. This API does not work on win9x. Inkscape will release a new version the next weeks and it would be good (I think) to ship the win32 version with gtk 2.8. Gtk 2.6 is known to work also on win98. If they are *really* interested in win9x support patches to http://cvs.cairographics.org/cairo/src/cairo-win32-font.c would probably be accepted. Though there may as well be other issues with running gtk+ on an obsolte os where apperantly no developer is interested anymore. Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
(gtk) bug and win98
Hello gtk-team, Inkscape is a SVG vector graphics editor that uses gtk and gtkmm. Currently with the 2.8 libs there is a problem starting on win98. http://bugzilla.gnome.org/show_bug.cgi?id=316878 Is it possible from you guys to investigate in this bug and find out wether it is a real gtk bug or not? Inkscape will release a new version the next weeks and it would be good (I think) to ship the win32 version with gtk 2.8. Gtk 2.6 is known to work also on win98. Many thanks for your patience, Adib. --- PS If I am on the wrong channel please guide me to the right position to ask this question again. Thx. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ team irc meeting
Hi Matthias, On 10/3/05, Matthias Clasen <[EMAIL PROTECTED]> wrote: > The meeting is intended for the GTK+ team, but everybody is > welcome to come and listen. The meeting logs will be posted > on the GTK+ website (http://www.gtk.org/plan/meetings). > > Place: irc.gnome.org:#gtk-devel > Time: 20:00 UTC (16:00 EDT), Wednesday, October 5 Recently I have started reading the irc log of the GTK+ team meeting. But unfortunately, this website wasn't updated with the lastest (after Sep 13) meeting logs :/ Do you know when/if these logs will be uploaded to the web site? Thanks in advance, Rodrigo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.8.5
GTK+ 2.8.5 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.8/ gtk+-2.8.5.tar.bz2 md5sum: cc25d162c5924e9bae02fb04c6fd494d gtk+-2.8.5.tar.gzmd5sum: 5809435d16e53e82fb3d5d930fd8a36e This is a bugfix release in the 2.8.x series. 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.8 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/ Overview of Changes from GTK+ 2.8.4 to GTK+ 2.8.5 = * GtkFileChooser - Don't clear the file name entry too often when in SAVE mode. [Jürg Billeter] - Reduce the startup time in OPEN mode [Federico Mena Quintero] * Stop drag in GtkPaned when grab shadowed [Matthias Clasen] * Correct the calculation for the first weekday in GtkCalendar [Matthias Clasen] * Use a larger buffer when determining the image format in gdk-pixbuf [Sebastian Bacher, Dom Lachowicz] * Win32 bug fixes [Kazuki Iwamoto, Tor Lillqvist] * Other bug fixes [Tor Lillqvist, Gustavo Carneiro, Paolo Borelli, Ray Strode, Søren Sandmann, Tommi Komulainen, Benjamin Berg] A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=308332,317444,316828,317455,317039,317457,317332,317491,317611,137796,314696,317225 Matthias Clasen October 3, 2005 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ team irc meeting
I'll be gone tomorrow, thus the meeting will be one day later than usual... The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 20:00 UTC (16:00 EDT), Wednesday, October 5 Possible agenda items: - Summit preparations - Project Ridley progress Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.8.3
GLib 2.8.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ glib-2.8.3.tar.bz2 md5sum: 58177fe64c189b86bac1625350512159 glib-2.8.3.tar.gzmd5sum: ea61e475c586d082559652a0f10a038f This is a quick follow-up release to fix a bug that crept into 2.8.2. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.8.2 to GLib 2.8.3 = * Fix an error that crept in with a change to glib-mkenums in 2.8.2 [Matthias] * Documentation improvements [Davyd Madeley] * Translation updates (bn) Matthias Clasen October 3, 2005 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango-1.10.1 released
Pango-1.10.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ pango-1.10.1.tar.bz2 md5sum: 1ff4c96982f61ea6f390d09a4febdf18 pango-1.10.1.tar.gzmd5sum: 6b3b06b3263845706a2bfc769b83f7fc This is a stable release and is source and binary compatible with 1.10.1. Notable changes include significant performance improvements for the Cairo backend on Windows and a couple of important bug fixes. About Pango === Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are two basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.10 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango depends on version 2.6.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.10.0 and 1.10.1 = - Add various forms of caching to the Win32 backend, greatly improving performance [Tor Lillqvist] - Fix problem with colors leaking from a Pango item to subsequently drawn strings. [Choe Hwanjin] - Fix bug where error underlines would be drawn 1024 times too big in the Cairo backend. [Luis Villa] - Misc bug and build fixes [Jean Brefort, Matthias Clasen, Behdad Esfahbod, Kazuki Iwamoto] Owen Taylor 3 October 2005 signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Regression in Pango 1.10 (See bug #316715)
Hi, Could someone review the bug #316715 I have filled two weeks ago ? It's a major bug that prevents me using gtk 2.8.x Mehmet ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RecentManager and win32
Hi James, On 10/3/05, James Henstridge <[EMAIL PROTECTED]> wrote: > Emmanuele Bassi wrote: > > >* Strategy > >== > > > >Obviously, we can't have two APIs, so the best thing that I could come > >up with was: > > > >1. we use, for the recently used resources list, the same storage system > >on both Unix *and* win32: a dot file inside $HOME, which stores > >everything using an XBEL dialect; > > > >2. plus, protected by arch-dependent #ifdefs, when we register every new > >item inside *ours* recently used resources list, we also register it > >inside windows' MRU list, using the win32 shell API. > > > >By doing this, we keep the same meta-data on both archs, but we make > >windows aware of what we are registering. > > > > > With this scheme, what do you do if the two recent files lists are out > of sync? Which one is considered correct in such a case? Since there's no common way to programmatically access the Recent Documents list (except, as written by Tor, list the directory contents), Gtk applications would only access the gtk recent files list, which should be considered, at all effects, as an "extended MRUList", not stored inside the win32 register... > If you treat the XML file as canonical, how do applications find out > about new items added by native Windows applications? As far as I can see on MSDN, no application has access to recently used files registered by other applications. Global recently used files are activated using the default MIME type handler. > If you try to merge the two lists, how do you remove items from the list? I'm not trying to merge the two list: these list are separated, and they are supposed to be. But they are separated for every win32 application; every win32 app register an item *twice*: one inside the Recent Documents global list, and one inside its own MRUList. Applications have access to their own MRUList - the global Recent Documents directory is handled by the shell. Just to be sure: try and open a new file inside a win32 application - say Word; then, clear the Recent Documents contents. Open Word again, and you should see that the file is still listed inside the File menu, even though the global Recent Documents list is empty[1]. So, when a Gtk application registers a new recent file, it will register it in two list: the list held by the RecentManager, and the list held by the win32 shell. This is what I inferred from the API documentation on MSDN. If I'm mistaken, I'd like a pointer to something else that explains how recently used documents works on win32. +++ [1] This is totally braindead. I wouldn't believe it myself, when I tried it. Regards, Emmanuele. -- It is against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail, and learning to be self-critical? -- Alan Perlis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RecentManager and win32
Emmanuele Bassi wrote: >* Strategy >== > >Obviously, we can't have two APIs, so the best thing that I could come >up with was: > >1. we use, for the recently used resources list, the same storage system >on both Unix *and* win32: a dot file inside $HOME, which stores >everything using an XBEL dialect; > >2. plus, protected by arch-dependent #ifdefs, when we register every new >item inside *ours* recently used resources list, we also register it >inside windows' MRU list, using the win32 shell API. > >By doing this, we keep the same meta-data on both archs, but we make >windows aware of what we are registering. > > With this scheme, what do you do if the two recent files lists are out of sync? Which one is considered correct in such a case? If you treat the XML file as canonical, how do applications find out about new items added by native Windows applications? If you try to merge the two lists, how do you remove items from the list? James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject reference counting / lack of "sink" issue
Tim Janik wrote:
> you are right, GObject is widely used these days out of GtkObject
> contexts,
> and anywhere in C land (where memory book keeping or reference house
> keeping
> can't be automized) when objects are created and ownership is passed on,
> a floating flag is strongly desired (and forces you to derive and
> reimplement
> if you're consequent enough ;)
>From a language bindings perspective, if the language supports garbage
collection you usually want to get rid of the floating references if
they exist. So having support for floating references in GObject itself
would be good, provided all objects with floating references used the
support, since the "remove floating reference" code could be generic.
(it would still be necessary to special case GtkWindow and its
descendants due to the fact that the reference returned by
g_object_new(GTK_TYPE_WINDOW, ...) is owned by the GTK internals).
> so for a change, i'd like to suggest introducing extra API (and do
> some slight
> deprecations) for this and apprechiate people's comments on it:
>
> /* ref() and clear floating flag (#1) */
> GObject*g_object_ref_sink (GObject *object);
>
> /* figure whether floating flag is set */
> gbooleang_object_is_floating(GObject *object);
>
> /* intended for object implementations only, sets the floating flag */
> voidg_object_force_floating (GObject *object);
This API looks usable. So the following code:
if (GTK_OBJECT_FLOATING(object)) {
g_object_ref(object);
gtk_object_sink(GTK_OBJECT(object));
}
to:
if (g_object_is_floating(object))
g_object_ref_sink(object);
> #1) in allmost all cases where the _sink() API is used, it's used in
> combination with _ref() similar to:
> g_object_ref (object);
> g_object_sink (object);
> so this may as well be a single function call, especially since
> this function call may then conveniently return the object
> handle the way _ref() already does it. in the pretty rare
> scenarios where the automatically added reference count is not
> usefull (e.g. when emulating gtk_object_sink()), a combination of
> _ref_sink() and _unref() can be used instead.
Combining ref() and sink() into a single call would also make it
impossible to issue the sink() call before ref(), closing off a class of
bugs (it does open up a similar class of bugs for implementing sink()
behaviour, but that should be a lot less common).
James.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject reference counting / lack of "sink" issue
On Mon, Oct 03, 2005 at 02:09:27AM -, Andrew Paprocki wrote: > Dave, > > Using the same container example which needs to take ownership of GObjects > passed to the public API -- > The problem we have is that much more time and effort goes into crafting the > core container objects, and having inconsistent public API (two methods) to > add an object to a container is highly undesirable. This leads to confusion > and bugs in our experience. The burden should be placed on the person > designing the container to ensure that the public API calls properly ref/sink > when needed thereby eliminating the burden from the much larger group of > programmers which will be calling the API. > > We have run into consistent problems when writing reusable objects for an > audience of over a thousand developers at our firm. Since callers of the API > are not expected to be fully literate in GObject semantics, pushing the > burden to the caller (requiring them to unref after passing) can lead to > nasty memory leaks. Similarly, creating two API calls to pass an object into > a container is also not desired because it leads to confusion when the > callers are not familiar with GObject's ref-counting implementation. you cannot avoid it in c: you must understand the ref-counting policy. if you wish for thousands of developers to never have a a problem, you should switch languages. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
