About GTK+ 3.0 and deprecated things

[Colin Leroy]

Hello,

I've read the PDF at
http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf

I am wondering what the options will be for users of the GTK lib, that
still use deprecated widgets?

In the project I work for, we do have a lot of them:

[claws-mail/src]$ grep -r GtkItemFactory *|wc -l
163
[claws-mail/src]$ grep -r GtkTooltips *|wc -l
61
[claws-mail/src]$ grep -r GtkCTree *|wc -l
670
[claws-mail/src]$ grep -r GtkCList *|wc -l
198

They're used all over the place and in very central places of the code.
Rewriting them to use newer, non-deprecated widgets would require a
scary number of man-hours of un-fun work, introduce new bugs, and would
take all of our (we're three core developers) energy to re-do work we've
already done.

We went through this when migrating from GTK+ 1 to GTK+ 2 already. We
don't want to do it again.

What do you plan on doing for users of your toolkit who don't have time
to rewrite things every four years?
--
Colin
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Mathias Hasselmann-2]

Am Mittwoch, den 16.07.2008, 09:16 +0200 schrieb Colin Leroy:

> What do you plan on doing for users of your toolkit who don't have
> time to rewrite things every four years?

One obvious option would be to stay with GTK2 forever, and to take over
bug fixing for it.

Another **rough** idea I always had in mind is moving all that
deprecated code into some libgtk-compat library: Obviously this approach
would not work for structure fields, but it should be trivial for
entirely deprecated classes.  This approach also should be support
deprecated functions. Obviously those deprecated functions would suffer
from the fact, that they cannot access internal data structures anymore.
So for functions that cannot be easily be ported maybe just some stub
yielding linker warnings would be created in that compat library.
Filling that stub would be the task of people willing to use that
deprecated function (instead of porting their code).

Ciao,
Mathias
--
Mathias Hasselmann <mathias.hasselmann@...>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


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

[Bastien Nocera]

On Wed, 2008-07-16 at 09:16 +0200, Colin Leroy wrote:

> Hello,
>
> I've read the PDF at
> http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf
>
> I am wondering what the options will be for users of the GTK lib, that
> still use deprecated widgets?
>
> In the project I work for, we do have a lot of them:
>
> [claws-mail/src]$ grep -r GtkItemFactory *|wc -l
> 163
> [claws-mail/src]$ grep -r GtkTooltips *|wc -l
> 61
> [claws-mail/src]$ grep -r GtkCTree *|wc -l
> 670
> [claws-mail/src]$ grep -r GtkCList *|wc -l
> 198

<snip>
> We went through this when migrating from GTK+ 1 to GTK+ 2 already. We
> don't want to do it again.

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.

The tooltips should be easy to port, the tree and list widgets less so,
which is why it should have started quite some time ago...

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

[Colin Leroy]

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.
 
> The tooltips should be easy to port, the tree and list widgets less
> so, which is why it should have started quite some time ago...

and the GtkItemFactory are huge to port too. And probably there is
more; I've just looked at the first batch of compilation errors using
GTK_DISABLE_DEPRECATED.

As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good
idea and (in my application developer's opinion) least that can be done
for the users of the GTK+ lib.

There are 2017 applications on http://gnomefiles.org/ ; how many of
these projects have the available manpower to rewrite their code? How
many of these are projects are run by enthusiasts on their free time ?

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

[Mikael Hallendal]

Colin Leroy skrev:
> On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:

Hi,

> 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.
>  
>> The tooltips should be easy to port, the tree and list widgets less
>> so, which is why it should have started quite some time ago...
>
> and the GtkItemFactory are huge to port too. And probably there is
> more; I've just looked at the first batch of compilation errors using
> GTK_DISABLE_DEPRECATED.
>
> As Mathias said, a libgtk-legacy (or -compat or whatever) seems a good
> idea and (in my application developer's opinion) least that can be done
> for the users of the GTK+ lib.

Having a libgtk-compat library sounds like a good idea. We discussed it
during Guadec a year or two ago but the discussion was then about
whether it would be possible to move the deprecated calls into a
separate library without breaking ABI which from my understanding it
isn't on Linux.

It sure would lessen the burden for applications still using deprecated
widgets (which is the hard part of the ABI break).

Cheers,
   Mikael

--
Mikael Hallendal
Imendio AB - Expert solutions in GTK+
http://www.imendio.com
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Colin Leroy]

On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote:

Hi,

> It sure would lessen the burden for applications still using
> deprecated widgets (which is the hard part of the ABI break).

Well, the hardest part in my opinion, for free software at least, is the
API break :-)

There's something unclear from the State of the union slides I've read
(I wasn't at GUADEC...); What will happen to GTK+2 when GTK+3 is out ?

If it's continuing its life as a bugfix-only branch, the problem from
my (app developer's) point of view is not as important...
--
Colin
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Mikael Hallendal]

Hi,

16 jul 2008 kl. 12.33 skrev Colin Leroy:

> On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote:
>
> Hi,
>
>> It sure would lessen the burden for applications still using
>> deprecated widgets (which is the hard part of the ABI break).
>
> Well, the hardest part in my opinion, for free software at least, is  
> the
> API break :-)

Sorry yes, meant the API break :)

> There's something unclear from the State of the union slides I've read
> (I wasn't at GUADEC...); What will happen to GTK+2 when GTK+3 is out ?

I think that comes down to whether people are interested in investing  
in GTK+ 2.x (either with resources or money).

Cheers,
   Mikael

--
Mikael Hallendal
Imendio AB - Expert solutions in GTK+
http://www.imendio.com





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

[Paul Davis]

On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote:

> 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.

No offense, but we went through a very similar process with Ardour (very
similar time duration anyway), yet one of the top priority items for us
was to remove CList and CTree and switch to TreeView as soon as we had
figured out how to use it. It seemed VERY clear to us that the
deprecated state of CList and CTree made that extremely important. I
would not have considered a release that had not transitioned to
TreeView and for the most part, the widget has been good to us (or it
was, until we started work on the native OS X version).

For ItemFactory, we made the switch to GtkActions and the UIManager,
which massively improved the design of our software (albeit in ways that
I think the rest of Gtk still needs to catch up with, especially key
handling).

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

[Owen Taylor]

On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote:

> 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.

Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
(e.g., I remember doing that for gftp, not a trivial app.)

Porting to GtkCList and GtkCTree was was the main thing that took
significant work.

So, I'm not really sure what you were doing for 497 commits...

- Owen


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

[Johan Dahlin-2]

Owen Taylor wrote:

> On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote:
>> 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.
>
> Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
> (e.g., I remember doing that for gftp, not a trivial app.)

Ditto, I remembered doing devhelp and helping out doing a couple of
dialogs in nautilus.

Hopefully we'll have refactoring tools ready for the 3.0 transition which
makes the process roughly similar.

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

[Colin Leroy]

On Wed, 16 Jul 2008 09:25:43 -0400, Owen Taylor wrote:

Hi,

> Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
> (e.g., I remember doing that for gftp, not a trivial app.)

Probably not trivial, but 30k LOCs is much less than Claws ;)

> Porting to GtkCList and GtkCTree was was the main thing that took
> significant work.
>
> So, I'm not really sure what you were doing for 497 commits...

We had work on: switch to GtkTextView, font selection, charset-related
things, GtkCombo(Box(Entry)), pixmap stuff, file selector,
accelerators, changed signal handlers...
These 500 commits were not only porting work, there were also syncs
with the gtk1 branch and bugfixes; still it took us 2 years to be
confident enough to release our first GTK2 version.

Anyway, I didn't come here to complain about the past, but rather to
try and avoid repeating it :)
--
Colin
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

> Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
> (e.g., I remember doing that for gftp, not a trivial app.)

