Integrating GFC into Xfce

[Jeff Franks]

Brian J. Tarricone wrote:

> Jeff Franks wrote:
>
>> Can I use the current GFC scheme (same as gtkmm)  which uses the 
>> <major + minor> version numbers as a suffix.
>>
>> $includedir/xfce4/xfc-4.4/xfc/... for the header files
>>
>> and
>>
>> xfccore-4.4.pc and xfcui-4.4.pc
>>
>> then in Xfce 4.6 it could be
>>
>> $includedir/xfce4/xfc-4.6/xfc/... for the header files
>>
>> and
>>
>> xfccore-4.6.pc and xfcui-4.6.pc
>
>
> i'd prefer it if you didn't.  i don't really see the point.  for one 
> thing, if the libraries aren't versioned such that you can keep 4.4, 
> 4.6, etc. in parallel, this isn't useful at all, and could cause 
> problems.  secondly, we won't be breaking binary (or source) compat 
> until 5.0, so there's no need to keep around older headers.

Benedikt had suggested I use $includedir/xfce4/xfc-1/xfc/... for the 
header files and xfccore4-1.pc (or something similar) for .pc files so 
as to allow parallel installs. If XFC uses the Xfce version numbering it 
must also use the same minimum GTK+ dependancy. This would mean that the 
XFC binding would always tend to be behind GTK+ wrt newer widgets which 
could not be included until the current Xfce version increments its 
minimum GTK+ dependancy. How do you see this working?

>
> speaking of binary compat... i think you mentioned earlier that your 
> wrappers don't include deprecated gtk widgets like GtkOptionMenu.  
> this isn't a problem for us, since, as you mention, we use gtk 
> directly in xfce, and not your wrapper.  but still, i think it's 
> generally a bad practice.  if people see a binding that claims to be 
> compatible with gtk 2.4, they'll logically assume that it's also 
> compatible with 2.2 and 2.0, since gtk itself follows this policy.

GTK+ has deprecated these (and other) widgets and recommends that new 
code not use them because eventually they will be removed, possibly in 
GTK+ 3.0. XFC is new code and as such has no need to include old 
deprecated code. Any one using XFC shouldn't expect to use an old 
deprected widget when they should use the new widget that replaces it 
instead. We're talking about new code, and of course from this point on 
any newly deprecated code will be dealt with in the same way GTK+ does, 
inside a deprecation macro.

Jeff.