[openbeos] Re: decoder config options

  • From: Gabriele Biffi <mlist@xxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 21 Feb 2008 02:15:37 +0100

Alexandre Deckner wrote:
Wait - there shouldn't be a need for a separate config application at all! All the configuration should be done inside the application itself. But if we stick to a common format, the power user can use a generic editor (and if we use text files, we don't need one at all, but we can still make one if we want).
Yes yes, we agree. When i say editor, i think of a common ConfigView a la HtmlView that would be easily integrated and extendable in your app, or in a separate app.

I never liked those. A preferences panel should be nicely designed to fit the application. And not all settings goes into the preferences panel. It can stay in a generic editor, sure. But then we need another file to teach that editor the rules for our apps option, or put them into the settings file itself (that's what XML does).

I can understand it in an application with plugins, but there are very few of them.

4) + contrarily to plain text, your changes are always valid, the user interface is here to enforce that.
> 5) + it can be easyer on the programmer because he can use brute force,
> object/message dumps, and you are sure the data is conform due to 4.

Not really. A binary file can be altered via a binary editor or otherwise damaged, so you still have to check it.
Sure it can be broken, just as the program binaries or text files, but a normal user is less likely to use a binary editor. Anyway i'm thinking "reducing code duplication", and integrity checking should be done by common code, be it text or binary. The difference is that you can't cleanly hide private/implementation data in text files.

I think that the best way to go are text files (easier for the user), and a set of functions to make them easy for the programmer as well.
Sure, i use them every day, xml too, but i've seen so much code (and wrote some, not Haiku in particular) redoing basically the same tedious work differently each time because there's no ultimate nor standard practice now. And there's some reason this discussion started after all :-)

Yes, we need a common laoder/parser in some form. I was designing a text based one for AtomoCAD, but I never gone much far from a couple of headers...


Regards,

Gabriele


Other related posts: