[OTR-dev] 2.0.0 pre-releases coming soon

[Evan Schoenberg]

On Jan 31, 2005, at 8:17 AM, Ian Goldberg wrote:

> On Sun, Jan 30, 2005 at 08:07:25PM -0600, Evan Schoenberg wrote:
>> Attached.  As before, I can't compile the GTK part, so apologies if it
>> has errors.  Let me know if there are any problems.
>
> Wouldn't it be better to move the gaim-prefs-specific loads and saves 
> to
> the gtk file, but leave the find_policy call alone?  Won't you want to
> use the find_policy function as-is?
>
I moved the whole thing to the gtk file because another UI may have 
preferences handled differently... and of course I speak in the generic 
there but mean that Adium has a different way of handling preferences 
;)  Our contact-specific prefs automatically handle inheritance, so if 
a value isn't set at the contact level, the group level will then be 
checked, and then the global level, with the most specific possible 
value returned.

I guess a single function could return the appropriate values, either 
global or contact-specific or whatever... I'd just gone ahead and 
stored the preference as a value out of an enumeration rather than 
under three keys, so my function's implementation just asks the contact 
for the preference and then does a switch() on it to return the 
corresponding OTR value.

>> Also attached is a one-line diff squelching a compiler warning I
>> received in otr-plugin.c.
>
> I don't think this is valid; what's the warning?  The switch statement
> already handles all possible values of the enumeration, and if the
> enumeration changes, *then* we want a compiler warning that you need to
> change something in the switch (which will be suppressed by the
> default:, which will in fact cause the wrong thing to happen).
>
My compiler was complaining that gaimlevel might be used uninitialized. 
  I don't see how it could be, either, looking at that enum... Sorry for 
the haphazard patch; you're right that that would suppress a later 
change.  No idea what my compiler is doing there, though.

-Evan


>    - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2228 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050131/7a961ce3/attachment.bin>