Re: breaking libgnomeui API

[Carlos Garnacho <garnacho tuxerver net>]

El mié, 28-01-2004 a las 20:06, Mike Hearn escribió:
> On Wed, 28 Jan 2004 01:59:47 +0100, Matthias Clasen wrote:
> > Of course, apps wont have much benefit from inserting a
> > preview widget in a fileselection which is never shown, but at least
> > they would still compile and work.
> 
> Backwards compatibility isn't just about keeping apps compiling - if
> something uses this field then it clearly expects it to influence the UI
> in some way. Changing that assumption breaks the semantics of the API if
> not the ABI, which is just as bad.
> 
> If it is really a problem, just dupe the APIs involved so programs can be
> changed using a simple s/gnome_file_entry_new/gnome_file_entry_new2/ or
> whatever. 
> 
> Probably a better solution would be a flag that alters the behaviour
> though, so you can default to using the old widget unless the app opts-in
> and the field now points to the new file picker. That makes it a bit
> harder to keep working with older versions of libgnomeui, but such is
> life (for now). You also have to go through and audit apps to ensure they
> use the new flag, but this is better than breaking backwards compatibility
> when the project has made a firm commitment to not do so. Bugs like not
> using the magic flag would work themselves out in time though.

Seems a really sensible solution, in this way the backwards compat will
be explicitly broken by the app developers. This is also an API change,
but much less important than the former, if I do it, will be accepted?

	Carlos

> 
> If it sounds like a lot of effort, well, it might be. If it's not done
> though gnome 2.6 may ship with a mix of file selectors in the core
> desktop which is arguably worse than the present situation.
> 
> thanks -mike
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>