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

[Jo Even Skarstein <joska@online.no>]

Paul Wratt wrote:

> 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

So what you're saying is that one could add a XML-based resource format
in addition to the existing format?

> based RSC format makes an XML based editor a logical step, with the
> engine having the added advantage of being capable of render HTML

I have yet to see a good GUI based on this technology. All of them are
slow and quirky, even on current PC hardware. Not to mention the huge
efforts that is needed. Expanding on the current technology is also
time-consuming, but it will require a tiny fraction of the work needed
for a pure XML-based GUI.

> 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

Including a decent GEM-based RSC-editor? ;-)

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

I don't understand. Nothing is needed. It works well as it is. RSC-files
in text-format would be beneficial for version control, but not
required. In fact, I think there are lots of other issues that is more
urgent than this.

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

A XML based RSC compiler requires XML source to compile. And this source
would have to be created either by hand by a human or by an RSC editor.
Or a tool that decompiles RSC-files. But in this case any changes to the
intermediate XML will be lost whenever the RSC changes, so it's
usefullness is limited to version control.

I'm not saying that XML is a bad idea. On the contrary. A proper RSC
editor that reads and writes XML version of the RSC will be a great
development tool:

- Super-objects can be created. Complex objects that consist of several
simpler objects. E.g. listboxes, datepicker...
- Store references to code with the objects. This makes it relatively
easy to integrate the RSC editor with an IDE (you refer to the XML
objects in the code, not the actual AES object), thus resulting in a
real 'Visual GEM' programming environment.
- Easy to support multiple languages.

The point is that this XML is compiled to a real RSC, so the object
renderer still deals with an efficient binary format.

Jo Even