🚀 go-pugleaf

In article <4897@svin09.info.win.tue.nl> wsinda@info.win.tue.nl writes:
>* Grouping icons
>  A very useful feature to build into a template editor. Is the current
>  format flexible enough to accomodate icon groups? It may be necessary to
>  add a 1-word prefix to an icon definition block. A value of 1 would
>  mean that an ordinary 32-byte icon block follows; a value of 2 indicates
>  an icon group (list of icons), 3 for meta-icons etc.

Very good idea.  But maybe we can have a look at the way Draw stores grouped
objects.  I think we can adopt the same way, something like :

Icon object definitions :
     0     4    Word specifing the kind of icon object definition block.
                What Dick suggested :
                1 = ordinary icon
                2 = group of icons
                3 = meta-icons
                ...
     4      4   Length of this icon object definition block
     8      ?   Icon object definition block, containing - ordinary icon, or
                                                         - group of icons, or
                                                         - meta-icons, or
                                                         - ...
     ?          Next icon object definition

As in Draw, group of icons can be nested.  However, there are certain
consequences if we are using this approach : the icon numbering could be the
order of apperance in the list of Icon object definitions.  And this puts a
restriction on grouping/ungrouping because this action can change the order
of the icon object definition block.

This restriction does not apply for the programmer because (s)he only needs
to remake the #define file but that's no solution for the user.

Maybe we should give each icon its own explicit number ?

>* Quo vadis?
>  Wouldn't it be nice if we could have an integrated programming environment,
>  in which you can
>    (1) design windows, icons and menus,
>    (2) write routines that are linked to the icons and menus, and finally
>    (3) let the environment build a wimp application from it
>  The plans for Glazier are a nice step into the direction of (1); StrongEd
>  supports the External Edit protocol so integrating (2) shouldn't be too
>  hard (after we have agreement on the data format); for (3) you'd need a set 
>  of make utilities, 1 for each programming language that is supported.

Yes, it would.  What about defining the menu format in the Glass file ?

John
tytgat@esat.kuleuven.ac.be
BASS