Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote: > OK, just to make sure, that I understand you correctly. When you want > to > add resources to an application being part of the OBOS build, you > launch > the QuickRes replacement, create new resources, save them to an XML > file and tell the build system, that said file contains the resources > for > your application. When building the resources tool is invoked in > command > line mode to convert the XML file into a resources file which is > finally > added to the application. Right, exactly how it is currently done with the beres .rdef files. The QuickRes replacement should be able to read/write those XML files directly. > For the MIME database the process is similar: With FileTypes > (actually I > would find it a bit confusing to use FileTypes, as it edits the > running > system's MIME database) you create an XML file per MIME type to be > contained in the database and, when building, the tool converts them > into > the standard attribute-only format. > Correct? Yes, that's what I meant... perhaps we should build a special version of FileTypes to be retargetable (or perhaps via commandline arguments), so that we won't mix the two things - or we also should add support for the ability to read/write the XML format directly, too, although it certainly has a lower priority there (as no user would need this, OTOH QuickRes would be very useful for everyone). > > BTW I would not want to create the current beres/deres style > > resource > > files manually either, if avoidable (which it is) :-) > I haven't worked with these tools yet, but from quick glances on such > resource files, I have to agree, that the format seems to have some > potential for improvement. :-P Well, it's not so bad, but it's the kind of file I like to machine generate, and maybe edit it manually afterwards. > However, the situation is, that we currently have two formats for > resources: binary resource files and the textual beres format. The > former > is the one that is used in the build. The latter is the only textual > alternative for now, which I've, BTW, been asked to add build system > support for. I'm absolutely unemotional concerning the matter and > would > also be happy with a yet-to-be-designed XML format. Nevertheless it > would > be nice, if we could decide for with which one want to go in the near > future. E.g. if XML makes the race, it wouldn't make much sense to > add > support for beres files now. Although we could make the use of beres/deres completely the same for the build process (I would also want to keep the .rdef suffix), we should probably not do this before we have a single solution for that problem. IMO the best reason to use XML here is that we wouldn't need to write a parser for it, but we would need to write one if we'd reproduce the beres format. Adios... Axel.