Re: breaking libgnomeui API



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.

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]