On 3 December 2013 09:43, Jo Even Skarstein <joska@online.no> wrote:
On Tue, 2013-12-03 at 08:27 +0100, Helmut Karlowski wrote:
I think that's what JFL wanted to avoid, and I can understand that. The
AES should support such cases and not force the programmer to use
home-cooked stuff or "dirty" things like USERDEF.
The AES does support such things in a clean and well-defined manner -
USERDEFs... There's nothing "dirty" about this.
But there are limitations to the use of USERDEFs (at least there used
to be). Can we call wind_get(handle, WF_FTOOLBAR,...) in the USERDEF
callback function to get the rectangle list? It used to be forbidden.
The real problem here is that JFL wants to use AES toolbars, and AES
toolbars are not very flexible. If you want a horizontal toolbar on the
top and a vertical on the left, you have to manage this yourself. Adding
support for multiple toolbars is a much better solution than hacking in
a "work area" inside a widget. With multiple toolbars you will still
have a real work area. Problem solved.
That would be ideal, but unfortunately beyond my grasp since I'm not
the one developing the AES.
However, the easiest and quickest solution would be to write your own
windowed form_do(). It's not very hard, it's clean and it works with all
AES'es. And the code can be reused in later projects very easily.
I've done that several years ago and use it in my own programs who, if
I may say so myself, are not so bad regarding the use of GEM.
However, not everyone will have the patience of re-inventing the wheel
as we did and I was more thinking in terms of advancing what XaAES can
do to simplify developing new MiNT/GEM apps. For example, the WCOWORK
mode really simplifies the management of windows.
Another case in point, colours: if you want an object to be filled
with another colour than one from the default 16 colour palette you
have to resort to a USERDEF. That's another area where XaAES might be
able to do better than the rest some day (but that's for another
discussion :-) ).
Anyway, back to the topic. I still think that a new option like:
wind_set(handle, WF_OPTS, WO0_TOOLREDRAW, 0, 0, 0, 0);
that would send redraw messages for any redrawing done within the
toolbar might be useful. But this sure needs to be tested -- and
implemented first, which is another matter completely.