Re: Preferences dialog: Not implementing options without hacks

From: Christian Neumair (chris_at_gnome-de.org)
Date: Sat Apr 10 2004 - 04:19:33 EDT

  • Next message: msevior_at_physics.unimelb.edu.au: "commit: Various RTF import fixes for Frames."

    On Sat, 2004-04-10 at 02:25 +0200, Marc Maurer wrote:
    > > Uhm where should I add it? Does this mean that it's an empty
    > > function/dummy implementation? Sorry, but I'm completely unfamiliar with
    > > this coding style / way of thinking.
    >
    > In the place where you 'first define those functions'. And yous, this
    > means that they are 'empty' functions when not overridden.

    Well, defining the setter as empty is no problem. But stubbing out the
    gather functions may cause serious issues because inside
    AP_Dialog_Options::_storeWindowData, Save_Pref_Bool is called with
    _gatherSomeOption() as argument. The problem is that if the getter stubs
    simply return 0, all non-visible options will be set to false, at least
    that what's I suppose from the way it's invoked. We'd have to only call
    Save_Pref_Bool if it's associated _gather is implemented in the derived
    class - I don't know whether CPP can do that, can it check for function
    existance?. Another possiblity would be to write a custom
    _storeWindowData for the derived class, but I think the matter is more
    clean. Third option, which is evil hackiness, pass
    pPrefsScheme->getValue to Save_Pref_Bool by modifying the _gather
    #define. But this would mean a really evil loop. Getting and setting the
    same pref inside the same call is really horrible.

    regs,
     Chris



    This archive was generated by hypermail 2.1.4 : Sat Apr 10 2004 - 04:22:31 EDT