Ok, that sounds like a good idea. Thanks a lot
On Tue, 2005-06-28 at 22:11 +0900, Jorg Schuler wrote:
> Hi James,
> I think it's quite clear why I'm using enums and predefined
> static const gchar *path_button_names =
> const gchar *path_entry_names =
> static const gchar *path_fileselector_titles =
> It's easy to extend without writing new functions everytime new path
> definitions are added. Just add the button_name and entry_name to the prefs
> window (gtkpod.glade), then add new strings to the definitions above and
> extend the enum list.
> Anyway, the naming scheme could easily be improved by using e.g.
> path_entry_names[enum_value] instead of "path<enum_value>".
> Just be sure to write an automatic conversion from the old identifier to the
> new identifier when reading the prefs.
> On Mon, Jun 27, 2005 at 06:55:28PM -0700, James Liggett wrote:
> > Hello all,
> > I'm working on revamping the prefs system, and while I have a working
> > system for most keys, I'm at a loss to explain why the path keys are
> > numbered (path0, path1, etc), instead of being named as to what they're
> > used for. For each path, there's a comment in the prefs file, that
> > follows that convention. Why don't we use these more meaningful names?
> > It would certainly be easier to add new path prefs this way. The current
> > system requires a delicate enum system, but I just don't see the need
> > for that sort of thing. Can someone tell me why it was done this way?
> > Thanks
> > 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