About GTK+ 3.0 and deprecated things

[Colin Leroy]

On Thu, 17 Jul 2008 12:55:59 +0200, Mikael Hallendal wrote:

Hi,

> A suggestion that came up in the post-guadec discussions was to move  
> deprecated widgets to libgtk3-compat instead of removing them. This  
> means that applications using these will have to add that as a  
> dependency to his code base in order to continue using them. Off the  
> top of my head this sounds like a good suggestion to me.

Indeed.

> The 1.x -> 2.0 change was painful for everyone who had an app that  
> needed porting, however I find it pretty irrelevant in comparison to  
> 2.x -> 3.0.

Well, if no libgtk-compat is planned, it will be about as painful
for users of the deprecated and removed widgets/functions.

--
Colin
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Kalle Vahlman]

2008/7/16 Colin Leroy <colin@...>:

> On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:
>
> Hi,
>
>> IMO, if you're still using GtkCTree and GtkCList, which were
>> deprecated when GTK+ 2.0 was released 6 years ago, you're asking for
>> trouble.
>
> Well, they do work for us. When GTK+ 2.0 was released six years ago, we
> were already too busy with the rest of the rewriting code-that-worked to
> do it. Two years and nine days, exactly, between the first commit to
> the GTK2 branch and the first GTK2 release after 497 commits. And we
> never came to replace the GtkCtrees because a) they work and b) we
> didn't have the time/motivation.

If using deprecated and unmaintained code is not a problem for you, I
suppose there's no real reason to be worried about GTK+ 3.x either..?

I wish people would stop fighting against the "code cleanup release",
unless they really want to switch to an alternative widget library.
GTK+ isn't seeing the love it needs, and the strict API/ABI policy of
GTK+ 2.x mixed with "leaky" public interfaces is seen (by the people
doing the work) as one of the biggest problems why that is.

If you prevent fixing that with all this stop-energy, it's not going
to take long for new applications start choosing something less dead
as their widget set of choice.

So please let the code be revived _now_ when there's a chance it's not
going to be just undead after the operation and direct the energy to
implementing the canvas, css theming and animations and whatever. The
good news is that you don't need to wait for 3.x, you can start the
work already! The new API and its policy is already known and in SVN
if I'm not mistaken, so go and hack away!

--
Kalle Vahlman, zuh@...
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Travis Watkins-2]

On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman <kalle.vahlman@...> wrote:

> I wish people would stop fighting against the "code cleanup release",
> unless they really want to switch to an alternative widget library.
> GTK+ isn't seeing the love it needs, and the strict API/ABI policy of
> GTK+ 2.x mixed with "leaky" public interfaces is seen (by the people
> doing the work) as one of the biggest problems why that is.
>
> If you prevent fixing that with all this stop-energy, it's not going
> to take long for new applications start choosing something less dead
> as their widget set of choice.
>
> So please let the code be revived _now_ when there's a chance it's not
> going to be just undead after the operation and direct the energy to
> implementing the canvas, css theming and animations and whatever. The
> good news is that you don't need to wait for 3.x, you can start the
> work already! The new API and its policy is already known and in SVN
> if I'm not mistaken, so go and hack away!
>

The problem is this "code cleanup release" breaks everyone's
applications for no reason. No one has shown a case where the current
situation makes a fix impossible and no one has proven any interesting
new features (other than whole new widgets, which we can do now) can
be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get
terrible backlash from a 3.0 that has zero new features and I suspect
any of the promised shiny bits will end up having to wait until 4.0
anyway.

In the end all we get is the ability to drop some old widgets no one
spends time on anyway.

--
Travis Watkins
http://www.realistanew.com
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Sven Herzberg]

Am Donnerstag, den 17.07.2008, 06:59 -0500 schrieb Travis Watkins:
> On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman <kalle.vahlman@...> wrote:
> The problem is this "code cleanup release" breaks everyone's
> applications for no reason.

