NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/acorn/tech/1224

Internet Message Format | 1993-01-11 | 3.8 KB

Path: sparky!uunet!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
Newsgroups: comp.sys.acorn.tech
Subject: Re: new template format
Message-ID: <[e-mail]>
From: [e-mail] (TMOTA)
Date: Mon, 11 Jan 1993 01:33:56 GMT
Sender: [e-mail] (TMOTA)
Organization: Computer Science Dept. University of Auckland
Lines: 66


[talking about icon tags]

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

It's not all that inefficient, for the following reasons:
  a) You can have short tags. I would be happy with 4-byte tags, which can
     be compared very swiftly (rather than arbitrary strings).
     4-byte tags also take up no/minimal extra space.
     If arbitrarly length strings are used, then they need only be defined
     and used for icons whicah are actually used/altered 'by name' by the
     application, so you won't have to compare your way through screeds of
     icons to find the only button in the window which does something!

  b) You don't have to convert on *every* access. I think you'll find that
     most icon accesses are very infrequent, and only a few icons are accessed
     enough to warrant caching their WIMP-icon equivalents.

  c) As Glass format is going to supply extra functionality (meta-icons etc)
     some kind of lookup will have to be performed to some extent anyway - the
     program cannot deal directly in terms of WIMP icons all the time.

     The whole idea of (for example) a slider meta-icon is that you will
     refer to it as a single entity in the program and in the editor, and
     the support code will convert operations upon the meta-icon into
     operations on one or more WIMP icons to simulate the meta-icon's
     abilities.

>(2) What's the point?  Heretical, I know, but what do you actually gain by
>being able to decode icon names at run time?

Well, it has user-friendly advantages everywhere you refer to an icon
external to the program: References in debugging information and in
message tags, etc, for example.

It would also be handy for defining template sets for different languages
etc. without having to worry about getting the numbering exactly right -
you want the references to be the same for any icon: By defining a name you
can be sure, but if the name is converted to some arbitrary internal
reference by Glazier at edit-time, then you can't guarantee that the
relationship between #define names and actual references will hold over
all your different template files.

So due to this fact, and the fact that you have to do some
glass-icon-reference to wimp-icon-reference conversions anyway, I can't see
how you are going to handle everything correctly in a nicer way than icon
tags...

Note that many icons could be marked as unimportant, so that they don't have
specific tags, and are ignored when scanning for tags. This includes titles
and boxes and other inert icons. Writable icons can be looked up once to
find the indirected workspace, and then have that address cached, etc.

In DSEdit, I can only think of about 10 icons out of the hundreds I have
that would be 'touched' nearly often enough to justify caching their
handles in order to improve efficiency. Although there is an extra overhead
on accessing icons, remember that often icon updates are to do things like
responding to a click by indenting, in which case, an extra 100 cpu cycles
is a negligible delay... Also note that I believe that a large proportion
of icon accesses should move into the Glass support module, for example,
continuous update of a slider icon should be handled by Glass, not by the
user program, so the overheads do not apply...
--
[e-mail]cycledelectrons