Replace inifile handler

[GoogleCodeExporter]

The current inifile handler is not really flexible and don't allow us to 
add entries to existing sections. This make the separation of the inifile 
in sections quite pointless.
I suggest using Franck Hecht's C_Inifile ( http://franckh.developpez.com/
cinifile/ ) because :
-I know it
-It works
-It's written in highly portable ANSI C89 (compiles fine even with open 
watcom)
-It's GPL v2

This would allow easier management and changes on the ini file and a 
cleanup of old features without compatibility breaking between versions. 
What do you think about it ?

Original issue reported on code.google.com by pulkoma...@gmail.com on 24 Jul 2009 at 3:46

[GoogleCodeExporter]

Will it be able to support the multiple occurences of a key (0 to 4) that we 
use for
Bookmarks ?
Note, I put the defaults in a file called "gfx2def.ini" because it was less work
during the porting, but don't hesitate to re-design as you need. All the 
optional
settings have a default twice: in the .ini, and in the loading code.

Original comment by yrizoud on 24 Jul 2009 at 4:36

[GoogleCodeExporter]

Multiple occurences of a key doesn't sound like very regular ini syntax... I 
wonder 
who added that to the file :p

I guess only the first one will be loaded. But we can introduce a new section 
called 
[bookmarks] with entries called name1, path1, name2, path2,... instead, which 
sounds 
much cleaner. Is this kind of compatibility breakage acceptable between 2.0 and 
2.1 
inifiles ? Or should I write a special handler for this case and gather the old 
values, at the price of some less clean code ?
I think gfx2def can be removed if the loading code don't need it. If you can 
bear 
the faxt that I often upload my own .ini and .cfg alongside with my commits, of 
course.

Original comment by pulkoma...@gmail.com on 24 Jul 2009 at 4:49

[GoogleCodeExporter]

I did. It's not as if there was a standard or something...
Losing bookmarks (once) is annoying but not too severe, I can live with it. 
(And I'm
not the one who is causing it :) )
Don't put your gfx2.ini in svn, please... it's already an error to have 
gfx2.cfg in
there.
We cannot ship a default gfx2.ini along with the executable, because it would 
force
grafx2 to choose behavior "configuration directory is data directory".
The goal of gfx2def.ini is mostly to have the comments, because the current 
system
preserves them when saving as gfx2.ini in configuration directory.

Original comment by yrizoud on 24 Jul 2009 at 5:23

[GoogleCodeExporter]

Ok, I will check how C_Iinfile handle the comments (i think it will keep them 
if 
they are already there). But we need a way to generate these comments for the 
first 
run... mh... maybe i'll extend C_Inifile to handle comments attached to a 
value. Or 
maybe we can just drop them and add a wiki/help/man/readme page explaining the 
settings ?

And of course the .ini will stay out of svn. For some reason I tought it was 
already 
in there. Sorry.

Original comment by pulkoma...@gmail.com on 24 Jul 2009 at 5:53

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Sep 2009 at 7:14

• Added labels: Milestone-2.2

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 30 Oct 2009 at 11:37

• Added labels: Milestone-2.3

[GoogleCodeExporter]

Something to ponder: We're reaching the limits of the cfg format for keyboard
shortcuts, and it's a bit strange to handle 2 files (cfg and ini) for 
configuration.
Maybe we should unify the two files into one. Cfg has several pieces of data 
which
can't be cleanly expressed in .ini format (6 shade tables containing 512 color
indices each). Xml would do fine, but we'd rather find compilable source code 
for the
parser/writer, as I doubt we'll find a handy library for all platforms. We'd 
have to
be careful, storing binary as hexa will double the file size. Storing the brush
container will take some room if the brushes are large.

For compatibility, we should still read cfg and ini when they exist (and delete 
them
after conversion), so this change would not reduce much the amount of source 
code anyway.

Original comment by yrizoud on 25 Nov 2009 at 10:27

[GoogleCodeExporter]

The idea behind the .ini is to have an easy access to settings and tweak them.
Switching to a pure binary file means :

- Having all the settings available in the gui
- Having a /safemode option to run with default settings, if you ever mess 
something
(like running the prog in a non working video mode)

Having all the settings in the gui is good. Having a binary file is not. XML 
will not
bring much more than good old ini, and I'm not fan of uuencoding binary data 
anyway.

If we remove .cfg and .ini, I'd rather write an external prog. to convert old 
files,
or we could keep it inside gfx2 but for only one version, then drop it.

Original comment by pulkoma...@gmail.com on 25 Nov 2009 at 10:44

[GoogleCodeExporter]

Well, I've made a mistake when I implemented more and more data as .ini 
settings.
Typical examples : bookmarks, window position.

Original comment by yrizoud on 25 Nov 2009 at 10:56

[GoogleCodeExporter]

yes. I'm planning to move as much as possible settings inside the program. If 
they
are settable both using the GUI or from command line, it's ok.

For example, I know CPC users created batch scripts to run gfx2 in different 
modes
(wide, normal, tall) ith the palette range preset. This way you can use it for 
CPC
and still have the normal, non-batch version, run in default mode with the 
256-color
palette range.

If the number of settings that can be set only from the ini is low, replacing 
that
with a pure binary cfg file and some command line switches for critical things 
(video
modes), then I think we're ok.

Original comment by pulkoma...@gmail.com on 25 Nov 2009 at 11:08

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Jan 2010 at 7:34

• Added labels: Milestone-NotPlanned