🚀 go-pugleaf

jwil1@cs.aukuni.ac.nz (TMOTA) writes:

> NO! You *must* use *tags* for icons! We use messagetrans tags for text, and
> tags for window names, and we intend to have tags for menu entries, so why
> leave this stupid icon-number thing in place?

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.

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.

If the user wants to move an icon to the front/back, he can simply choose
'<' or '>' icons (like in ArtWorks) and internally this results in an
icon-number renumbering.  Note that this icon-number is *not* being used in
the program to determine a certain icon (we use iconnames for this), but only
when building up the window definition for Wimp_CreateWindow.

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.

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.

I think the latter is the most flexible one, but maybe not simpliest to deal
with.  Opinions, please.

> If you are really concerned about icon tags taking up a lot of sapce, then
> I suggest that icon tags are either:
>   * 8 bytes of text, or
>   * 4 bytes of text/an integer.

I never said I was concerned about space (although not in this discussion ;-)).

wsinda@wsintt05.info.win.tue.nl (Dick Alstein) wrote:

> Doing icon grouping as in !Draw has the advantage that it enforces a proper
> nesting (if two groups have objects in common, then one group must be a part
> of the other). However, in Draw files, objects are self-contained (except for
> font handles, I think); all data needed to render an object can be found
> inside the definition block. IMO, it would be best to split the Indirected
> Data tables and attach the data for each icon to the icon definition block. 

Why is it so important to make self-contained icon objects ? Would the split
of the Indirected Data tables make reading/writing Glass files not more
difficult ?

> A consequence is that you are limited in how icons overlap: if icon A
> overlaps icon B, then all icons in the same group as A overlap B. But I
> think that's not a big restriction.

On the contrary, I think it *is* a big restriction (see above).

> Another (logical) consequence is that you have to hide the icon numbers from
> the programmer; if the grouping changes, then the order of the icon
> definitions in the file may change completely; hence icon numbers are very
> "unstable", and the programmer should only refer to icons by their names.

Agreed.

jwil1@cs.aukuni.ac.nz (TMOTA) writes:

> In DSEdit, I have no default text in my application. This is simply because
> the messages file is so absolutely mindbogglingly important that there is
> no point in even trying to run without it... As the text for all interactions
> and the menus are messagetransed, I can't really see any point in defaults
> most of the time...

Neither can I.

> I would say the easiest way is to specify a bit which indicates that the
> text is actually a tag, and then in the application-side support code that
> is supplied with the template editor, put in a method by which these
> text items can be 'expanded'. Off the top of my head, I'd say a nice way to
> approach this might be to register a messagetrans decoding function with
> the support code, so it calls some user-defined function, passing in the
> tag, and gets back a pointer to the actual string...

Not such a bad idea.

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) ?

John
tytgat@esat.kuleuven.ac.be
BASS