GNOME 2.24 available
From: | Vincent Untz <vuntz-AT-gnome.org> | |
To: | gnome-announce-list-AT-gnome.org, devel-announce-list-AT-gnome.org | |
Subject: | Celebrating the release of GNOME 2.24! | |
Date: | Wed, 24 Sep 2008 21:19:35 +0200 | |
Message-ID: | <20080924191935.GF19848@vuntz.net> |
====================================== Celebrating the release of GNOME 2.24! ====================================== Today, the GNOME Project celebrates the release of GNOME 2.24, the latest version of the popular, multi-platform free desktop environment and of its developer platform. Released on schedule, to the day, GNOME 2.24 builds on top of a long series of successful six months releases to offer the best experience to users and developers. For more than 10 years now, the project has been seeing a tremendous amount of work. And as usual, it's hard to come back to a previous version of GNOME once you've tried GNOME 2.24, which is probably the best compliment the project can receive. This six months effort wouldn't have been possible without the whole GNOME community, made of contributors from all around the world: hackers, documentors, usability and accessibility specialists, translators, maintainers, sysadmins, companies, artists, users and testers. GNOME would not exist without all those people. Thanks very much to every one of them! You'll find detailed information about GNOME 2.24 in our release notes: http://library.gnome.org/misc/release-notes/2.24/ Some parties are already happening in various places to celebrate this release. But tomorrow morning, you can be sure that GNOME contributors will already be working on their plans for the next version of GNOME, due in March, 2009. Enjoy! And be proud of it! - The GNOME Release Team -- Les gens heureux ne sont pas pressés. -- devel-announce-list mailing list devel-announce-list@gnome.org http://mail.gnome.org/mailman/listinfo/devel-announce-list
Posted Sep 24, 2008 21:41 UTC (Wed)
by Darkmere (subscriber, #53695)
[Link] (10 responses)
So, an upcoming article about the state of the project might be an idea, perhaps a QA with the release team or Stormy Peters now that she's firmly in the saddle?
Posted Sep 25, 2008 2:13 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (9 responses)
http://mail.gnome.org/archives/desktop-devel-list/2008-Se...
Posted Sep 25, 2008 6:18 UTC (Thu)
by alankila (guest, #47141)
[Link] (8 responses)
image->visual->depth,
I guess it's
gdkvisual_get_depth(gdkimage_get_visual(image)),
or maybe even
g_object_get_int(g_object_get_object(image, "visual"), "depth").
I don't see the improvement. Hiding private fields may be tenable as nobody is supposed to poke at them anyway, but this seems to go beyond sane.
Posted Sep 25, 2008 7:01 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Sep 25, 2008 9:07 UTC (Thu)
by kripkenstein (guest, #43281)
[Link]
C++ isn't trivially portable and has various other issues. Regardless, at this point in time it would be better to use an even higher-level language. The natural candidate would be Vala, of course.
A combination of Vala and the related projects of GNOME-introspection, automatic bindings generation, etc., for higher-level languages on top of that, would have been a compelling target for GTK3.
Posted Sep 25, 2008 14:21 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Sep 25, 2008 7:21 UTC (Thu)
by tetromino (guest, #33846)
[Link] (3 responses)
Posted Sep 25, 2008 9:28 UTC (Thu)
by alankila (guest, #47141)
[Link]
Posted Sep 25, 2008 10:30 UTC (Thu)
by epa (subscriber, #39769)
[Link]
C# deals with this in an elegant way by allowing properties with 'get' and 'set' methods which are exposed through the normal syntax. If you don't want the accessor to do anything except set the field, it can be generated for you, so no boilerplate is necessary. I hope other languages will adopt something similar.
Posted Sep 25, 2008 11:36 UTC (Thu)
by dgm (subscriber, #49227)
[Link]
Release Notes and GTK3
Previously it was said to want to "do away" with binary compatibility, however that seems to go against several years of good practice for no real good reason, even if interfaces can slowly be deprecated and phased out. (while retaining compatibility)
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
Release Notes and GTK3
If you allow direct access to structure fields, there is basically no sane way to implement new classes in languages such as Python or Java.
That's often true, and yet it is a real annoyance to cruft up the syntax with 'a.setY(b.getX())' instead of 'a.y = b.x', and to write boilerplate methods for every field you want to expose.
Release Notes and GTK3
It's not clear to me if you mean mere subclassing in an application's code, or subclassing for writing new classes for others to consume.