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

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 29 Sep 2002 15:06:37 CEST (+0200)

> "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 
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 
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 
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 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. ;-)

> 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.

> 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?

CU, Ingo

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 09-2002