That sounds like a serious case of selective memory.  Or maybe gftp
has the ui from "hello, world".

Here's a partial list of suffering that we went through.  Let's see...

* All widgets has to be reworked and audited.  There was new reference
  handling and double destroy calls added to the trouble.

* All glade files needed to be redone, or at the very least subjected to
  heavy post-translation surgery with Emacs and Perl.

* All code needed to be audited for UTF-8.

* All font handling had to be reworked.  Drawing changed too.

* Whenever something crashed, leaked, or otherwise simply did not work,
  we had to audit not only our own code, but glib, pango, and gtk+ too.
  There were piles and piles of bugs in the new code.

* We had to struggle with sluggishness of the resulting gtk2 application.

The above is just what I can remember off the bat and is *before*
changing to use the new widgets of gtk2, some of which were only
partial replacements of what they deprecated: the tree view, for
example, was touted as right for all kinds of tables, but it has
become clear that it cannot handle large ones.

Gnumeric has about 34k lines dedicated to dialogs, not including code
that implements the actions of those dialogs.  Add to that 20k lines of
widgets and another 20k lines of further gui code.  That excludes code
for graphs.  You just do not audit that in a weekend or two.

You want us to go through some variant of that every 3-4 years?  That's
insane!

What, exactly, is it that is hard about maintaining 2.x that will not be
hard for 3.x?  I have seen nothing but unsubstantiated assertions
about this.  What I have observed is that sub-systems like GtkPrint
get dumped in and abandoned right away.  With bayesian mind
that tells me that the maintenance situation will not be better for 3.x

What really bothers me is that people go out of their way to break working
code.  Looking at svn logs tells me that the effort of keeping the old widgets
and methods around is minimal.  It's not just the old gtkclist -- the recently
deprecated gtktooltips shows the same thing.  The second unsubstantiated
assertion is that the deprecated widgets cause a lot of maintenance work
beyond the self-inflicted pain of deprecation.  The data does not support
that assertion.

I would like to see all this gtk3 talk pushed 3-4 years out into the future.
There are lots of things that need to be fixed and introducing new,
buggy code elsewhere is not going to fix it.  If that means the world
will have to wait for animated, semi-transparent widgets, then that
would be fine.  No real work will get done of behalf of those features
anyway.

Morten Welinder

PS: For whatever it's worth, GnuCash also took years to go gtk2.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote:

> PS: For whatever it's worth, GnuCash also took years to go gtk2.

and in case i didn't make it clear enough early, Ardour also. we had the
exact same set of issues as mentioned by morten and colin. some of the
2yr period, though, was caused by us expanding our idea of what we could
do with the toolkit, so its not entirely fair to blame GTK2 for the
entire time.

i totally agree with those who are arguing against the current notion of
what GTK3 should be. i haven't seen any evidence that any of the
problems that our developers face with GTK are going to be easier to
address after the proposals for 3.0 are complete, with the possible
exception of themeing. it is suggested that once G_SEAL etc. is
complete, it will become easier to "fix the problems". i've mentioned
our problems before ... once again, none of the people working on GTK
have ever said to me "oh, once 3.0 is done that will be much easier to
fix". the closest might be kris' refusal to look at the treeview DnD
situation in 2.X because he has a completely new implementation of the
entire widget (family) waiting in the wings. does this need G_SEAL to
make it work?

i would much rather see a version of GTK that makes real progress toward
solving the actual problems faced by its current users (and developers),
rather than making theoretical progress towards future problems that
might be faced down the road. and in fact, to be honest the biggest
issues we have with GTK right now don't even come from any forward
progress, but from the fact that we're trying to get gtk/quartz
stabilized and usable.

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

[Sven Herzberg]

Hi,

Am Mittwoch, den 16.07.2008, 18:08 -0400 schrieb Paul Davis:

