Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-13 at 00:01 +0200, Arnaud BERCEGEAY wrote:
> Don't you think it's a good remark ? If a new feature mainly introduce  
> incompatibility and nothing for the user, then it's a bad feature... and  
> it's my feeling about WCOWORK.

There is no incompatibility at the user level, except that XaAES is
needed and not N.AES or MagiC, and we already said this is about the
worse argument ever.

> > and "Dont make
> > new things as they wont work on other AES's".
> 
> This has never been one of my arguments.

So what is the incompatibility for the user?

> This is the idea of the modularity approach.

You would probably really like the project I'm starting - a programming
language / glue language, actually.  It goes way beyond conventional
modular programming to the point of being "experimental" in nature.  I
have much to do before there anything to show people though, and I'm
sure everyone will hate the syntax.

> All these libraries are independant and don't know what other libraries  
> do. If one piece of code enable the WCOWORK feature, then all the  
> libraries will get into trouble because values returned by some AES  
> functions depend on that mode.

Not if your library is written right.  A good library isn't going to
tell these components anything about AES messages.  They may need to
know what part of the screen needs a redraw, but those messages haven't
changed.  Are you really saying that your "component model" system where
all the libraries are independant will actually be so dependent on the
AES messages and raw window functions?  It would be Windom's job to set
or not set WCOWORK and provide a suitable abstraction from the OS to all
of the components.

> So, when a lib call wind_set(WF_CURRXYWH) to set the FULL area, maybe this  
> will change the WORK area... when a lib (workspace reorganiser) will send  
> to the application some AES messages to move windows, some of the window  
> will interpret the values as WORK area and other as FULL area...

And when will a library component do this?  This seems like a contrived
example for a library that isn't doing its abstractions properly.

However, I would like to say that wind_set(WF_CURRXYWH) should always
set the complete area, and not the working area.  There is already a
wind_set(WF_WORKXYWH).  WCOWORK applications would simply rarely use the
WF_CURRXYWH, but its there if needed.  I don't see a reason to remove a
capability and make it redundant.

> The *only* problem is that some data may now have two differents meanings  
> depending on the WCOWORK mode. Without this mode, the meaning of the data  
> is clearly defined and may be safely used by any piece of code.

User interface and functionality should be clearly seperated.  I don't
see any reason for application "components" to be given anything but
working area coordinates.  Rearranging windows isn't an application's
job.


> > In combo with VDI support, WCOWORK will
> > allow for the AES to keep WORK areas of windows as offscreen buffers,
> > excellent for future stuff.
> 
> At least one serious argument :)
> 
> You'd like to have a kind of virtual workstation per window. It's fine. No  
> argument against that feature... Now we can take the question in the right  
> order :
> "we want application to control a "virtual workstation", wich will be  
> displayed in the work area of a window, and we don't want the application  
> to care about the borders of the window."
> I have correctly understood ? Please correct me if needed.

This is why I was originally suggesting that you not even bothing with
working coordinates.  If the VDI workstation was relative to the window,
then only the VDI needs to know the working coordinates.  Everything
else is relative to 0.  This can really simply a lot of things.
Applications won't care if the window is moved, blit it to a new area,
and the application still works even if you don't tell the application
that the window was moved!

Let the AES control the window, and the application control the
contents.  The VDI can draw directly to the window or to an off-screen
bitmap depending on the hardware capability, memory, and preferences of
the user.

> Before you post, WCOWORK seemed to be a very bad feature to me.
> Now, WCOWORK seems to be a very bad temporary intermediate state in the  
> developpement of new feature.

Now here is where I almost agree.  There hasn't been very much
discussion of WCOWORK, and my primary complaint is that it may be an
intermediate state.  If we do a massive change to the AES, and force
applications to choose which they will use, lets give them just the two
choices, and not 3 or 4.   Lets make sure this will cover all needs well
into the future.