[OTR-dev] pidgin-otr rewrite

[Howard Chu]

Ian Goldberg wrote:
> On Sat, Dec 17, 2011 at 07:13:19AM -0800, Howard Chu wrote:
>> [Resending; I attached the patch before but at 80KB it was too big
>> for the mailing list to accept. Contact me if you want a copy of my
>> work-in-progress patch.]
>>
>> I've spent a couple days rewriting the pidgin-otr-3.2.0 plugin to
>> only use libpurple, so that the plugin will work with finch. I've
>> just now gotten something running, so I thought I'd post a snapshot
>> of my changes to get some early feedback. You'll also need the
>> latest finch source with my patch here
>>
>> http://developer.pidgin.im/ticket/14818
>>
>> otherwise the conversation menu won't be installed.
>>
>> I've been trying to preserve the UI abstraction of the original
>> code, but it's pretty awkward. I believe ultimately the abstraction
>> could be removed, since the libpurple version will work in both
>> finch and pidgin. (Even if its UI is not as sophisticated as the
>> original pidgin code...)
>>
>> The two sections that are still unimplemented are management of
>> buddies' fingerprints, and authentication of buddies.
>>
>> For the latter, I believe I'm just going to add another sub-menu to
>> the conversation menu, with three choices "Secret Question" (SMP),
>> "Shared Secret", and "Fingerprint" since I don't think I can update
>> a dialog in realtime while changing a combo box like the pidgin/GTK
>> code does.
>>
>> For the fingerprint list I believe the purple_notify_searchresults()
>> API will let me create the multi-column list of fingerprint info,
>> and the appropriate action buttons to go with.
>
> Very cool!  The original reason for the UI separation in pidgin-otr is
> that Adium used to use the same codebase, but with different UI bits.
> It was envisioned that finch would also eventually do that.  Did you
> find that there was gtk-specific stuff in the non-UI parts of
> pidgin-otr?  [I believe Adium now has its own code, though.  Not sure
> what will happen when libotr 4.0 comes out.]

No, no problems of that sort, the opposite really. It seems to me that there's 
a lot of code in the UI-specific portions that should be common.
>
>> Going with the generic libpurple code sacrifices some of the widgets
>> of the pidgin UI. Personally I can live with that, especially since
>> I almost always use Finch anyway.
>
> This worries me a bit; ideally, the refactored pidgin-otr that also
> worked with finch if compiled that way would be identical to the current
> pidgin-otr.  You're saying that's not the case at the moment?

Oh, I've left everything for the pidgin/GTK stuff intact so far, but I'd like 
to see some things changed.

1) I don't believe the options to Generate Private Keys and to manage Known 
Fingerprints should be hidden behind the "Configure Plugins" interface. (And I 
basically can't make that work, for Finch.) Instead, I've added them as two 
menu items to the generic plugin_actions entry point. If we keep things this 
way, then that part of the GTK code can disappear. (But I can also wrap this 
change with #ifdef USING_GTK etc. to preserve the original GTK code.)

As a consequence of this change, the Configure Plugins interface is left with 
just a few boolean checkboxes. I move these into the generic plugin prefs_ui 
handler. But, the generic prefs handler doesn't let me do cascaded checkboxes, 
they're all just at a single level. It's a bit less pretty, but I don't think 
it has any impact on actual functionality or usability.

The thing is, if built solely using libpurple, and installed as a purple-2 
plugin, the single binary will work in all clients. It won't need to be 
recompiled specifically for pidgin and installed twice. But if you have the 
pidgin-specific build already enabled on your box, I believe the two may 
conflict. Right now I'm using the single plugin in both pidgin and finch, but 
first I had to manually edit my ~/.purple/prefs.xml to delete the pidgin plugin.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/