Re: State across application invocation
- From: Soeren Sandmann <sandmann daimi au dk>
- To: Havoc Pennington <hp redhat com>
- Cc: gnome-hackers gnome org
- Subject: Re: State across application invocation
- Date: 09 Aug 2002 21:12:47 +0200
Havoc Pennington <hp redhat com> writes:
> Personally I think we should have a nice cheesy little gnome_config
> style API (cleaned up a bit), though maybe it would actually save
> XML-style files (gmarkup would work), to use for this. People got
> somewhat over-gung-ho about "gconf is the way" and having only one
> config API, but gnome_config_ conflated two things I think are nicely
> handled separately: a preferences API, and a nice simple key-value
> pairs data storage API.
I'm not particularly set on GConf. I suggested it because it has these
properties:
- It meets the requirements
- It is working code, except that a new writable location must
be added
- It is already a dependency for any serious Gnome application
In contrast, the GDataFile API
- doesn't meet the notification requirement
I think notifications are necessary to make the stored
variables global. For example, history lists for entries
could often be global with good effect. In general, user
input can often be cached globally.
- is not working code, though admittedly simple to implement
> (For recent documents specifically, there's a proposal for a standard
> file format for that to be shared across mozilla, openoffice, kde,
> etc. which I'd consider important.)
Do you have a pointer to this proposal?
Since GConf already does file monitoring (right?), the Gnome API
corresponding to this proposal could be GConf based. This would make
recent documents "instant apply", which would in my opinion be a good
thing.
> Anyway, faster and simpler than gconf, but doesn't offer systemwide
> defaults, or mandatory read-only settings, or notifications, or any of
> that.
Well, it is simpler because it has less features. It is probably also
faster; the question is just whether it be enough faster that it would
matter - I doubt that very much.
Anyway, the problem with this API is that you can't possibly have
state across running applications, unless you add something like
typedef void (GDataFileChangedFunc) (GDataFile *df, gpointer data);
g_data_file_install_notification (
GDataFile *df, GDataFileChangedFunc f);
which can't be implemented unless GLib gets "file changed"
functionality.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]