This is wrong for 2 reasons:

1. It does only breaks apps that don't compile with disable-deprecated
or enable-broken; that's far from "everyone's"

2. There are reasons, they have been mentioned quite a few times (code
cleanup, more possibilities for refactoring, etc.)

> No one has shown a case where the current
> situation makes a fix impossible and no one has proven any interesting
> new features (other than whole new widgets, which we can do now) can
> be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get
> terrible backlash from a 3.0 that has zero new features and I suspect
> any of the promised shiny bits will end up having to wait until 4.0
> anyway.

Wring, just read Kris' email, he's mentioning very concrete development
ideas that are not possible without breaking the current API, but that
would be possible if we had properly sealed from the beginning.

> In the end all we get is the ability to drop some old widgets no one
> spends time on anyway.

Isn't that a good thing, too? Dropping unmaintained stuff so others
won't use it and might be disappointed because of the bad state of it?

Regards,
  Sven

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Mikkel Kamstrup Erlandsen-2]

2008/7/17 Travis Watkins <amaranth@...>:

> On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman <kalle.vahlman@...> wrote:
>> I wish people would stop fighting against the "code cleanup release",
>> unless they really want to switch to an alternative widget library.
>> GTK+ isn't seeing the love it needs, and the strict API/ABI policy of
>> GTK+ 2.x mixed with "leaky" public interfaces is seen (by the people
>> doing the work) as one of the biggest problems why that is.
>>
>> If you prevent fixing that with all this stop-energy, it's not going
>> to take long for new applications start choosing something less dead
>> as their widget set of choice.
>>
>> So please let the code be revived _now_ when there's a chance it's not
>> going to be just undead after the operation and direct the energy to
>> implementing the canvas, css theming and animations and whatever. The
>> good news is that you don't need to wait for 3.x, you can start the
>> work already! The new API and its policy is already known and in SVN
>> if I'm not mistaken, so go and hack away!
>>
>
> The problem is this "code cleanup release" breaks everyone's
> applications for no reason. No one has shown a case where the current
> situation makes a fix impossible and no one has proven any interesting
> new features (other than whole new widgets, which we can do now) can
> be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get
> terrible backlash from a 3.0 that has zero new features and I suspect
> any of the promised shiny bits will end up having to wait until 4.0
> anyway.
>
> In the end all we get is the ability to drop some old widgets no one
> spends time on anyway.

I have two comments:

1) How does *anything* break? I am willing to bet 10 cases of beer
that distros are going to ship gtk 2.0 and 3.0 side by side for a long
time (unless it is absolutely trivial to port all major apps). Also
with the widespread deployment of Gtk2 it is also likely to assure
that Gtk2 will bitrot in the short term.

2) I also think that the psychological aspect of this whole deal gets
way to little attention. Hackers that are not seasoned Gtk-veterans
(like yours truly) are more and more regarding Gtk as an outdated
toolkit. And you can rest assure that this is what the lay hacker
think. I walk and talk with people that think this every single day.
At work, on mailing lists, on IRC. Everywhere. It is just not cool to
use Gtk.

As I see it Gtk is in desperate need of of a cool-juice injection if
it want to continue to appeal to aspiring hackers. Talking about
myself I can attest that I am looking more and more for alternatives.
If it was not because my mind was incompatible with C++ (although I
really want to like the language) and that my attention span simply
can not cope with KDE I would probably have been a Qt consumer today.
Call me an eye-candy-junkie or what ever derogatory term you want to
apply, but people out there in the trenches are *already* seeking out
alternative toolkits. You don't have to look very far to see that, but
I shall omit any finger pointing.

As mentioned this is very much a psychological phenomenon, not
necessarily rooted in rigorous technical arguments. We need something
flashy to turn this sentiment, technical rants and ABI stability will
not cut it.

Conclusion:
Gtk does not have to break and go for 3.0. It can probably survive a
good many years yet and I will continue to use it myself. However; if
the idea is to keep aspiring hackers interested something has to be
done. This need not be a goal of Gtk and I can accept that. There are
plenty of reasons not to break, like don't upsetting key stake
holders. In the end it comes down to which goal is deemed most
important: Keep ISVs and spare-time-investors happy or motivate a new
generation of hackers to pick up, the coolness that could be, Gtk.

Cheers,
Mikkel
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Morten Welinder-2]

> It is just not cool to use Gtk.

I think that pretty much hits it on the nail.  Some people want a cool
project to work on.  By all means, go ahead!  Fork gtk+ to something
new, cool, fancy.  But leave existing gtk+ bugzilla and svn module
alone.

> In the end it comes down to which goal is deemed most
> important: Keep ISVs and spare-time-investors happy or motivate a new
> generation of hackers to pick up, the coolness that could be, Gtk.

Do you really think saying "Fuck you!" to your application developers
every 3-4 years is going to attract an enthusiastic crowd?

Morten


> 1) How does *anything* break?

The constant deprecation and removal of (boring, ugly, unmaintained,
unsexy, but working-as-well-as-yesterday) code means that you put
application developers into a bad spot: my source code will not work
with both old and new gtk+.  Since new gtk+ only gets deployed years
after it hits svn, that means maintaining two versions.  Or screwing half
my user base.  Not fun.

Using the newest APIs is not really a viable choice for application
developers unless it is for functionality that is not essential.  (GtkRecent
fails into that category, for example.  We will use it if it is there.  If not,
you don't get recent file support.)
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Xan Lopez-2]

On Thu, Jul 17, 2008 at 3:59 PM, Morten Welinder <mortenw@...> wrote:
>> It is just not cool to use Gtk.
>
> I think that pretty much hits it on the nail.  Some people want a cool
> project to work on.  By all means, go ahead!  Fork gtk+ to something
> new, cool, fancy.  But leave existing gtk+ bugzilla and svn module
> alone.
>

This is exactly what they are doing, that's why they call it GTK+ 3.0,
or 2.99.0, or whatever. You are free to keep using and maintaining the
2.x series for as long as you need. Now, if you'd like *others* to
spend *their* time doing what *you* would like them to do, well,
that's different.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Thu, 2008-07-17 at 16:02 +0100, Xan wrote:

> This is exactly what they are doing, that's why they call it GTK+ 3.0,
> or 2.99.0, or whatever. You are free to keep using and maintaining the
> 2.x series for as long as you need. Now, if you'd like *others* to
> spend *their* time doing what *you* would like them to do, well,
> that's different.

i think the problem is midway between these two. Developers using GTK+
would like developers of GTK+ to do the new, good stuff that one or
other or both groups are fired up about. but they'd like it done in a
way that doesn't negatively affect them.

so the developers of GTK+ have said "we can't do that without dealing
the public/private issues in the current API", and so we have G_SEAL.
this provides a transitioning bridge from things-that-should-never-
have-been-public-but-were to the new world of only-public-things-are
actually-public. this is fair enough.

i think the problem is one of perception. its not obvious to most
developers using GTK+ how the public/private stuff really impacts work
on the things they'd like to see addressed in GTK+. to many of us, its
not clear why its necessary to move to 3.0 to get substantive stuff
done. its not that we know we're right, its that we just don't get the
justification.

a few more specific examples would probably help to clear the air of
this question. kris gave us one slightly hand-wavy one. can anybody
offer some more?

as far as deprecated stuff goes, i have to confess that i am in total
agreement with its (pre-announced) removal.

--p


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Martin Meyer]

Several people have mentioned the "move the deprecated stuff into a
separate library" idea. Can we get some concrete answers on:

1) Would this satisfy the various apps still using the deprecated
code? i.e. is it OK to depend on this different library in the future
in addition to gtk-3? Are there any arguments against this, aside from
the effort/time involved?

