Re: Big GDK cleanup

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 7 Sep 2001, Owen Taylor wrote:
> 
> > I'm about to commit a huge patch to clean up GDK. This will, 
> > unfortunately, probably cause minor build breakage for Win32
> > and linux-fb until someone fixes stuff, and fairly large
> > (though mechanical to fix) conflicts when next merging
> > head changes into the multihead patch.
> 
> [...]
> 
> > The total effect of this change on exports for libgdk-x11 is:
> > 
> > # total symbols 
> > nm /usr/lib/libgdk-x11-1.3.so | wc 
> >     544    1632   17742
> > gdk$ nm .libs/libgdk-x11-1.3.so | wc
> >     494    1482   16378
> > 
> > # exported variables
> > nm /usr/lib/libgdk-x11-1.3.so | grep '\<\(D\|B\)\>' | wc
> >      38     114    1062
> > nm .libs/libgdk-x11-1.3.so | grep '\<\(D\|B\)\>' | wc
> >       2       6      52
> 
> ok, in principle i apprechiate that change.
> but since this involves a huge API change for apps that have to freak
> around with x11 specific gdk internals (i doubt there's much out there
> in that category for win32 or fb), we should probably port a few of those
> to 1.3 before sanctionizing all changes you made. (what comes to my mind
> imediately is desk-guide or gdk-using wms).

To quote my Changes-2.0.txt entry:

* The following variables are no longer exported from GDK. (Other variables
  are also no longer exported; the following are the ones found used
  externally in a large sample of GTK+ code.)

   Variable                               Replacement
   ========                               ===========
   gdk_null_window_warnings               None - did nothing in GTK+-1.2.
   gdk_leader_window                      None - private variable
   gdk_screen                             gdk_x11_get_default_screen ()
   gdk_root_window                        gdk_x11_get_default_root_xwindow ()
   gdk_root_parent                        gdk_get_default_root_window ()
   gdk_error_code/gdk_error_warnings      gdk_error_trap_push()/pop()
   gdk_display_name                       gdk_get_display ()
   gdk_wm_delete_window                   gdk_atom_intern ("WM_DELETE_WINDOW", FALSE)
   gdk_wm_take_focus                      gdk_atom_intern ("WM_TAKE_FOCUS", FALSE)
   gdk_wm_protocols                       gdk_atom_intern ("WM_PROTOCOLS", FALSE)

Of those 10 changes:

 gdk_null_window_warnings/gdk_leader_window/gdk_wm_*

Were never intended to be exported and had no legitimate uses,
though they were referenced in a few places in GNOME CVS.

 gdk_root_window/gdk_root_parent 

Had macros that they were supposed top be accessed through. 
(Same for gdk_display, but I decided to leave it alone since
it was used so much not via the macro.)

So, the only actual source-compat breakages breakages that
properly written code might use are:

 gdk_error_code/gdk_error_warnings (substitute was there
   in 1.2, but there is old code that hasn't been converted.)

 gdk_screen (no macro for this was ever added.)

We aren't talking a lot of places here ... and its in the 
most low-level, hacky, written-by-GNOME-insiders portions
of code.

I don't believe that there is any reason for concern on
this issue, though, the sooner people start porting the
better :-) 

> > Which I think represents a significant improvement in cleanly defining
> > our interfaces and making sure that we can maintain binary compatibility
> > in the future. (Removing the exported structures is even more important
> > for this purpose.)
> 
> hum, what huge binary incompat changes are you pondering about for 2.0.x?
> or did you mean "source compatibility" for 2.x?

While I don't want to get into a big 2.2 discussion here, I 
believe it is _strongly_ in our interests to do a source
compat feature addition release in a short (hopefully 6-9 month) 
timescale. Such a release needs to also be binary compatible:

 - Breaking binary compatibility would require maintaining bug
   fixes for the 2.0 branch for another 1-2 years. Since we are  
   also going to have to maintain 1.2, I believe this is
   a burden we aren't equiped to handle.

 - A binary incompatible release requires considerably more
   engineering related to parallel installs. 

 - A binary incompatible release doubles the number of packages
   that every distribution has to maintain, and doubles
   the memory footprint until everything is ported. 
   
We simply can't go around breaking binary compatibility every 6
months, or every year, and I can't see waiting a couple of years for
another release. There are a bunch of issues we can and should fix in
the short term:

 - Multihead suport
 - File selector widget
 - Replacement for OPtionMenu and ComboBox
 - Action based menu API 

These are all straightforward API additions, and there should
be no problem at all doing them in a binary compatible fashion.

Regards,
                                        Owen