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/
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev