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 on gtk. > 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]> http://erikg.codepoet.no/ "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 enthusiastic about." -- Albert Einstein
