Hundred Rabbits <hundredrabbits@gmail.com> wrote:
> I've been toying with the idea of grabbing the rom's "state" by
> reading that vector and by changing the metadata, I can write a
> different name to the emulator window title, like "Noodle -
> neauismetica08x08.icn".

I did not think of that, although I can understand why that might be
desirable. However, there are also the following things to consider:

- The program title is not necessarily the same as the window title, and
the window title can be changed due to what you mention, so it seems klugy
to me to put them together.

- Some emulators might not be able to display a window title (or might not
do so depending on the window manager, user settings, etc).

- If changing the window title is implemented, it might be better to use
a separate port for that anyways (possibly one of the unused system ports).

> I was thinking maybe it might be best to specify port names for the
> emulator device(#f0) at some point to handle these sort of events, but
> before moving forward with this I'd like to complete the implementation
> of the manifest specs. I'd like to be able to navigate the manifest from
> an external application, so this will likely also find its way into
> the metadata.

Uxn38 currently uses port #f0 for something else (although only if the -x
switch is specified). It is called after command-line arguments have been
sent and after EOF on stdin. The other ports of that device are also used.
However, this can easily be changed in future if better ideas are had and
are decided to be used (how it is right now is not necessarily best).

> I like the idea of the code page for the character encoding, it could
> be located right after the position of the app icon. I'm not a super
> fan of naming fields, I think it's best to let people use these 3-4
> lines of data whichever way they want. Most of the apps I've written
> use them for name, ver, details and credits, but it could be anything.
> I'm also open to leaving the number of lines up to the application. In
> potato, I read as long as it doesn't find two nulls in a row.

A free text field may be useful, and perhaps the first line can be
considered as the program title by programs that make a list of the files.
Two nulls in a row is probably not the way to do it, though; you could use
line feeds between lines, like the directory listing capability does, and
like command-line arguments already do, etc. This way you can also make
blank lines in the description.

However, other fields might want to be specified explicitly. It seems to
me that the key/length/value format would be useful, so that you can omit
any fields that are not needed (e.g. if there is no icon), add additional
fields, etc.

I think that listing capabilities in the metadata would be useful; at least
to me, it seems more important than including icons. (This could also be
an optional field with its own key, like other ones will be, too.)

A key/length/value format also easily allows programs that do not use all
of the metadata fields to skip the ones it does not use without needing to
already know what their lengths are, because the lengths of each field will
be specified in the file.

I also believe that allow metadata to be inside the program file or in a
separate file, with the same format either way, is useful since this allows
it to avoid using up space in the program file if this is not desired,
while also allowing it to be combined if desired (in case you want to put
them all in one file, and/or for the program to read its own metadata
without having to access a separate file).

-- 
Don't laugh at the moon when it is day time in France.