2) Is it entirely possible from a gtk perspective to have all that
code detached from gtk-core and placed in a different library? Are
there any deprecated things that this would *not* work for? Maybe we
can detach as many as possible and leave the rest in place for now.

3) How long / how much effort would it be do to this? Is it something
that has to be done by experienced GTK hackers or can it be handled as
a side project?

Martin

On Thu, Jul 17, 2008 at 11:12 AM, Paul Davis <paul@...> wrote:

>
> On Thu, 2008-07-17 at 16:02 +0100, Xan wrote:
>
>> This is exactly what they are doing, that's why they call it GTK+ 3.0,
>> or 2.99.0, or whatever. You are free to keep using and maintaining the
>> 2.x series for as long as you need. Now, if you'd like *others* to
>> spend *their* time doing what *you* would like them to do, well,
>> that's different.
>
> i think the problem is midway between these two. Developers using GTK+
> would like developers of GTK+ to do the new, good stuff that one or
> other or both groups are fired up about. but they'd like it done in a
> way that doesn't negatively affect them.
>
> so the developers of GTK+ have said "we can't do that without dealing
> the public/private issues in the current API", and so we have G_SEAL.
> this provides a transitioning bridge from things-that-should-never-
> have-been-public-but-were to the new world of only-public-things-are
> actually-public. this is fair enough.
>
> i think the problem is one of perception. its not obvious to most
> developers using GTK+ how the public/private stuff really impacts work
> on the things they'd like to see addressed in GTK+. to many of us, its
> not clear why its necessary to move to 3.0 to get substantive stuff
> done. its not that we know we're right, its that we just don't get the
> justification.
>
> a few more specific examples would probably help to clear the air of
> this question. kris gave us one slightly hand-wavy one. can anybody
> offer some more?
>
> as far as deprecated stuff goes, i have to confess that i am in total
> agreement with its (pre-announced) removal.
>
> --p
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>

--
Laurence J. Peter  - "Originality is the fine art of remembering what
you hear but forgetting where you heard it."
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tim Janik-2]

On Thu, 17 Jul 2008, Martin Meyer wrote:

> Several people have mentioned the "move the deprecated stuff into a
> separate library" idea. Can we get some concrete answers on:
>
> 1) Would this satisfy the various apps still using the deprecated
> code? i.e. is it OK to depend on this different library in the future
> in addition to gtk-3? Are there any arguments against this, aside from
> the effort/time involved?

It'd certainly reduce the pain for application developers that still use
deprecated widgets such as CTree or ItemFactory.

> 2) Is it entirely possible from a gtk perspective to have all that
> code detached from gtk-core and placed in a different library? Are
> there any deprecated things that this would *not* work for? Maybe we
> can detach as many as possible and leave the rest in place for now.

Complete deprecated widgets should be fairly easy to separarte,
single deprecated functions that some components may have can be
hard to impossible to move when the implementation requires
access to internals.

> 3) How long / how much effort would it be do to this? Is it something
> that has to be done by experienced GTK hackers or can it be handled as
> a side project?

I think any moderately experienced developer could tackle this (e.g.
someone who has implemented his own widget at some point).

A closing word on the library name, since this'd be an ABI break,
such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
probably advertise that it ships deprecated Gtk+ stuff. So the best
name is probably libgtk3deprecated for this (there could possibly
be a libgtk4deprecated as well at some point).

> Martin

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Sven Herzberg]

Hi,

Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik:

> On Thu, 17 Jul 2008, Martin Meyer wrote:
> > 2) Is it entirely possible from a gtk perspective to have all that
> > code detached from gtk-core and placed in a different library? Are
> > there any deprecated things that this would *not* work for? Maybe we
> > can detach as many as possible and leave the rest in place for now.
>
> Complete deprecated widgets should be fairly easy to separarte,
> single deprecated functions that some components may have can be
> hard to impossible to move when the implementation requires
> access to internals.

