Erik Grinaker wrote:
> Well, the data access side will necessarily depend on GTK/GNOME, as we
will be using GNOME-VFS for loading/saving data (so we can access it
over a network). But the file format handlers will only need to be
passed a string of data, so these can be made independent of GTK/GNOME.
Hmm. I would prefer a very tight integration between console and GUI
versions of revelation -- right down to the config level, but that is a
good point about GNOME-VFS, and come to think of it the config is
controlled by GNOME as well, isn't it?
What I could do for the console side is test if GTK is available on the
machine at launch (and if it is, pull in the GNOME config and use the
GNOME data-loading layer). If it is not, fall through gracefully to a
rather simpler config layer depending on a simple text-based
~/.revelation config file (which obviously would not have access to
GNOME-VFS and would not support all the fun stuff that the VFS allows).
Thus you could have console revelation installed on your desktop
computer (for SSH access to passwords), and it would automatically use
the same config as your main revelation instance... but you could also
have it installed on (random headless computer), and it would just
function based on a ~/.revelation config file.
Of course, console means command-line parameters too... which would
over-ride either config source.
I've looked through the code a little bit, and I was hoping that we
could take out gtk.TreeStore and replace it with a different TreeStore,
one that isn't provided by GTK and doesn't depend on PyGTK/GTK. I've
spent a little time looking around and haven't found any obvious open
source TreeStore classes (other than the one provided by GTK), but even
then could we perhaps write a TreeStore class that doesn't depend on GTK
instead of using PyGTK's?
Actually, since 0.5.0 won't organize accounts in a tree structure any
more, the file format handlers could just return a normal Python list of
Account objects, which shouldn't need to depend on GTK.
Would this be sufficient? The rest of the library would need GTK/GNOME,
but I don't think any of it would be of interest to a curses interface
in any case...
That would be fantastic. As long as we can keep the account objects
free of GTK/GNOME dependencies, that would work well to my mind.
Great, thanks Erik.
--
Remi Broemeling ([EMAIL PROTECTED])
System Administrator
Nexopia.com Inc
