🚀 go-pugleaf

wsinda@wsintt02.info.win.tue.nl (Dick Alstein) writes:

>This posting is a Call For Discussion.
[long description of tags for icons in template files deleted]

(Now that's what I call net-friendly quoting!)

You may be interested to know that somebody (whose name escapes
my swiss-cheese memory) is writing a new template editor, called
!Glazier (from scratch). It's very beta prerelease at the moment,
but is very good, and extremely promising...

But there is more... He has got an official file allocation from
Acorn for a new template file format, with the hope of making a
new template format, as well as releasing C code (or possibly even a
module) to allow programs to load the new template format and
'emulate' all the new features by a combination of new code
and use of existing WIMP constructs.

Some of the ideas i have seen/suggested for this format are:
  Tagged format which is upgradable - Acorn's format is a little restrictive
  as it is basically just a core dump... ;-)

  New 'meta-icons' for example, a 'slider' icon that is designed in the
  template editor, and used as a single icon in the program, but is actually
  defined in the window as a pair of WIMP icons... ALL the handling of these
  types of icons will be transparent to the user/programmer, thus giving
  the appearance of a much higher-level of icon capabilities.

  Tagged icons. Refer to each icon by a unique name-tag

  Extra information on icons stored in the template (e.g. "If this icon is
  clicked, shade that icon", etc)

  Incorporation of menu templates: Tagged menu items are used, so the
  menu structure can be edited (put the quit item as a subitem of the 'file'
  submenu if you like), but the program will still respond to a click on
  'quit' by quitting...
  Inclusion of support for ESG groups of tickable menu items, etc.

  Incorporation of hot-key definitions

Thus, the template format would allow editing of a much greater amount of the
interface without having to alter the program at all. Ideally, you should
be able to radically alter the look & feel of the application, it's menus
and key-bindings, ALL with a single template editor package.

So any suggestions I will collect and pass on to him if he doesn't get them
for himself...
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)

In article ... wsinda@wsintt02.info.win.tue.nl (Dick Alstein) writes:

   * A standard for icon names, defining their maximum length and
   the way they are stored in a template file. This means that the
   file format of template file must be extended. The current
   format definition does have room for such an extension.

I suggest the maximum length for an icon name be at least 255. 65535 is
another plausible limit. Essentially ``as big as you ferreting like''.

--

Regards, Kers | "Once   I would have been glad   to have made your acquaintance
Renaissance:  | Now   I feel the danger   brought about   by circumstance."

In article <1992Dec14.223454.12513@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:
> [...]
>But there is more... He has got an official file allocation from
>Acorn for a new template file format, with the hope of making a
>new template format, as well as releasing C code (or possibly even a
>module) to allow programs to load the new template format and
>'emulate' all the new features by a combination of new code
>and use of existing WIMP constructs.

This is interesting.  Would you mind asking him to reveal the new template
format ? Maybe we have some suggestions for improvement.

>Some of the ideas i have seen/suggested for this format are:
>
> [new features deleted]
>
>Thus, the template format would allow editing of a much greater amount of the
>interface without having to alter the program at all. Ideally, you should
>be able to radically alter the look & feel of the application, it's menus
>and key-bindings, ALL with a single template editor package.
>
>So any suggestions I will collect and pass on to him if he doesn't get them
>for himself...

- multi file editing
- selection of icons in the template editor <> selected icons in the
  window definition (unlike in the otherwise excellent TemplEd)
- nice structured C source where we easily can add our own tools ;-)
  Or even better :
  A modular approach like in ArtWorks would be 'creme de la creme' : so we
  could share our tools without having to hack the C source.
- output of a text file containing all the menu, icon & window text.  This
  file could be used as input for the MessageTrans module.
- grouped icones (like in Draw)
- print facilities
- ...

John
BASS

In <4814@svin09.info.win.tue.nl> wsinda@wsintt02.info.win.tue.nl (Dick Alstein) writes:

>Upon which you have to adapt the program. You may have to check
>every line in which an icon is referred to. Of course you can get
>around it partly, by setting a constant or variable (e.g. put a
>line like '#define OK_button 2' in a C header file). But you
>still have to take care that the icon numbers in the template
>definition match those in the program. It becomes a real pain if
>you tend to develop a program stepwise (add a feature, test it,
>add another feature, etc.).

One solution would be imbedding the names in the template
file and then just adding the lookup to the library.

Better would be a combined template/code editor, so that 
you would edit code that should be called etc. when that icon
was activated.  All naming etc. would be taken
care of by the editor.

Dave
--
-------------------------------------------------------------------------------
- David Alan Gilbert - gilbertd@cs.man.ac.uk - G7FHJ@GB7CRG                   -
------(Programmers don't sleep - they just park their heads)-------------------

For C programmers, a partial solution would be to have a template editor
which maintained a .h file containing constant definitions for the icon
numbers (e.g. #define I_LOAD_CANCEL 1 ).

I think this would also work for Norcroft Pascal (which has the C
preprocessor) and could be adapted for basic (use variables instead of
constants and include them as a library).

If you edit the template, the .h file is updated and running MAKE will
re-compile any modules affected.

You need some way of remembering the constant names assigned to each
icon.  I can see 4 ways of doing this:

1.  The template editor saves its templates in it's own format, which
    could include the icon names and any other extras. When you
    save your file, you actually save 3 things:

    * The new format template editor file
    * The original format template file (this is what your program loads)
    * The header file

2.  When the template editor loads the template file, it also loads and
    interprets the .h file.  You'd need some "smart comments" and such
    in the .h file to hold other info.  Problem here is if the template
    and .h files get out of step you're stuffed.

3.  Use the validation string to hold the icon name.  This means that 
    everything has to be an indirected text or indirected text+sprite
    icon, but that is only a problem if you need to use indirected sprite
    only icons (which !FormEd won't do anyway).  If you're using RO3's
    slabbed icons or Interface then you're in this position already.

4.  Tack some extra data on the end of the template file and hope...

The whole point of this idea is that, at the end of the day, your program
doesn't need any non-standard template files or new libraries, and users
can still use !FormEd to tweak the templates if they feel inclined.

The problem with using a new template file standard is (a) I don't think
you could ever get it to work with RISC-OS lib without horrendous kludges.
(Yes, RISC-OS Lib is c**p, but I wrote a few programs before I realised
that and I don't fancy re-writing them!) and (b) If those lads and lasses
at Acorn & Norcroft sort us out with a nice C++ compiler and class
library, you'd be back to square one.

Does anybody know how to "manually" change the clock speed on a VIDC enhancer
(i.e. how to write to the AUX IO line that the switch is connected to) ?

Also, as I understand it, the A540 and A5000 must have something like a
VIDC enhancer built in in order to do SVGA - does anybody know of any
"Mode Definer" software (preferably PD) that is A5000/A540 aware?

In article <1992Dec14.223454.12513@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:
>wsinda@wsintt02.info.win.tue.nl (Dick Alstein) writes:
>
>>This posting is a Call For Discussion.
>[long description of tags for icons in template files deleted]
>
>(Now that's what I call net-friendly quoting!)
>
>You may be interested to know that somebody (whose name escapes
>my swiss-cheese memory) is writing a new template editor, called
>!Glazier (from scratch). It's very beta prerelease at the moment,
>but is very good, and extremely promising...

The name is Tim Browse, he isnt on the net at present, but you can
contact him via Arcade BBS (081) 654 2212. I have Glazier too, and it 
really is pretty good.

Andy
-- 
-------------------------------------------------------------------------------
Andy Mell, Applied Physics Department,  |   andy@santafe.edu
University of Hull, Hull, HU7 6RX       |   amell@nyx.cs.du.edu
England.                                |   torq@gnu.ai.mit.edu

In article <1992Dec15.100256.27370@gate.esat.kuleuven.ac.be> tytgat@esat.kuleuven.ac.be (John Tytgat) writes:
>In article <1992Dec14.223454.12513@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:
[...]
>>So any suggestions I will collect and pass on to him if he doesn't get them
>>for himself...
[...]

Sometimes, it would have been useful to have the details of 2 icons
visible at the same time, for comparison and checking purposes.
Possible this could be added.


Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******