🚀 go-pugleaf

I shouted:    ;-)
>> NO! You *must* use *tags* for icons!

>I agree that using tags for icons is a good idea.  But if you are only using
>tags for referring icons you lose information about the icon overlap (Dick
>Alstein also noticed this).  This is eg. very important when you are using
>certain 3D icons.

I disagree. I think you are talking about overlap as in "this icon is in
front of that one". This can still be achieved, as the icon numbering that
we are currently stuck with gives you that, and it is implicit in the
order of storage of icons in the file.


>Therefore I suggested to include also an icon-number together with each
>icon definition.  This icon-number is in fact totally invisible for the
>Glass editor user and will define the icon order in the window definition.

In fact, the icon number is implicit in the file-storage. This means that
there is a restriction on the user program creating WIMP icons in a
sequential pass through the icon list in the file, and that the editor
allows you to alter the order with "move forward/back" and "put to front/back"
operations, just like in Draw.

>This system allows the user to move the icons.  However, when we want to
>allow user to create new icons or to delete icons (do we want that ?), an
>icon renumbering has to happen, so we're back to point zero.

No. The important thing about the icon ordering is only the *relative*
order, i.e. higher-numbered icons are in front of lower-numbered ones.
If we delete icon 4, then all following icons move down one place in the
file, but they all hold the same *relative* positions. When moving an icon
forward or back, you simply swap it with the icon below/above it, thus only
changing the order of the 2 icons you are working on. No problem.

>Maybe a better way could be : if there is an icon which has to be absolute in
>front of certain other icons, it can have a list of their icon names somewhere
>in this icon definition.

No need. You don't have this kind of feature in a drawfile, do you? But you
still manage to get the correct stacking order.

Note also that meta-icons (a combination of several normal WIMP icons to
create special things such as a "volume-slider" icon) will have a special
order within the meta-icon, so will always appear in the correct order.

...

>Another point I would like to raise is : are we going to support Acorn's
>Help application by defining a help string in each window/icon and menu entry
>(it should also be language independant) ?

What about the way I support help in DSEdit II?
This calls a generic (program-wide) event handler for help requests, and
creates a tag of the form
  "Window-template-name.icon-number"
e.g.
  mainwindow.3    - icon 3 in mainwindow
  mainwindow.-1   - window background

which is passed to the DeskLib Msgs code to get the message.
If no message is found, it returns no help.

This means that the program generates a standard help request to the message
system, and has no need of knowing about specifics of which messages
are/are not available. The message system allows message definitions like:

  mainwindow.-1: This is the main window
  maintool.-1: This is the main tool window
  sound.3: This is icon number 3 in the sound window

  sound.*: This is anything in the sound window
  main*.4: This is icon 4 in either the main window or main tool window

etc.

So you can put in help for any icons you feel like:
  dialogue.0: Click here to start this operation
  dialogue.1: Click here to abort
  dialogue.7: Isn't this pretty?

...with a default for any other area of the same window:
  dialogue.*: Point somewhere more interesting!

I can completely change the level of help given by DSEdit by simply editing
the messages file: No re-compilation is necessary!

Obviously, if icons also had text-based tags, this would become even nicer:
  dialogue.okbutton: Click here to crash your computer!

This way is also better, because you can have multiple files for different
languages and stuff. Defining these messages within the template editor
would be too restrictive (though it can use the ExtEdit protocol to allow
you to more conveniently edit such message files in a text editor...)

And also, the help can be left until the end of program development to
save you re-writing it every time you make any changes!

(Oh, and another thing that's nice with DSEdit's help system is that Msgs_
allows me to load multiple files, so the 10kB of helptext is only actually
loaded when the first helprequest is recieved. This is another advantage of
having a good, centralised, generic, help handler...)
-- 
themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons