Re: [MiNT] WCOWORK operating mode

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-13 at 20:29 +0200, Arnaud BERCEGEAY wrote:
> If you consider today model and futur model : application may be composed  
> by various dynamical libraries, and applications may exchange messages  
> (the AES is not the only one to generate messages for the application),  
> then you'll see the problem. Have you read my post about the modular  
> approach ?

OK - this is getting silly.  What dynamic libraries?  MiNT doesn't
support dynamic libraries yet!  You are going to introduce a dynamic
library API thats half-assed with no kernel support, but we can't use
new AES features for this new system?   The idea of looking for a
library in some cookie just boggles my mind.

How about someone actually standardizes on the dynamic library API, and
you can assume that ANY of these libraries will be using the new WCOWORK
mode?   A clean slate!  No more backwards compatible cruft - just clean
efficient design that will make everyone happier because applications
will spend less time working around 20 years of incremental changes and
workarounds.

Doesn't work on MagiC?   Well, give the supposed 50% of Atari users a
reason to switch and they will.   Hey, you can even use toolbars without
hacking around it!  

Sarcasm aside, A good document on installing the latest MiNT and XAAES
and where to put all the files and how to configure everything would be
a start.  Maybe more people would upgrade, especially if there was an
installer.

> At the moment, there are strong definitions on various AES features:
> 
> - WM_SIZED message contain the requested FULL area of the window

Nothing inside the window should ever care about a WM_SIZED message.

> - wind_calc() do the conversion between FULL area and WORK area

Don't need this conversion.  Application components inside the window
shouldn't care about the FULL area.

> - wind_set(WF_CURRXYWH) changes the FULL area of a window

Here I agree with you - this should stay like it is.

> Idem for data exchanged between applications when one application sends a  
> WM_MOVED message to another application for example.

Aweful example ... applications moving each other around?
For data exchange, I vote the AES note the mode of the sender and
reciever and convert if necessary.  This seems like the only sane thing
to do.

> The "optional" feature is the big problem because there's no more  
> consistency in the definition of AES API.

I understand what you are saying - but I think with careful design, we
won't have any of these issues.