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]>

"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

Reply via email to