[OTR-dev] OTR Gaim plugin: Core/GTK+ UI split

Evan Schoenberg evan.s at dreskin.net
Tue Dec 21 08:45:29 EST 2004

Hadn't forgotten about you, verbal ;)

libotr of course needs no modification.  gaim-otr is currently in 3 
parts: otr-plugin.*, dialog.*, and ui.*.  I would propose gaim-otr 
being in 5 parts, instead: otr-plugin.*, dialog.*, gtkdialog.*, ui.*, 
and gtkui.*.

(Actually, while we're making changes, I would also propose giving 
dialog and ui more unique names, such as otr-dialog... this further 
distinguishes the files from those Gaim includes.  I'm being a bit 
selfish in that request - libgaim will be compiling these files 
alongside Gaim so it'll be a lot easier for us if the files aren't 
duplicative.  A lot easier.)

dialog.* and ui.* would implement a function as Gaim itself does:
static OTRDialogUiOps *otr_dialog_ui_ops = NULL;

otr_dialog_set_ui_ops(OTRDialogUiOps *ops)
	otr_dialog_ui_ops = ops;

OTRDialogUiOps *
	return otr_dialog_ui_ops;

Any of the core gaim .h files can show how the ui_ops struct is set up.

UI.* and dialog.* then just need to have gtk code separated from logic 
code... for each block of gtk code which needs to get called from the 
logic code, it is done via a otr_dialog_ui_ops->blah(arg1, arg2) call.  
The gtk files would implement an init_gtk_otr_dialog() type function, 
which install_plugin() could call, to register the gtk UI functions.... 
and that call would be #ifdef'd for only happening if gtk is being 
linked in.

Nikita, verbal, does that make sense / seem reasonable and 


On Dec 21, 2004, at 3:05 AM, verbal wrote:

> i think we can just use the lib from gaim for OTR and make it
> interface with adium cause adium uses libgaim anyways if i'm correct.
> shouldnt be that much work. i'm going to look over it in more detail
> this weekend when i have time. evan, i'm sure you know the specifics
> way better. let me know what i can do to help.
> verbal
> On Mon, 20 Dec 2004 21:33:55 -0800, Nikita Borisov
> <nikitab at cs.berkeley.edu> wrote:
>> On Dec 20, 2004, at 9:06 PM, Evan Schoenberg wrote:
>>> It's great to see that OTR was developed with  multi-platform support
>>> in mind, with the Gaim interface separated from libotr.  Would 
>>> anybody
>>> else be interested in working with me -- or, developers, in accepting
>>> a patch from me or others -- to further abstract the Gaim plugin to
>>> have UI registration functions, as Gaim itself does, allowing the
>>> implementation of OTR-Gaim for other UIs?
>> We'd love for OTR to work with Adium.  I don't really know the
>> architecture of Adium; would the main thing to do be to abstract the
>> calls to GTK to something more generic?  If that's the case, it
>> shouldn't be too hard.  I have an OS X environment here and I'd be
>> happy to help with development, but I'm not very experienced in 
>> writing
>> code OS X.
>>> I would be glad to provide further thoughts I've had on
>>> implementation, or to answer questions about what would be needed for
>>> us to be able to use OTR.
>> Definitely, that would be great.
>> - Nikita
>> _______________________________________________
>> OTR-dev mailing list
>> OTR-dev at lists.cypherpunks.ca
>> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> _______________________________________________
> 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: 3617 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20041221/652a7759/attachment.bin>

More information about the OTR-dev mailing list