[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