[OTR-dev] Core/UI Split of gaim-otr-1.0.3

Evan Schoenberg evan.s at dreskin.net
Fri Jan 21 11:50:58 EST 2005


On Jan 21, 2005, at 7:31 AM, Ian Goldberg wrote:
> There's pretty much no logic left in gaim-otr; it's all UI.  ui.c is 
> the
> UI for the preferences panel, dialog.c are the dialog boxes, and
> otr-plugin.c is the "glue" to gaim.
> For Adium X, you'd probably need to implement each of these pieces 
> using
> Cocoa or whatever, but you could follow the structure closely if you
> liked.  [otr-plugin.c probably has the most reuseable bits in it, since
> the glue to Adium should be similar to gaim.]

[Prepare yourself... long email.]

If otr-plugin is a true extension of gaim, it shouldn't be necessary to 
maintain "adium-otr".  Gaim is nearly UI neutral in its core (there are 
still 2 core files which need some attention to be completely UI 
neutral); to update to a new version of libgaim, I diff the old Gaim 
against the new Gaim and apply the diff.  In the future, when the 
core/UI split is complete, that will be completely unnecessary; I'll 
drop the new version of libgaim in place.

Similarly, if otr-plugin were core/ui split, an updated version of 
gaim-otr would be dropped in place.  If significant functionality 
changed I might change the UI functions which Adium registers with 
otr-plugin (like the gtkgaim functions which would have been updated 
along with the plugin, since it would ship with the gtk UI for use with 
Gaim, no changes needed).

I can't just implement these pieces using Cocoa, not in any manner that 
would be clean or maintainable anyways.  This would be the first 
invasion of cocoa into libgaim and its dependencies, libraries, and 
plugins.  Libgaim.framework (a framework in OS X is like an umbrella 
dynamic library or something) is C-only.  From within Adium's Cocoa 
code, what I want to do is register the UI functions which the plugin 
will call.  Those should inform the UI of what to do display and be 
passed callbacks to call when user interaction is necessary... ok_cb, 
cancel_cb, whatever.  The UI shouldn't need to call within libotr; 
otr-plugin is the abstraction layer between UI and libotr, just like 
the gaim core is the abstraction layer between UI and the various 
protocol prpls.

Right now, otr-plugin directly calls methods within ui.c and dialog.c.  
What I would suggest instead is that these two files be changed to be 
UI-neutral, using their own structures, and have registration 
functions.  A structure of the needed UI methods would be created with 
references to functions in the split gtk-otr-ui.c and gtk-otr-dialog.c 
and then would be registered with otr-ui.c and otr-dialog.c, which 
would perform the logic and libotr calls as needed, passing off UI and 
only UI to the registered UI functions.  otr-plugin.c itself only has 
one function which actually depends on the UI and expects: a) it is GTK 
and b) it behaves in a certain way.

(Those are just random name suggestions.. but giving the files in 
gaim-otr a unique prefix would be a Good Thing since one possible way 
of compiling gaim is statically, with all the plugins compiled at the 
same time and into the same binary, and without a unique prefix we're 
asking for a conflict).

The magic test in my mind is ultimately if otr-plugin.c, ui.c, and 
dialog.c can be compiled without GTK; alone, they would clearly do 
nothing, but throw gtk-otr-ui.c and gtk-otr-dialog.c into the mix and 
you end up with the current functionality (no change apparent to the 
user, of course).  otr-plugin.c would have some means of automatically 
registering the gtk callbacks if a gtk #define is available... if not, 
the external UI (Adium X in our case, but Proteus will probably Keep Up 
With The Joneses as usual, and other libgaim UIs will almost certainly 
surface in the future) will need to register its own callbacks for 
gaim-otr.  In GTK Gaim proper main.c inits the core and then calls 
functions in the gtk*.c files which perform all the gtk registrations.

I don't want to bore you, or ramble... so: Does that make sense? Does 
that seem desirable? etc.  Basically: Thoughts? :)

>
> I was under the impression that there wasn't gaim for OSX, just Adium 
> X.
> So wouldn't your package be adium-otr or something?
>
See my other email... OS X is a BSD-based operating system and as such 
can do anything other *NIX systems can do.  I always have the latest 
Gaim installed and working via X11 XWindows Server.... it's ugly by 
comparison, clunky to use in my opinion, a hassle to get installed in 
the first place and not nearly as convenient to load up, but it's there 
:D

But while Adium would implement its own UI, we would optimally just 
have gaim-otr loading as a normal plugin into the gaim core.

-Evan




More information about the OTR-dev mailing list