Re: Stock Items Deprecation
- From: Murray Cumming <murrayc murrayc com>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: GTK Devel List <gtk-devel-list gnome org>
- Subject: Re: Stock Items Deprecation
- Date: Wed, 11 Sep 2013 13:24:48 +0200
On Wed, 2013-09-11 at 12:10 +0100, Emmanuele Bassi wrote:
hi;
On 11 September 2013 11:39, Murray Cumming <murrayc murrayc com> wrote:
This deprecated several classes (GtkIconFactory, GtkIconSet,
GtkIconSource, GtkImageMenuItem, GtkAction, GtkUIManager).
It also deprecated GtkRecentAction, because it deprecated the base
GtkAction.
as the author of GtkRecentAction, I'm honestly not concerned.
GtkRecentAction was a stop-gap that covered users of the old
EggRecent* API, and was never really useful; in a sense, it was a
class used to paper over a deprecation. shoving a bunch of recently
used files with only the name and a 16 px MIME type icon as a
differentiating feature in a menu (or in a toolbar menu button) always
seemed to me like a very bad UI. the file selection widget has a
better list of recently used files, these days.
OK. That sounds reasonable. Can we make that decision and state it in
the gtk-doc deprecation comments, please?
Deprecation without replacement makes the deprecation less useful to
application code because it makes it impossible for me to achieve zero
use of deprecated API.
I'm not entirely sure that "zero use of deprecated API" is a worthy
goal to achieve immediately after a single release cycle - especially
when it comes to timed releases like the 3.x series has been for the
past 3 years. yes, in the end we obviously want the deprecated API
usage in applications to tend to zero, but "being able to port an
application in the month and a half between API freeze and GTK
release" has never been a requirement for deprecating API.
[snip]
I don't need to do it immediately after the stable release. I'd like to
do it as soon as possible, idally before the next set of deprecations
come along, but that gives me 6 months or so, which seems like a
worthwhile goal for me.
We want deprecations to be useful and would like people to follow their
advice. They are more useful when people can temporarily turn on
warnings as errors and make sure there are no deprecation warnings left.
A warning that can't be solved would make that harder.
--
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]