home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pipex!demon!kernow.demon.co.uk!vulch
- Newsgroups: comp.sys.acorn.tech
- From: vulch@kernow.demon.co.uk (Anthony Frost)
- Reply-To: vulch@kernow.demon.co.uk
- Subject: New Template file format RFC
- Organization: VCS Kernow
- X-Mailer: ReaderS for the Acorn Archimedes
- Date: Fri, 8 Jan 1993 20:42:06 +0000
- Message-ID: <930108204206@kernow.demon.co.uk>
- Sender: usenet@demon.co.uk
- Lines: 73
-
- I've been passing all contributions to the template file format discussion
- to Tim, he has asked me to post the following...
-
-
- ----------------------------cut--here-------------------------------------
-
- Re:Glass files - a short addendum...
-
- A few people have commented on the naming of icons and asked how the lookup
- of icon names would work - a library? a relocatable module?
-
- Now then, here I must confess to being a bit of a heretic - I'd always
- thought that a constant header file would be generated and would be used
- with the source (whether for C, ARM, BASIC, Pascal etc). ie the
- compiler/assembler would actually use the icon number directly (via a
- #define) or in the case of BASIC, the interpreter would use the variable
- contents to get the number. There may be problems in getting this to work
- with BASIC (I looked at using LIBRARY to do this - I think it's a
- non-starter as it won't share variables) but there must be *some* way to do
- it reasonably elegantly, and, as Dick Alstein pointed out, BASIC is handy
- for small apps, and it's dead cheap (=free); I consider ensuring that the
- format is usable by BASIC important.
-
- There are two reasons why I don't think icon names should be used at run
- time:
-
- (1) It's inefficient. Just think about it - *every* time you change an
- icon's contents, set its flags, read its selection state, decode a mouse
- click - you go through a string look up table routine. This may be
- acceptable to some people, but not to me, because, well...see (2).
-
- (2) What's the point? Heretical, I know, but what do you actually gain by
- being able to decode icon names at run time? If you change a name, the
- source has to change too - so recompilation is necessary. If you change icon
- names around, the program no longer works properly - so why do you need it?
- Why not just leave it to the compiler/interpreter? There's only one
- instance I can think of that that might warrant it:
-
- You want to change the icon ordering - without string lookup this
- will require re-compilation.
-
- But why would the *end-user* want to do this? It would be a *very* minor
- advantage for the programmer to be able to do this without re-compiling.
-
- In summary, I don't consider the overhead (having to keep icon names in
- memory, having to scan them for every icon access) to justify the additional
- functionality (which I perceive to be zero). I am open to suggestion - if
- anyone can think of any reason why run-time look up would be desirable, post
- to this group - giving a convincing example! I am, as you may have divined,
- somewhat sceptical, but I don't mind being proved wrong. Also, failing a
- suitable alternative solution for BASIC, we might as well do it...
-
- As to the suggestion of a module to support loading etc of Glass files -
- this seems a good idea as it negates the need for specific prog.lang.
- libraries, and avoids duplication of effort by co-resident applications.
- Comments? Anyone against this?
-
- Finally, thanks for the general tone of the comments on the format so far -
- helpful, constructive and technically sound. Keep it up :-)
-
- Tim Browse.
-
- PS. I know BASIC does a string lookup to access variables anyway, but
- that's a side issue. I don't see that it warrants run-time look-up.
- Unless you know better?
- PPS.Stop press - I've just thought of a reason which may justify decoding
- icons at run-time, but I want to see if anyone else thinks of it :-)
- If you want a hint, have a look at Glazier's template file(s).
- |
- this is a clue ! --------+
-
- ---------------------------cut--here---------------------------------------
-
-