I am very glad to see that other people are also thinking about an enhanced
template format. I hope we can have a constructive discussion about it.
These are my comments and thoughts about the 'Glass' format :
(1) I wouldn't allow 'anonymous icons' (ie. icons without a name), because
these icons will cause problems when the user wants to generate the #define
file. During the convertion of a Template file to a Glass file, I suggest
you artificially generate the icon names (eg. by giving them ASCII number
names).
And I think you should also specify that there may not be two windows/icons
with the same name. Althought I see no problems when 2 icons have the
same name when they belong to 2 different windows.
(2) Personally I would prefer the sequence Name_WindowPrefix, Name_IconPrefix,
Name_IconName, Name_IconSuffix and Name_WindowSuffix instead of
Name_IconPrefix, Name_WindowPrefix, Name_IconName, Name_WindowSuffix and
Name_IconSuffix. Couldn't we define the order of these fields in one of
the free three bytes which are available in the "2 word" Risc Os Time Stamp ?
(3) Normally it is possible that each window has its own Sprite pool. Althoughtthis is rarely used, it can have its advantages. Unfortunately you can't
specify this in the Glass format. Another pity thing is that you can't
specify which sprite file has to be loaded together with the Glass file.
A solution for these problems could be the following standard for the
'Sprite area control block pointers' :
0 => Wimp sprite area
<any other value> = chunk offset to the sprite filename (somewhere in the
Indirected data block)
Personally I think it is better to seperate the sprite filename(s) from the
Indirected data block. Maybe we can define a new chunk for it (together
with the filenames where the icon constants should go).
(4) Something which I don't quite understand :
> GLS_WIND
> ========
> Chunk Field Field
> Offset: Size: Meaning:
> Header:
> [...]
> 12 4 Wind_IndDataOffset
> Chunk offset of indirected data table for this
> window.
"for this window" ? Shouldn't that be "for these windows" ?
(5) A last point what I would like to raise is that there is no support for
text (read : Indirected Data) in different languages.
A solution for this could be different Indirected Data tables. IMHO this would
make the GLS_WIND chunk rather heavy. Therefore I suggest to define a new
chunk as :
GLS_DATA
========
Chunk Field Field
Offset: Size: Meaning:
Header:
0 4 Number of different Indirected Data tables (one for
each supported language)
4 8 Ind_NumEntries (number of data entries in each table)
8 16 reserved
24
Language table:
l+0 20 Name of the language (null terminated string)
l+20 4 chunk offset to the Indirected Data table for this
language
l+24 next language table entry
Indirected Data tables (one for each supported language):
As descripted in the initial Glass format, except the "Ind_NumEntries"
is omitted (which is now being placed in the GLS_DATA header).
Indirected Data block:
As decripted in the initial Glass format.
Comments
~~~~~~~~
- The GLS_WIND chunk would only contain the Header, Index and Window Data
blocks.
- All the window title texts are indirected and there are only indirected
icons. So the 'indirected data' bit *in the Glass file* can be used to
hold other information (eg. should we allow that other people can change
all the text strings in a Glass file, like copyright strings, version
numbers, etc. ?)
- The way to access the indirected data in a Glass file would be the same
as proposed in the initial Glass file format except that you have to choose
the right Indirected Data table.
- I do not have the Risc OS 3 PRMs but I guess that the language name could
correspond with what the terrority module returns.
> To John Tytgat:
> ~~~~~~~~~~~~~~~
> I gave a copy of Glazier to a member of BASS at the meet after the '92 BAU
> show. He said he wrote !Dissi - I thought this was you? Do you really have
> such a short memory, or was it not you, and BASS members just don't talk to
> each other? :-) He even looked like the picture of you in the info window
> of Dissi...
Yes, you gave it to me. And no, I do not have such a short memory ;-). The
reason why I asked more info about the Glass file in c.s.a.t was because I
didn't know that you were about to define a new Template format. We are
extremely interested to be involved in the development of the Glass file
format. In the beginning of December '92, we already started to define a
enhanced Template file format ourselves but I believe that the public
development of the Glass file format is more interesting for the Archimedes