> On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote:
> i totally agree with those who are arguing against the current notion of
> what GTK3 should be. i haven't seen any evidence that any of the
> problems that our developers face with GTK are going to be easier to
> address after the proposals for 3.0 are complete, with the possible
> exception of themeing. it is suggested that once G_SEAL etc. is
> complete, it will become easier to "fix the problems". i've mentioned
> our problems before ... once again, none of the people working on GTK
> have ever said to me "oh, once 3.0 is done that will be much easier to
> fix". the closest might be kris' refusal to look at the treeview DnD
> situation in 2.X because he has a completely new implementation of the
> entire widget (family) waiting in the wings. does this need G_SEAL to
> make it work?

Paul, just in case this wasn't made clear enough already; the GTK+ team
want to deploy a GTK+3 that will be API-compatible to the latest GTK+2
including all deprecation flags that are there (disable deprecated,
multihead safe, single header include, etc.).

There are these simple things you can do to get your app easily 3.0
compatible:

1. make sure your application compiles with these flags
2. if you use deprecated/considered-broken widgets/classes, copy them
into your project and change the namespace from gtk to your project's
namespace.

After that, everything should be fine. Plus I heard rumors about some
refactoring tools being developed so we (app developers) can easily get
our code compatible for 3.0.

The reference counting pains and the GtkArgs removal etc. were a REAL
pain (compared to the points above), also adding lots of new code. But
with GTK+3, there are no evil changes like this queued.

Regards,
  Sven

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

[Matthias Clasen-2]

On Wed, Jul 16, 2008 at 4:51 PM, Morten Welinder <mwelinder@...> wrote:

[ lots of whining cut out]

>
> You want us to go through some variant of that every 3-4 years?  That's
> insane!

GTK2 is not going away any time soon. Enterprise distributions will have
to keep it alive in maintenance mode for a long time to come (RHEL 5
is still shipping gtk 1.2).

> What, exactly, is it that is hard about maintaining 2.x that will not be
> hard for 3.x?  I have seen nothing but unsubstantiated assertions
> about this.  What I have observed is that sub-systems like GtkPrint
> get dumped in and abandoned right away.  With bayesian mind
> that tells me that the maintenance situation will not be better for 3.x

Nothing that is hard about maintaining 2.x will not be hard for 3.x.
The argument that the proponents of the current 3.x agenda make is
that the current state of the code makes it increasingly impossible to add
new features.

Regarding your GtkPrint comment, I have to point out that moving increasing
amounts of the platform into GTK+ does not magically grow the GTK+
maintainership at the same rate. You could improve the situation by sending
a patch every once in a while...you do seem to have enough time to do
statistical analysis on the GTK+ svn logs, after all :-)


Matthias
_______________________________________________
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 04:11 +0200, Sven Herzberg wrote:

> Paul, just in case this wasn't made clear enough already; the GTK+ team
> want to deploy a GTK+3 that will be API-compatible to the latest GTK+2
> including all deprecation flags that are there (disable deprecated,
> multihead safe, single header include, etc.).

if its API compatible, why a change in major version numbers?



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

[Andrew Cowie]

On Wed, 2008-07-16 at 23:03 -0400, Paul Davis wrote:
> if its API compatible, why a change in major version numbers?

As I understand it, because:

a) they're removing all the deprecated stuff, and

b) the API sill start changing after 3.0 in ways that won't be
compatible with < 3.0

All good.

AfC
Sydney



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

[Mikael Hallendal]

Hi,

Because the ABI is incompatible. Apps will need to be recompiled  
against the new version.

Also, it is not API compatible with latest GTK+ without the flags.

Cheers,
   Micke

17 jul 2008 kl. 05.03 skrev Paul Davis:

>
> On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote:
>
>> Paul, just in case this wasn't made clear enough already; the GTK+  
>> team
>> want to deploy a GTK+3 that will be API-compatible to the latest GTK
>> +2
>> including all deprecation flags that are there (disable deprecated,
>> multihead safe, single header include, etc.).
>
> if its API compatible, why a change in major version numbers?
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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