[openbeos] Re: resource files, application signatures, and icons

From: François Revol <revol@xxxxxxx>
To: openbeos@xxxxxxxxxxxxx
Date: Sun, 29 Sep 2002 22:24:12 +0200 (MEST)
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.
References:
- [openbeos] Re: resource files, application signatures, and icons
  - From: Ingo Weinhold
[openbeos] Re: resource files, application signatures, and icons

Other related posts:
