Re: [MiNT] HRD's & RSC's

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Jan 12, 2010 at 6:55 AM, Jo Even Skarstein <joska@online.no> wrote:
> Paul Wratt wrote:
>
>> as long as people remember that any even if the resource can be output
>> as c code, that will need a specific make line to recreate, and that
>> the resource itself needs to be easy maintained and adjustable, which
>> is inherantly not the case when converting resource files to a source
>> code format (C or ASM)
>
> Another solution is to create a RSC editor that loads and saves ASCII
> files. Then the metadata (HRD-files) could be saved together with the
> resource data, and the ASCII files could be converted to RSC-files with
> a small tool while building XaAES.
>
> This could be useful in an IDE too, because you can store references to
> code as metadata in the ASCII RSC. Then it would be possible to create a
> "Visual GEM" IDE.
>
the metadata are currently also binary files, and to me, look like
libs, so I infer that this binary data be in ascii form as your last
paragraph.. metadata is very receptive to ascii style format

I have already mentioned to Joe about the need for a command line
resource compiler for use in compiling icon sets for desktop themes,
as well as for compiling language into resources dynamically

A tool as discussed here, that can also handle traditional resource
setups, like copying data and structure from another resource, or
resource injection would be of use to a lot od current development,
especially where original source is not available. If it worked with
acc to allow modification of there internal resource, this would cover
just about every senario, especially if it can cope with AES 4 &
Interface resource generation as well

A format of resource structure, content and meta information would
also allow for much easier extension of widgets. As it happens the
default native format for Haiku 32bit vector icons are also text
based. With the added advantage of using xbm and xpm formats, all
resource data can be safely store in repos, while maintaining easy
editing, at least by any ascii editor if nothing else is available.

note that xpm and xbm can store 32bit data, including transparency, at
least suitable to contain mask information for icons. It should also
be noted the the resource format as outlined in toshyp
(http://toshyp.atari.org/008016.htm#RSHDR) can theoretically use 15,
16, 24 and 32bit icon data. This may be dependent on actual TOS/AES
implementation, but is at least worth checking out.

As much as I think RSM is a great tool, people are still having to use
Interface for certain projects that require certain functionality.
With the use of a command line resource compiler, a gui frontend need
never become out of date at least as far as the resource format goes,
and what can be contained within it, as this can be easily defined as
example implementations of said resource object

the idea of constructing a resource gui would make for the basis of a
IDE by default, with the addition of a text editor core. Theoretically
there is no reason, short of resources, why the IDE could not the also
allow a point & click and/or drag & drop style rapid application
development

With this flexibility, the IDE itself could then be adjusted to run as
a simple text editor, or cobbled together in a different way for a
different programming style...

If the resource editor were also an interpreter, then its use in the
IDE as a inline syntax checker for language X could also be achieved,
which would allow for any lib functions included to be check as
entered

Theoretically the resource source format could be defined as xml, or
specifically as html+css style, which would assist in making the
addition of scripting to HighWire a reality, even if the format were a
subset

That indicates that HighWire might be a good basis for a resource
designer, as it already has the basis for an interpreter, and that
resources in source form could then be previewed in any web browser,
which in itself would allow a lot more people to design for the
platform as a whole

This need not be seen as one huge development, as the individual parts
are usable by themselves as well as being needed for a cohesive
development environment

Paul