GTK+ 2.90.2 released
GTK+ 2.90.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.90/ http://download.gnome.org/sources/gtk+/2.90/ d8010a92297f4f926c73d6afa67d9f63032c2a827324b9590bc034efcd4f3a3f gtk +-2.90.2.tar.bz2 6d8d3c57f77169d1a2fac0e9dde5bf0287f867d9199490a0f1dc6b9a024f9c6f gtk +-2.90.2.tar.gz This is the third development release leading toward 3.0. Notes: * GTK+ 3 will be parallel installable with GTK+ 2.x, and this release has been prepared to test this by renaming all .pc files, libraries, include paths, and so forth, to include a '3.0' component. * GTK+ 3 will remove deprecated API from the GTK+ 2.x series and make struct members unavailable that have been GSEALed in 2.x. Therefore, applications can be prepared for porting to GTK+ 3 by making sure that they build with -DGTK_DISABLE_DEPRECATED and -DGSEAL_ENABLE. * 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.90.1 to 2.90.2 == * GtkApplication: an application class, based on GApplication. Currently, this is fairly minimal, but it is good enough already to replace libunique. Future work: - Add a way to say "This is my application menubar", which gets put into all toplevel windows on non-OS-X, and into the top on OS X - Support session management - Maybe support application settings * Misc new api: - gtk_window_has_group: determines if a window is part of a window group - gtk_status_bar_remove_all: removes all messages from a statusbar * DND on offscreen windows works now * GtkIconView: - arrow keynav can now be connected over adjacent icon views * GtkAssistant: - gtk_assistant_commits: prevents going back beyond a certain point in the page sequence, adjust shown buttons appropriately - It is now officially supported to have a progress page at the end of the page sequence * Introspection: - Many annotation fixes - gdkx.h api is exported in a separate typelib, GdkX11-3.0 * Cleanups: - the draw_string function has been removed from GtkStyle - gdk_get/set_use_xshm have been removed - Deprecated gdk_color api has been removed * Documentation related to GTK+ 1.2, etc has been removed. Instead there is an initial GTK+ 3 porting guide now. * Bugs fixed: 620509 Progress bar rendering is broken 607628 DnD operation doesn't work when using offscreen. 619838 kill off references to gtk 1.2 in docs/comments 608218 GtkOffscreenWindow causes bad window with GtkEntry 619649 Remove deprecated code from GdkColor 619080 text-inserted events should not be emitted unless text... 620511 Use g_source_set_name for all custom GSources in GTK+ 603637 gtk printer dialog does not show remote printer 618271 Add gtk_window_has_group() 617863 Actually expose the X11 funcs through introspection 620244 misprint in the description of the function gtk_widget_list_... 549127 Print error dialog not shown 611709 gseal hides GtkStatusBar->messages but doesn't give anything... 596428 GtkAssistant: Support ending with a progress page * Translation updates: Esperanto Hebrew Irish Thanks to our contributors Javier Jardón Christian Beier Carlos Garcia Campos Michael Natterer Li Yuan Garrett Regier John Palmieri Cody Russell Marek Kasik Matthew Barnes Tadej Borovšak Colin Walters Stanislas Marquis Sven Herzberg Steve Frécinaux Richard Hughes June 8, 2010 Matthias Clasen ___ gtk-devel-lis
Re: Minutes of the gtk+ team IRC meeting - 2010-06-08
Hi, On Tue, Jun 8, 2010 at 7:06 PM, Emilio Pozuelo Monfort wrote: > Hi, > > On 09/06/10 00:49, Emmanuele Bassi wrote: >> • how to deal with gtk-requiring libraries, with regards to the API/ABI break >> - libraries will have to do an ABI bump to match the ABI bump in gtk >> - we need to communicate this on the various venues and remind the >> maintainers >> ACTION: mclasen to draft a mail for gtk-devel-list/desktop-announce > > Forgive me if I misunderstood it, but isn't this the sort of thing that would > be > avoided if GTK+ used symbol versioning? If so, using it from 3.0 onwards may > be > a good idea. If you read the recent thread, http://mail.gnome.org/archives/desktop-devel-list/2010-May/msg00088.html as it points out, symbol versioning only helps with symbols. The ABI bump would still be required for types, properties, signals, etc. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the gtk+ team IRC meeting - 2010-06-08
Hi, On 09/06/10 00:49, Emmanuele Bassi wrote: > • how to deal with gtk-requiring libraries, with regards to the API/ABI break > - libraries will have to do an ABI bump to match the ABI bump in gtk > - we need to communicate this on the various venues and remind the maintainers > ACTION: mclasen to draft a mail for gtk-devel-list/desktop-announce Forgive me if I misunderstood it, but isn't this the sort of thing that would be avoided if GTK+ used symbol versioning? If so, using it from 3.0 onwards may be a good idea. Cheers, Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minutes of the gtk+ team IRC meeting - 2010-06-08
• figure out how to make distcheck not touch any files under source control - distchecking gtk takes so long commits might happen in between - usually, translator commits - the distcheck phase touches files under revision control, named *.po - the Makefile.in.in from glib-gettext is the culprit - might be good to finally move glib-gettext to upstream gettext and switch to that - needs a list of requirements - at least, find a way for glib-gettext to not make our lives miserable by default • how to deal with gtk-requiring libraries, with regards to the API/ABI break - libraries will have to do an ABI bump to match the ABI bump in gtk - we need to communicate this on the various venues and remind the maintainers ACTION: mclasen to draft a mail for gtk-devel-list/desktop-announce • GApplication and GtkApplication - merged GApplication in glib - merged GtkApplication in gtk+ - feedback is coming through Bugzilla - identified issues: + portability (win32 and quartz backend are missing) + headless applications + platform support (inhibit idle, session management) + documentation should be improved (esp. failure conditions) • review GBinding - https://bugzilla.gnome.org/show_bug.cgi?id=348080 - binds two object properties, uni or bi-directionally + optionally with a transformation function - API idea coming from libexo - similar implementations in: gimp, evolution, gedit, seahorse - GObject functionality • review GObject::thaw-notify - property notification can be expensive - when N properties change it requires N signal emissions - bulk notification can be implemented only by overriding dispatch_properties_changed, which is not always possible - ::thaw-notify is emitted when the notification queue is thawed for the last time, and it emits a bulk notification of all the properties in the queue + thaw-notify is the signal form of ::dispatch_properties_changed() - naming is not really descriptive - needs more thought/work • Editable label: sub-class or class feature+ABI break? - replaces EelEditableLabel - a sub-class of GtkLabel was needed to preserve ABI - gtk+ 3.0 is breaking ABI anyway, so can we fold that into GtkLabel itself? - more importantly: do we really, really need them? - feature sets between labels and entries do not match - worth investigating the pattern of editable/uneditable widgets • get rid of GtkProgress - patch wrote by mclasen at: https://bugzilla.gnome.org/show_bug.cgi?id=620618 - not as hard as thought - not ABI compatile (for obvious reasons) - works fine • deprecation of gtk_quit_add_full() to remove GtkArg - GtkArg is only used by GtkCallbackMarshal - GtkCallbackMarshal is only used by one function - should really be replaced by GCallback • potential cost of direct access vs. function calls - sealing means moving away from direct access to public accessor and modifier functions even from within gtk+ - public accessors have type and argument checking - the cost has not been fully benchmarked - there are possible scenarios for enabling direct access from within the gtk+ code base without breaking all the work done with the sealing - measurement, or even a definition of measurement, should be done first ACTION: discuss on the mailing list next meeting: 2010-06-22 ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Quartz] Gtk Selection
On Jun 8, 2010, at 7:45 AM, Kristian Rietveld wrote: > On Jun 8, 2010, at 4:02 PM, John Ralls wrote: >> Thanks for the encouragement. It's done, and a patch submitted against >> https://bugzilla.gnome.org/show_bug.cgi?id=571582. > > Ah, I missed that Bugzilla mail. It was already on my review list. I am a > bit overloaded at the moment, also want to review the NSView embedding patch > and look at the GdkPixmap/GtkImage bug. I will do my best to get to it soon. > >> Yes, I understand that redesigning Gdk would be a long term goal. Have there >> been any discussions about what the architecture would look like on IRC? I >> sure haven't seen any here... > > Not that I know of. Would it be interesting to start "drafting" requirements > for this in the Wiki? Kris, It's too early for requirements. First we need to figure out what to abstract, and whether each abstraction really belongs in Gdk or should be moved "up" to Gtk (like clipboards) or "down" to Glib (like string conversions). Wikis are like whiteboards: They're a useful aid to a discussion but not a vehicle for the discussion itself. So if you want to start a wiki page, maybe you start a list of what Gdk abstracts, and we can discuss here where (i.e., GLib, Gdk, Gtk, or somewhere else, including Cairo and Pango) each of those abstractions belong. We could also consider whether there are abstractions in other libraries which would fit more naturally into Gdk. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] gtk team IRC meeting - 2010-06-08
this is a reminder for the GTK+ team IRC meeting, * date: 2010-06-08 * time: 20:00 UTC [0] * channel: #gtk-devel on irc.gnome.org * agenda: - how to deal with gtk-requiring libraries, wrt API/ABI break - GApplication and GtkApplication - GBinding - GObject::thaw-notify and GController - editable labels - get rid of GtkProgress - GtkArg removal: deprecate gtk_quit_add_full()? - Miscellaneous as always, everyone is invited to attend. ciao, Emmanuele. [0] http://www.timeanddate.com/worldclock/fixedtime.html?month=6&day=8&year=2010&hour=20&min=0&sec=0&p1=0 -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Quartz] Gtk Selection
On Jun 8, 2010, at 4:02 PM, John Ralls wrote: > Thanks for the encouragement. It's done, and a patch submitted against > https://bugzilla.gnome.org/show_bug.cgi?id=571582. Ah, I missed that Bugzilla mail. It was already on my review list. I am a bit overloaded at the moment, also want to review the NSView embedding patch and look at the GdkPixmap/GtkImage bug. I will do my best to get to it soon. > Yes, I understand that redesigning Gdk would be a long term goal. Have there > been any discussions about what the architecture would look like on IRC? I > sure haven't seen any here... Not that I know of. Would it be interesting to start "drafting" requirements for this in the Wiki? regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Quartz] Gtk Selection
On Jun 8, 2010, at 6:13 AM, Kristian Rietveld wrote: > On May 24, 2010, at 3:15 PM, Paul Davis wrote: >> On Mon, May 24, 2010 at 1:21 AM, John Ralls wrote: >> >> >> The structure of that part of Gdk follows very closely the X11 way of doing >> things, and Cocoa Foundation's way of handling selections and clipboards >> (which they call pasteboards) doesn't line up very well with it. It seems to >> me that it might work better to just make a gtkselection-quartz.c and >> implement everything directly, ignoring Gdk entirely, much as Richard did >> with gtkclipboard-quartz.c and gtkdnd-quartz.c. > > John, it's really great that you are having a go at getting the selection > code working. If Richard has been bypassing GDK in the clipboard and DnD > implementations as well (I have not studied that code in detail yet), then I > guess it makes sense to do the same for selections. > > >> seems to me that its all about time. ideally, the design of GDK would be >> modified to be more generic/adaptable, and all backends would continue to >> use it as an interface. but it seems to me unlikely that this is going to >> happen in any reasonably timely way. so if you want this to work (i confess >> that its not too important for ardour's functionality), i think your >> proposal is likely right way forward. > > I am really in favor of modifying the design of GDK to be more generic, not > only for selections, but for many more areas: DnD, window management, > drawing, etc. Of course, this is a really a long-term goal ... Kris, Thanks for the encouragement. It's done, and a patch submitted against https://bugzilla.gnome.org/show_bug.cgi?id=571582. As it happened, I had to touch both gtkselection and gdkselection -- the latter because of the text conversion routines. Fortunately in OSX, there is only utf8 for strings (unless someone overtly codes something else, but why do that?), so the implementations were pretty simple. I found in my studies that the Gtk widgets don't use the selection interface at all anymore; they use GtkClipboard. There's a recommendation about that in the Gtk Selections documentation, but I suggest going all out and deprecating the selection interface. Yes, I understand that redesigning Gdk would be a long term goal. Have there been any discussions about what the architecture would look like on IRC? I sure haven't seen any here... Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Quartz] Gtk Selection
On May 24, 2010, at 3:15 PM, Paul Davis wrote: > On Mon, May 24, 2010 at 1:21 AM, John Ralls wrote: > > > The structure of that part of Gdk follows very closely the X11 way of doing > things, and Cocoa Foundation's way of handling selections and clipboards > (which they call pasteboards) doesn't line up very well with it. It seems to > me that it might work better to just make a gtkselection-quartz.c and > implement everything directly, ignoring Gdk entirely, much as Richard did > with gtkclipboard-quartz.c and gtkdnd-quartz.c. John, it's really great that you are having a go at getting the selection code working. If Richard has been bypassing GDK in the clipboard and DnD implementations as well (I have not studied that code in detail yet), then I guess it makes sense to do the same for selections. > seems to me that its all about time. ideally, the design of GDK would be > modified to be more generic/adaptable, and all backends would continue to use > it as an interface. but it seems to me unlikely that this is going to happen > in any reasonably timely way. so if you want this to work (i confess that > its not too important for ardour's functionality), i think your proposal is > likely right way forward. I am really in favor of modifying the design of GDK to be more generic, not only for selections, but for many more areas: DnD, window management, drawing, etc. Of course, this is a really a long-term goal ... regards, -kris. ___ 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
On Tue, Jun 8, 2010 at 5:54 AM, Richard Hughes wrote: > On 8 June 2010 06:20, Matthias Clasen wrote: >> * GApplication: a basic application support class, with a D-Bus based >> implementation > > I've ported gnome-color-manager to this (from libunique), and it seems > to work fine. I'm wondering what branches of GTK are going to support > GtkApplication, as I can only see this in master for now. It is going to appear in 2.90.2 today. Colin wants it to land in 2.22 as well, but I am not convinced. The hurdle for switching to GTK3 is not high... > I'm also not sure on the policy for GNOME applications to depend on > gtk3 now. I assume gtk3 is a blessed dependency of GNOME? Are any > distros apart from Fedora shipping it yet? gtk3 is the next version of GTK+ I don't think any blessing is needed, really. We're making the transition as easy as possible for distributions, with full parallel installability. For really painless switching, we need some more progress on http://live.gnome.org/GnomeGoals/PortGtkModules I don't know about the availability of gtk 2.90.x in other distros. ___ 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
On 8 June 2010 06:20, Matthias Clasen wrote: > * GApplication: a basic application support class, with a D-Bus based > implementation I've ported gnome-color-manager to this (from libunique), and it seems to work fine. I'm wondering what branches of GTK are going to support GtkApplication, as I can only see this in master for now. I'm also not sure on the policy for GNOME applications to depend on gtk3 now. I assume gtk3 is a blessed dependency of GNOME? Are any distros apart from Fedora shipping it yet? Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
