Development Question Concerning ConfigFile

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

Post Reply
TheFlyingMonkey
Posts: 2
Joined: Tue Nov 27, 2007 2:49 pm

Development Question Concerning ConfigFile

Post by TheFlyingMonkey »

Hi all,

As a project for one of my classes, we're supposed to look at and modify some data structure on an open source project. ScummVM is an awesome project and something I'd really like to contribute to.

I was looking at the ConfigFile data structure and noticed that it uses a list to store each individual section of the config file. The reason given for this is that the list provides for easy read/write to files. Is there any reason beyond that for using a list? Also, is the order in which the sections are output important?

Lastly, I wanted to apologize if I have posted this in the wrong forum. The Help/Support forum seemed to be more for problems running ScummVM than anything else, and I don't think my question is quite technical enough to attempt to post on the developer mailing list. If, indeed, this is in the wrong place, I do apologize and would appreciate it if you could point me in the right direction.
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Re: Development Question Concerning ConfigFile

Post by fingolfin »

TheFlyingMonkey wrote: I was looking at the ConfigFile data structure and noticed that it uses a list to store each individual section of the config file. The reason given for this is that the list provides for easy read/write to files. Is there any reason beyond that for using a list? Also, is the order in which the sections are output important?
Yes, it is important, and this is precisely the reason why we use a list. A map / dictionary would of course make it possible to perform section lookups faster. But since section lookups are very rare, we didn't bother to optimize that. Over all, in fact, ConfigFile is not much used at all -- rather ConfigManager is used. And ConfigManager does use a map, plus a list of the section names in the order they are supposed to be stored. The same optimization could be applied to ConfigFile. But this would not yield any noticable improvement anywhere, so why bother...
Also, one day, I want to port ConfigManager to use ConfigFile, but since right now "everything just works", this is a very low priority item.
TheFlyingMonkey wrote: Lastly, I wanted to apologize if I have posted this in the wrong forum. The Help/Support forum seemed to be more for problems running ScummVM than anything else, and I don't think my question is quite technical enough to attempt to post on the developer mailing list. If, indeed, this is in the wrong place, I do apologize and would appreciate it if you could point me in the right direction.
I think posting this here is just fine, no worries.
TheFlyingMonkey
Posts: 2
Joined: Tue Nov 27, 2007 2:49 pm

Post by TheFlyingMonkey »

Sorry for the late reply, it's been a busy week.

First off, thanks for responding, I really appreciate it. Second, looking at the two, ConfigManager seems to be a more full featured version of ConfigFile (factoring in, of course, stuff like the map). What was the idea behind creating two classes to essentially serve the same purpose? Is ConfigFile essentially deprecated? Thanks for your time.
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin »

First, there was ConfigManager.

Then, we needed to parse .ini-style files in other places (most notably, for HE games in the SCUMM engine and for GUI themes). For this reason, and since modularization is usually a good thing, we created ConfigFile. The idea was to make separate the code used for loading/saving config files from the ConfigManager (see also the Pentagram code, where it is like that).
However, that task was never finished, and so the two classes started to diverge again.

So, in an ideal world, we'd bring ConfigFile up to speed with the ConfigManager changes, and then switch the latter to use a ConfigFile for storage. However, since things work "as is", this is of rather low priority right now. In addition, one has to be very careful when doing this change, so that not too many things (ideally, none, of course *g*) get broken.
Post Reply