But this could be worked around with a strange compile setup, right?
With something like this:
~/sources/gtk+
~/sources/gtk-deprecated
and gcc -I$(top_srcdir)/../gtk+/gtk
to access potential gtkwidgetpriv.h, right? Would mean "recompile with
every source change to gtk+" but if some (many?) people depend on this,
I think they can easily distribute the burden of maintaining a parallel
version.

> A closing word on the library name, since this'd be an ABI break,
> such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
> probably advertise that it ships deprecated Gtk+ stuff. So the best
> name is probably libgtk3deprecated for this (there could possibly
> be a libgtk4deprecated as well at some point).

Well, so GTK+ 4.0 could be accompanied by these two:
libgtk3deprecated-4.0.so
libgtk4deprecated-3.0.so
Right?

Regards,
  Sven

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tim Janik]

On Thu, 17 Jul 2008, Sven Herzberg wrote:

> Hi,
>
> Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik:
>> On Thu, 17 Jul 2008, Martin Meyer wrote:
>>> 2) Is it entirely possible from a gtk perspective to have all that
>>> code detached from gtk-core and placed in a different library? Are
>>> there any deprecated things that this would *not* work for? Maybe we
>>> can detach as many as possible and leave the rest in place for now.
>>
>> Complete deprecated widgets should be fairly easy to separarte,
>> single deprecated functions that some components may have can be
>> hard to impossible to move when the implementation requires
>> access to internals.
>
> But this could be worked around with a strange compile setup, right?
> With something like this:
> ~/sources/gtk+
> ~/sources/gtk-deprecated
> and gcc -I$(top_srcdir)/../gtk+/gtk
> to access potential gtkwidgetpriv.h, right? Would mean "recompile with
> every source change to gtk+" but if some (many?) people depend on this,
> I think they can easily distribute the burden of maintaining a parallel
> version.

There is no point in having libgtk3deprecated access gtk+ internals and
not go through public interfaces only. If we did that, we'd simply preserve
the maintenance burden on Gtk+ internal definitions. We really want to
get rid of a bunch of stuff, be free to refactor structures and internal
methods to implement new things cleanly. If libgtk3deprecated kept acessing
and relying on internals it'd either constantly break or hinder us on doing
reorganisations.

Also, this'd tie release cycles and maintenance resources of libgtk3deprecated
closely to Gtk+ again. The main point in seperating deprecated code is to
load off the core team though, so application developers or distributors
that still have an interest in deprecated components can take over its
maintenance as long as that's necessary.

>> A closing word on the library name, since this'd be an ABI break,
>> such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
>> probably advertise that it ships deprecated Gtk+ stuff. So the best
>> name is probably libgtk3deprecated for this (there could possibly
>> be a libgtk4deprecated as well at some point).
>
> Well, so GTK+ 4.0 could be accompanied by these two:
> libgtk3deprecated-4.0.so
> libgtk4deprecated-3.0.so
> Right?

I'd guess that if deprecated 2.x components that landed in libgtk3deprecated
are still required when a libgtk4deprecated is released, they could
possibly need some porting and simply be included as real parts of
libgtk4deprecated. This is highly speculative though and can be considered
when we have the Gtk+-4.0 discussion. We're not quite there yet ;)

> Regards,
>  Sven

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Owen Taylor]

On Thu, 2008-07-17 at 13:15 +0200, Colin Leroy wrote:

> On Thu, 17 Jul 2008 12:55:59 +0200, Mikael Hallendal wrote:
>
> Hi,
>
> > A suggestion that came up in the post-guadec discussions was to move  
> > deprecated widgets to libgtk3-compat instead of removing them. This  
> > means that applications using these will have to add that as a  
> > dependency to his code base in order to continue using them. Off the  
> > top of my head this sounds like a good suggestion to me.
>
> Indeed.
>
> > The 1.x -> 2.0 change was painful for everyone who had an app that  
> > needed porting, however I find it pretty irrelevant in comparison to  
> > 2.x -> 3.0.
>
> Well, if no libgtk-compat is planned, it will be about as painful
> for users of the deprecated and removed widgets/functions.

Possibly the constructive question here is:

 What sort of messaging would have convinced you to have moved
 away from the deprecated widgets?

I don't see the virtue of a gtk1-compat library... it's just shuffling
non-maintainership around forever. I'd suggest people can just cut,
paste, and rename the things into their own code if they are so
attached to the code.

- Owen


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Hans Breuer]

Am 18.07.2008 15:32, Owen Taylor schrieb:
> On Thu, 2008-07-17 at 13:15 +0200, Colin Leroy wrote:
[...]

>>> The 1.x -> 2.0 change was painful for everyone who had an app that  
>>> needed porting, however I find it pretty irrelevant in comparison to  
>>> 2.x -> 3.0.
>> Well, if no libgtk-compat is planned, it will be about as painful
>> for users of the deprecated and removed widgets/functions.
>
> Possibly the constructive question here is:
>
>  What sort of messaging would have convinced you to have moved
>  away from the deprecated widgets?
>

For me the answer is simple (being application developer for Dia and
longtime gtk+/win32 contributor): porting Dia to gtk+-2.0 and keeping
gtk+-2.0 useable for win32 just did not leave enough spare time to keep
pace with all the deprecations ;)

> I don't see the virtue of a gtk1-compat library... it's just shuffling
> non-maintainership around forever.
My attempt to a constructive answer is: just let the people who need the
compatibility keep gtk-2.x alive within the GNOME infrastructure.

For this it would be very helpful to have a clean release of gtk+-2.x
including all the GSEAL stuff but also compatibiity to continue iterative
porting before gtk+-3.0 gets released, which would break compatibility.

For me the hardest part in the transition from 1.2 to 2.0 was the lack of
gtk+-1.4 which would have included all the win32 porting done on 1.3
without the API breakages.

> I'd suggest people can just cut,
> paste, and rename the things into their own code if they are so
> attached to the code.
>
IMO having this deprecated stuff copied and pasted into a lot of
applications would be a distributed maintenance nightmare.

Regards,
        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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[muppet]

Hans Breuer wrote:
>
> Am 18.07.2008 15:32, Owen Taylor schrieb:
>> I don't see the virtue of a gtk1-compat library... it's just shuffling
>> non-maintainership around forever.
> My attempt to a constructive answer is: just let the people who need the
> compatibility keep gtk-2.x alive within the GNOME infrastructure.

A flaw in that logic is that the people who need the compatibility likely need
it due to lack of resources to port to the new version, and therefore would be
unable to contribute resources to maintenance of the toolkit.

People most dearly affected by forging ahead with ABI breaks are users of good
but "finished" (or sometimes simply abandoned) applications.  The users who
want it will not be able to help maintain an old version of gtk; you're more
likely to have people just reinvent the wheel.

(Sometimes you get a better wheel.  Sometimes the old wheel was far superior.)

--
muppet <scott at asofyet dot org>

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Cody Russell-2]

On Thu, 2008-07-17 at 20:18 +0200, Tim Janik wrote:
>
> I think any moderately experienced developer could tackle this (e.g.
> someone who has implemented his own widget at some point).

I -might- be willing to volunteer for this if nobody else does.  But if
I do I want to make it clear that I would be investing the initial
effort into getting it setup and building, I would absolutely not be
committing myself to maintain it.  I feel that application developers
who are still using it can take that responsibility.

> A closing word on the library name, since this'd be an ABI break,
> such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should
> probably advertise that it ships deprecated Gtk+ stuff. So the best
> name is probably libgtk3deprecated for this (there could possibly
> be a libgtk4deprecated as well at some point).

I vote for libgtk3graveyard, just to really drive the point home. :)

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list