[sword-devel] [bt-devel] Bibletime 2.0.alpha3 FTBFS with sword 1.6.0RC1 library

Troy A. Griffitts scribe at crosswire.org
Tue Apr 21 08:24:21 MST 2009

Eeli Kaikkonen wrote:
> Unfortunately I have to destroy your hope here: we have only the 
> static warning which doesn't have to be agreed. But I have already 
> planned replacing it with a dynamic warning.
> There is virtual int refreshRemoteSourceConfiguration(). Would it be 
> enough if I override it, opening a dialog etc.? Now I just use 
> setUserDisclaimerConfirmed(bool val). Is it so that the library calls 
> refreshRemoteSourceConfiguration() before every network transaction? 
> And what is the int return value?


All the InstallMgr calls which perform remote access now check if bool 
isUserDisclaimerConfirmed() returns true before performing their operation.
Would it be useful to you, as a frontend programmer wishing to satisfy 
this criteria in Bibletime, to have isUserDisclaimerConfirmed be made a 
virtual method, which always returns false in the default impl (not pure 
virtual since installmgr can still be useful for local/CD 
installation).  Then we would remove setUserDisclaimerConfirmed(bool).

This would essential mandate a best practices methodology for confirming 
that the user has accepted the disclaimer.  Something like:

bool MyInstallMgr::isUserDisclaimerConfirmed() {
    static bool confirmed = false;
    if (!confirmed) {
       confirmed = (showDisclaimerDialog() == mbOk);

Then the first time the user attempts a remote activity, InstallMgr 
checks isUserDisclaimerConfirmed() and your confirmation method is 
shown.  Obviously, if you'd rather choose to show the disclaimer at an 
earlier point, you can always call isUserDisclaimerConfirmed() yourself 
to trigger your confirmation method.

What do you think?

Now's the time for us to change the interface if we're going to do it, 
before we cut a stable branch.

>> When we release a final API which supports it, we will populate the 
>> master list with valid repos.
> Combining these two, does it mean that the API will change? Or should 
> I just read the installmgr or soon to come comments and use the 
> existing API?

No, I didn't mean to imply I had plans to change the 
refreshRemoteSourceConfiguration before release-- only that we hadn't 
bothered to update the master repo list yet because we hadn't released 
anything to end users.


More information about the sword-devel mailing list