En réponse à Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>: > > "shatty" <shatty@xxxxxxxxxxxxx> wrote: > > ... > > > Use the appname.rsrc convention for naming your > > > resource file. hint: add .rsrc to the "Resource file" > > > in FileTypes to get these to identify properly in tracker. > > > (no, it's not there by default, believe it or not.) > > > > > > examples: > > > Styled Edit: StyledEdit.rsrc > > ... > > > Also, as Francois brought up, some sort of text based > > > resource creation files would be really great. > > I'm not sure, if I see the benefits. Icons for example look very ugly > as text dumps. And if it is about being able to modify resources from They don't look that bad as .xpm :) (hint: xemacs+xpm-mode :) Btw the icon dump I used in shutdown was from kernel_intel, using this script: catattr BEOS:L:STD_ICON "$1" | cut -d ' ' -f2 | sed 's/,/, 0x/g'| sed 's/^/0x/' | sed 's/0x$//' > the command line, then it would be more helpful to complement `listres' > > by tools like `catres' and `addres' (similar to the attribute tools). > > > We need a textbased filetype build file as well. > > Same here. Of course we need some non-attribute-based format to be able > > to control the files via CVS, but I don't think, it needs to be text- > based. Resource files would be a very natural choice -- currently we actually, we can have it directly, just do a setmime -dump :-) > have QuickRes and can edit them relatively comfortable (BTW, we, at > least I, don't plan to implement the private API QuickRes uses, so it private API ?? which one ??? > won't run on OBOS; Prefs team: hint, hint ;-). A conversion tool should > > be easy to do. > > > I usually roll my eyes at any suggestions to use XML > > for all and everything, but perhaps this is a suitable > > case for it? Would it be overkill? > > Yep. I haven't had a look what XML parsers are available for BeOS for > quite a while. Last time I did, there were basically only libxmlparse > and XercesC. The former has some incompatibilities with the standard, > and the latter is a fat and slow monster with an ugly API. I don't see what makes you alergic to text files, really :P XML looks overkill to me at least. > > > I don't know about resources, but for filetype database > > entries we could simply go with a bunch of setmime > > Bash scripts. The whole lot being built by Jam? > > (not sure how it all fits together) > > setmime modifies the MIME database of the host system. What we actually > > want, is to create a new database somewhere in the `distro' directory. > > > Perhaps its time to scrap the zero-kb, all-attribute mime files, > > (none of them is indexed anyway, I think) > > and put it all in the file. That way we don't waste filesystem > > performance, once the icons go to 128x128 or a > > vector-based format. (When the attributes spill over > > into another inode, there's a small(?) performance hit.) > > I suspect, the difference in performance is insignificant. Actually the > performance may even be worse, when writing to the file and needing to > move data within the file due to an entry at the beginning of the file > having grown/shrunk/been removed. > > The disadvantage of a non-attribute approach is, that a clever format > has to be thought out, while attributes provide you with a way to store > typed data for free. > > Moreover you had to convince Tyler, who has already implemented almost > the complete MIME support (only some small high-level functionality > needs to be finished), to rewrite the basic storage parts. ;-) Eh :) > > > If the mime database used regular files instead, we could > > go with a text-based format, having it work with CVS, > > and having the CVS version of it -be- the mime database, > > shaving some time off the build process. > > Well, I suspect, that building the MIME database from whatever input > files we choose (unless it's XML maybe) won't take more than a few > seconds. Compared to some thirty minutes -- or how long a complete > build currently takes -- this is really not a big deal. again, check setmime -dump :) > > > IMO, someone needs to be the "team leader" of the filetype > > database, to spearhead the quest for perfection in > > file format recognition and support. > > Mmh, compared to other teams, like the kernel or the IK team, this team > would really be a tiny one, wouldn't it? François.