Sorry for the late reply :(
On Wed, 2007-08-29 at 18:56 -0600, Remi Broemeling wrote:
> 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?
Yeah, that's right - the config will be stored with gconf, which depends
> 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.
Sure, but Revelation will just ignore any ~/.revelation config file, and
always use gconf - it's too much of a hassle to determine which one to
use preferences from. And this might lead to some confusion for users,
who might make changes in ~/.revelation, and expect Revelation to pick
up on those.
> 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.
Yeah, that shouldn't be a problem - the basic data structure and file
format handlers should be completely free of any GTK/GNOME dependencies.
Erik Grinaker <[EMAIL PROTECTED]>
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
-- Albert Einstein