Re: [Gtkpod-devel] Prefrences format

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi James,

seems to be pretty much what I have expected.

In the current CVS release I have added the following, sometimes more
convenient frontend functions:

/* Retrieve a 64 bit integer setting. */
/* Return value: the set integer value or 0 if no value is set. */
/* Use prefs_get_int64_value if you need to know whether a value was
   actually set in the prefs or not. */
gint64 prefs_get_int64 (const gchar *key)

/* Retrieve an integer setting. */
/* Return value: the set integer value or 0 if no value is set. */
/* Use prefs_get_int_value if you need to know whether a value was
   actually set in the prefs or not. */
gint prefs_get_int (const gchar *key)

Also, I ran into a problem when initialising prefs settings with an
arbitrary number of entries, like

pset1=...
pset2=...
pset3=...
....

How do I default-initialise such settings? If I initialise them as
"a"
"b"
"c"

and the prefs file only defines

pset1="aa"
pset2="bb"

then pset3 would not be reset/overwritten.

I solved this (for the time being) by introducing an end-marker, e.g.

pset3="---+++---end---+++---"

Do you have any better idea?

Cheers,

JCS.

On Wed, Jun 29, 2005 at 11:11:50AM -0700, James Liggett wrote:
> I'm glad to have your support Jorg. To get a rough idea of where I'm
> going, I've attached a simple test suite for the backend code. It
> doesn't have a UI yet; it was only designed to test the inner workings,
> and to check for memleaks in the data structures and such. In a
> nutshell, I think that for this to work, we need to not number different
> things, but give them more descriptive names instead. Since the current
> system uses lots of arrays and stuff like that, I see why its done like
> that. My system uses a hash table, and therin the conflict lies. I'm
> sure you'll like where it's going.
> 
> Regards,
> James 
> 
> On Wed, 2005-06-29 at 15:23 +0200, Jorg Schuler wrote:
> > Hi James,
> > 
> > the prefs system was developped ("set up" is propably more accurate) when
> > there were only around 10 different prefs settings. From there it grew. It's
> > working, it can be extended, and it's a pain at times.
> > 
> > I don't have a love-relation to the preferences code, so if you have a
> > better way to implement it or a better format for the preferences file, I
> > will support you.
> > 
> > If I read the human interface design notes correctly, the "cancel" button in
> > the prefs window should not only close the prefs window, but also take back
> > all changes made to the prefs, including those already committed with
> > "apply". If this interpretation is correct, I'd like to make sure that this
> > stays the same. If my interpretation is wrong -- well...
> > 
> > Yesterday I've committed some code for the sort_prefs window that uses the
> > preferences system heavily. I'm mainly using prefs_set_string() and
> > prefs_get_string(), so I hope it is almost compatible with your new
> > interface.
> > 
> > Let me see what your new interface looks like -- I'm quite curious!
> > 
> > And last but not least: thank you very much for contributing to the gtkpod
> > project. I'm looking forward to the changes!
> > 
> > 
> > Cheers,
> > 
> > 
> > JCS.
> > 
> > 
> > > --- Ursprüngliche Nachricht ---
> > > Von: James Liggett <jrl...@co...>
> > > An: Jorg Schuler <Jor...@we...>
> > > Kopie: GtkPod Developer Mailing List <gtk...@li...>
> > > Betreff: [Gtkpod-devel] Prefrences format
> > > Datum: Tue, 28 Jun 2005 19:06:46 -0700
> > > 
> > > Jorg,
> > > Now that I have designed a suitable backend for handling prefrences
> > > key/value pairs in a much simpler, and more modular manner, I have come
> > > upon a conflict. The way certain prefrences are formatted, like paths,
> > > the sort tab prefs, and the sp prefs (playcount, rating, etc), make it
> > > difficult for anything but the current system to work. I have considered
> > > reformatting these key names as discussed, but I really feel that being
> > > compatible with the previous system would make things way too complex.
> > > As such I feel that we need to completely redo the file format for a
> > > future version. I realize that this is a mammoth proposal, but I really
> > > think that gtkpod will have to come to a major changing point if future
> > > development is to remain efficent. Such major changes would not be
> > > imminent, bur rather long term, quite a few versions in the making. When
> > > I began working on this project, I guess I didn't really know what I was
> > > getting into. I've been looking through the current prefs code, and I
> > > will pull no punches when I say it sucks. From a expansion standpoint,
> > > it's an absolute nightmare.  Not that I mean to be rude, but I have to
> > > call it like I see it. Nor is that a knock on your work. As a whole,
> > > gtkpod is a great product. I would like to help you make it even better.
> > > I just think we need to be thinking long term here. Thanks for listening
> > > to all of this. I really would like to discuss this further.
> > > 
> > > Kind regards,
> > > James Liggett
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > > >from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > _______________________________________________
> > > Gtkpod-devel mailing list
> > > Gtk...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
> > > 
> > 
> > -- 
> > What's the difference between eating sugar (e.g. candy bar) and
> > eating carbon hydrates (let's say a loaf of bread)?
> > 
> > 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
> > +++ GMX - die erste Adresse für Mail, Message, More +++
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Gtkpod-devel mailing list
> > Gtk...@li...
> > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel