Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90

On 2016-11-02 04:53 AM, S=E9bastien Wilmet wrote:
> On Tue, Nov 01, 2016 at 07:57:47PM -0700, Matthew Brush wrote:
>> Do you have any recommendations for applications wanting to support a ra=
nge
>> of GSV versions from before and after the rename?
>
> [...]
>
> If you want to write new code in 2016 and still want to run that code on
> an LTS distro from 2014, then use only APIs that are available in the
> GTK+ and GtkSourceView versions from 2014. GtkSourceView has kept a good
> backward-compatibility. GTK+ less so (for the CSS etc). So while it can
> make sense to write conditional code depending on the GTK+ version to
> make the app work with different versions of GTK+, it doesn't make sense
> for GtkSourceView, in my opinion.
>

It's nice to support a range of versions so that people with older =

distros can use a new version, and people with newer distros can use new =

features, etc. Generally it's easy enough, like say supporting GTK 2 and =

3, where most of the stuff is the same or still works. This is also =

useful for supporting other platforms like Windows where you're stuck =

with whatever bundled versions you can find or whatever's packaged in msys.

Renaming every symbol makes things a bit more challenging though, not =

that I think it's a bad idea.

> [...]
>
>> I guess making a header
>> with a bunch of #defines mapping to the old names would work, but perhaps
>> there's something less tedious I missed, or some compatibility path plan=
ned?
>
> A header with a bunch of #defines could be written, if it is really
> useful for some applications, why not. But I'm not going to write it :-)
> I don't need it, and I don't see why it would be useful. But
> contribution welcome.
>

I will probably go this route if the need arises. Are you planning to =

use a script to automate the renaming of symbols? If so, that might be =

useful for generating such a header.

Thanks for the response.

Regards,
Matthew Brush