Re: gdkcursors.h

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 25 Nov 2001, Owen Taylor wrote:
> 
> > "Matthias Clasen" <matthiasc poet de> writes:
> > 
> > > Is there a reason to definition the GdkCursorType enumeration in the way it
> > > is
> > > done currently, by including gdkcursors.h inside the enumeration ?
> > 
> > Well, it's done for the sake of the X-derived-headers rule in
> > gdk/Makefile.am, but since:
> > 
> >  * I doubt the set of X cursor defines will _ever_ change.
> >  * If it did, we wouldn't want that to imply a change in the
> >    GDK API accidentally. (We have a problem in gdkkeysyms.h
> >    in that a bunch of non-standard XFree86 only keysyms 
> >    snuck in at some point during the 1.3.x series.)
> 
> erm, a) what are those keysyms, b) what's holding you off from backing those
> out again (removing non-portable symbols shouldn't be locked by API freeze)?

a) 

 GDK_Ukrainian_ghe_with_upturn GDK_Ukrainian_GHE_WITH_UPTURN
 GDK_Armenian_eternity ... GDK_Armenian_ligature_ew
 GDK_Georgian_an ... GDK_Georgian_fi

 (136 symbols total) All these key symbols are not part of the X protocol, 
 and are unlikely to be added. (New key symbols corresponding to Unicode
 characters should be encoded as 'wc + 0x01000000')

 [ More background in bug #65088 ]

b) 
 
 Well, strictly speaking, I think that this _is_ covered by the API
 freeze, but was planning to make them silently vanish anyways on the
 idea:
  
 - that the chance of anyone hardcoding GDK_Armenian_ligature_ew
   into their programs yet is vanishingly small.
 - also, if they don't vanish, they need to be deprecated, which is a
   bit of a pain, considering the semi-automated generation of the file.
 - they aren't really GDK_DISABLE_DEPRECATED, but GDK_ENABLE_BROKEN
   level, since using them is actively harmful.

Regards,
                                        Owen