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 Inc

Reply via email to