🚀 go-pugleaf

[A discussion of improved template editing, with quite a bit deleted...]

>1.  The template editor saves its templates in it's own format, which

>2.  When the template editor loads the template file, it also loads and
>    interprets the .h file.

>3.  Use the validation string to hold the icon name.

Validation strings already hold a damn sight more than they should do...
They have become the prescribed method of extending an icon definition
to do the thigs it should have done in the first place. By the time you have
a reasonable set of validation strings in place, the overhead of parsing
them all is going to take a serious toll...

"R" numbers should have 4 bits set aside for the border type, as well
as 4 bits for the slabbing colourm rather than being set as a validation
string.

Antialiased font colours ("F") are there because some smart person decided
to overwrite the icon colours with a font handle... a result of icon
definitions being about 32 bytes too small... And the sad thing about this
is that the perfect opportunity to introduce a new format 64-byte icon block
(RISC OS 3.10) has been wasted.

etc.

>4.  Tack some extra data on the end of the template file and hope...

>The whole point of this idea is that, at the end of the day, your program
>doesn't need any non-standard template files

Well, three of your suggestions *do* need non-standard template files (you
have to put the new information *soewhere*), and the other involves cramming
more data into validation strings.

The other SERIOUS drawback is that you seem to like the idea of the template
editor outputting C code to be included directly into the target application,
which is fine for the AUTHOR, but makes it IMPOSSIBLE for users to edit
the templates to their own liking, one of the touted advantages of templates.
Would you prefer a program which you could easily personalise the
key-bindings, menu layout, and window layout for, or one which is
hard-wired by the programmer to do everything exactly as he/she liked it?

Why not just make a clean sweep and go for a new, well designed template
file format, rather than makeshift hacks to the existing system?

In any case, you need a new template editor, and some better support for
the new functions offered by the new templates in the target application, so
why stop at a single little thing like tagged icons: Why not come up with
a new template format that fixes almost everything in one go?
(I refer you back to my recent post suggesting a new template format which
supplies tagged icons, new improved icon types/classes such as sliders and
icons that know that they can be dragged, etc. as well as menu templates and
full application key-binding definitions, ALL stored in the new template
format.

>or new libraries, and users can still use !FormEd to tweak the templates
>if they feel inclined.

Well, no. They can tweak the basic windows behind the templates, but they
are denied the ability to tweak any of the extended functions that the new
template editor provides. (Unless programmers are suddenly going to release
their source code with the distribution... ;-)

>The problem with using a new template file standard is (a) I don't think
>you could ever get it to work with RISC-OS lib without horrendous kludges.

Who bloody cares about RISC OS Lib? It is widely acknowledged that RISC OS
Lib is a load of crap!

Wouldn't you rather have something BETTER than RISC OS Lib which supported
the NEW template system? Because this is what we are suggesting: A new
template format, a new template editor, and new support code to make
life really easy for both the programmer and the end-user.

>(Yes, RISC-OS Lib is c**p, but I wrote a few programs before I realised
>that and I don't fancy re-writing them!) and 

So? Why not adopt the normal backward-compatability stance and simply
phase out old programs that can't keep up with the new system?
The old programs will still work, they just won't be able to take advantage
of the new features. However, most of the new features you can write into
your programs despite RISC OS Lib (DSEdit II is living breating proof of
this), only they are less easily configured by the end-user.

>(b) If those lads and lasses
>at Acorn & Norcroft sort us out with a nice C++ compiler and class
>library, you'd be back to square one.

...or maybe, if we're really QUICK about it, they will support the new
format (when they realise how much better it is), and all C++ programs
will be able to benefit from the system too.

Even if this is not the case, I would think that if we are willing to write
the C support code for this in the first place, that we would not find it
too difficult to find enough people to write an equivalent set of libraries
for C++.

Lets have some optimism, please!
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)