Re: [freesci-develop] FreeSCI configuration

[Matt]

> I'm not sure if we can generalise the drag&drop to everyone's
> satisfaction, but I agree that as much as possible of the
> loader/configurator functionality should be integrated. I'd suggest
I know that for OS X the drag drop functionality would be difficult to 
get to work via X Windows only (unless X11 would be integrated into the 
system, right now it still requires an additional installer).
This would not be a big issue though, the drag drop could be 
implemented via cocoa to at least start freesci (the dropped folder 
name would be passed as an argument).
From there an integrated detailed game setup could be launched. This 
would leave the detailed game setup in freesci.

> That depends on whose ease you're concerned about ;-)
> It's fairly easy to understand our config format with a mere lexer (->
> src/config.l)-- perhaps not quite as easy as it would be with an XML
> file, but the format we're using has the advantage of being reasonably
> convenient for people to edit by hand.
Agreed, the ini like flow of config makes it an easy manual changeable 
file. I have been looking at this from a reading/writing perspective 
from a non Windows point. I coded some pieces (actually I created a 
WritePrivateProfileString and GetPrivateProfileString, functions I 
thought I would never see again after I switched to Mac) and noticed 
them becoming complex.
The thought of XML came up because any XML parser would take all the 
work away from reading and writing the file and I would think it would 
reduce some coding in freesci.

>   Anyway, the real issue you attempt to address with that seems to be
> round-trip configuration (de)serialisation, i.e. we need to add
> facilities to FreeSCI to serialise the configuration setup, and also
> to manipulate it (for this to serve any purpose).
>
>   Since you've already spent some thought on that (unlike me), do you
> have any suggestions as to the architecture or API that such a
> round-trip configuration subsystem should provide?
Writing an API for external game setup would show the user an 
'OS-fitting' UI. I have played with ScummVM and the internal setup is 
pretty nice so if thats possible with freesci (which sounds like it) 
then I would prefer that over any API. If an API is required I would 
think it would be the easiest to use the existing read write config 
code and just create a small tool that would allow reading and writing 
the game settings using this existing code. Its fairly easy to write a 
wrapper over such a tool in OS X.

> The correct video/audio setup should be autodetectable, but your
> drag&drop approach seems like a very nice feature that should become
> part of FreeSCI one way or another.
I remember there was a discussion if all video drivers would stay all 
supported. I believe there was a wish to reduce the number of video 
server/driver possibilities. Does Glutton still support SDL and 
X-Windows or will X-Windows (and maybe DreamCast) become the only 
supported video driver?

I am close to completing the launcher for OS X and will send it and the 
code out pretty soon. Just checking if everything runs nice on non 
debug machines.

Matt

On Apr 1, 2004, at 11:33 PM, Christoph Reichenbach wrote:

> Matt,
>
> > Its a separate front end. Here is a screenshot. Dragging folders on 
> > the
> > application icon or on the application itself adds the game to the 
> > game
> > list. Users can select the video and sound server for the specific
> > game.
> > If the game is already setup then dragging the folder on the
> > application launches the game immediately. Its really just a launch
> > platform.
>
> Good approach.
>
> > The more I check into supporting more features in the front end (by
> > using the config file settings) the more I really believe the loader
> > should be integrated.
>
> I'm not sure if we can generalise the drag&drop to everyone's
> satisfaction, but I agree that as much as possible of the
> loader/configurator functionality should be integrated. I'd suggest
> gradually migrating your features into the FreeSCI common stuff, but
> only after Hugues' existing code has been merged.
>
> > I wonder also if its not easier to convert the config file into an XML
> > format.
>
> That depends on whose ease you're concerned about ;-)
> It's fairly easy to understand our config format with a mere lexer (->
> src/config.l)-- perhaps not quite as easy as it would be with an XML
> file, but the format we're using has the advantage of being reasonably
> convenient for people to edit by hand.
>   Note that at least I personally am not conceptionally against a
> change in the configuration file format, as long as a real benefit
> will come out of that.
>
>   Anyway, the real issue you attempt to address with that seems to be
> round-trip configuration (de)serialisation, i.e. we need to add
> facilities to FreeSCI to serialise the configuration setup, and also
> to manipulate it (for this to serve any purpose).
>
>   Since you've already spent some thought on that (unlike me), do you
> have any suggestions as to the architecture or API that such a
> round-trip configuration subsystem should provide?
>
> > This front end will work for now but I would rather see an integrated
> > one as final version.
> > Once the game loader would be integrated a very simple wrapper could 
> > be
> > used to just launch freesci with the correct video driver/server.
>
> The correct video/audio setup should be autodetectable, but your
> drag&drop approach seems like a very nice feature that should become
> part of FreeSCI one way or another.
>
>
> -- Christoph
>
>
>
> _______________________________________________
> FreeSCI-develop mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freesci-develop