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

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

On Wed, Jan 13, 2010 at 5:23 AM, Jo Even Skarstein <joska@online.no> wrote:
> Paul Wratt wrote:
>
>> It may be more useful to look at an engine that can handle these, like
>> a slim line WebKit, and get the html engine and js with it
>
> Sounds awfully complex for an RSC editor! There is no need for all this
it is only complex if other parts of the OS are ignored, in this case
the use of a fully functioning HTML renderer (hence webkit). It has
rescently become obvious that any web browser requires XML and XSL
rendering capability.

Web based content is not restricted to use on the web. XML
applications make for easily customizable GUI front ends, hence a XML
based RSC format makes an XML based editor a logical step, with the
engine having the added advantage of being capable of render HTML

> - the RSC format is simple and strictly defined. All you need is to be
> able to load/save a human readable version in a RSC editor, and have a
> small command line tool to compile/decompile these files to/from the RSC
> binary format.

the idea idea is clearly split in two, a command line too, and a GUI
based edtior. For ease of multi platform development, older RSC
formats must also be createable. Any output format is much more easily
maintained if the editor calls a compiler.

RSC definition may be simple and strict, but it is also sorely lacking
in modern components. Thankfully most additions are extension of the
AES object, not the RSC format itself

>
> Remember that this is GEM and not the web :-)
>
>> The other point is that there neds to be some updating done on the
>> resource format, an extension at least, that can allow for a standard
>> set of AES objects and in particular 32bit color widgets. XaAES is
>
> This can be done with very little effort in the AES, but it requires a
> new RSC editor to handle the new format.
>
No AES work will be done on graphics for more than 12 months, and
apart from MyAES, there has been no related effort for years..

>> BTW, as a temp solution, something like python could be used to do xml
>> and xsl to rsc binary... there is a new package available from Mikro
>> that works natively..
>
> Sounds really slow to me. Way to complex to be beneficial. Remember, the

temp fixes are often slow, but they work. in this example python has
available all the components to provide a command line tool with only
minimal effort, and in a small amount of code

the point is there would be an easily adjustable (python being text
based) tool to provide required, available immediately, which seems to
be the result of CVS and repo maintainers concerns

> point in a human readable format is to make things easier to the
> developer and maintainer, to trickier.
>
> Jo Even

and anything human readable will have YES and NO fans on both side,
some poeple find C++ format simple, some find HTML complex, the point
being that human readable does not have to mean "one way only"

it is not outside the scope of available source to provide more than
one solution to this argument, however xml is technically a superset
of html, especially in the later incarnations, and so any development
in this direction would/should have benefits for HW or another browser
efforts, which are also sorely lacking

At the end of the day, it does not matter how many RSC compilers and
editors we have, the point is we need one now, a compiler at least for
source control purposes.

Anyone will to jump in as go the whole hog creating an editor that
uses XML, of any origin, as Kare has offered should probably get onto
it right away, as coping with any structural change to an XML based
definition is not as complex as other easily readable source based
definitions.

It should be remember that there is no need to maintain binary data in
any human readable format, but that the option should be available
from the outset to cover certain situations where it may be more
suitable

As it happens, both Haiku Vector Icons and *nix XPM and XBM are also
XML based human readable formats, and therefore lend themselves to
text based compression where needed (outside of repos in this
discussion). As it happens so are SVG images.

Another side benefit of the above outlined route is the use of Haiku
Vector Icons as the basis for a 32bit vector image format for GEM meta
files, the icons being limited to 256 paths only, and of a square
nature. The use of Haiku Vector Icon over other formats simply because
the format and structure is already clearly defined, and VERY highly
compressed. Even with 256 paths the resulting file can be as small as
200 bytes, on average around 1000 bytes (<1k), while still maintain
complex image design structure

The biggest lack of modern Atari based development, is the lack of
concern or thought for other parts of the OS. With the extra amount of
people currently around and waiting in the wings to do something
constructive, now is a good opportunity to rectify the situation at an
overall level.

An XML based command line RSC compiler is a good place to start, as it
opens up many possibilities besides its initial use of allowing RSC
data to be maintained in source format.

If it were supplied with even the most simple OS setup, the
possibility of customising one own OS become a reality, which would
lead to more language support across all fronts, including previously
neglected or unsupported languages.

Paul