Re: About GTK+ 3.0 and deprecated things

[Kristian Rietveld <kris gtk org>]

On Wed, Jul 16, 2008 at 06:08:58PM -0400, Paul Davis wrote:
> On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote:
> 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?

There's no completely new implementation of the GtkTreeView waiting in
the wings.  I do have started an experimental "version" of it over a
year ago, which is more or less a branch of GTK+ now where I want to
experiment with new features/API.  For me, it is much easier to play
with new things (whether or not compatibility breaking) here, have them
mature and then look into backmerging in the current GTK+ development
branch.  As a result of a lack of spare time not all that much has
happened here yet.

A large part right now are refactorings/code cleanups to the layouting
and rendering code, which might make their way into GTK+ once I have
proper unit testing for this in place.  In my experimental branch, these
refactorings are serving as a basis to look into designing and
implementing new features that touch the rendering system.

I've never refused to look at the tree view DnD code in 2.X; why it has
not happened yet is again a lack of time and other bug fixes that were
more important to get done first.  I have said that once I would get to
changing the DnD system, I would first design and implement this in my
experimental branch and then look into backmerging this into the gtk+
development branch piece by piece.  Recently I have been reading up on
the current state of the DnD code (I did an attempt to improve it in
2004 or so) and hope to get to experimenting with it during the Summer.

Whether or not we need GSEAL() for changes in tree view is two-fold;
GtkTreeView has been introduced in 2.0 with a "priv" pointer in place
and no other fields public.  However, GtkTreeViewColumn's structure is
filled with fields and out there in the public; by the time we want to
change the construction of the header or re-engineer the column
size-allocation/requisition mechanism (these are just two examples), we
can not do so compatibly.



regards,

-kris.