[MiNT] WCOWORK implementation : conclusions.

["Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>]

Hi list,

I've carefully read all the posts in this mailing list related to WCOWORK.  
Please read carefurely this one.



About the library concept.

i don't want to re-invent the wheel all the time. For example, for GEMtidy  
i've developped some functions to handle a "wout" window.

I then see that these funtions could be used *as this* by any other  
application, without any modification. So i get all the functions, compile  
them and here is woutlib. Now, if a developper wants to have that kind of  
window in its application, he just have to link its application with  
woutlib and add some wout_xxx() when needed in its code. He doesn't have  
to re-develop once again new "wout" functions.

I've heard that such approach is a hack, a bad design, something idiot...  
What is idiot in the story : to help other developpers by providing a set  
of lib so that they don't have to re-invent the wheel for each  
developpement ?

Of course, this library will use AES functions because it runs over the  
AES layer.... and of course it's not portable to other platform (linux,  
macos...) because it requiers the AES to run, but what's the problem ?  
oh... it also requiers a VDI for the output; it's even less portable, but  
it's just perfect for GEM developpers :)

Anyway, this is very usefull, and i don't see anything idiot there.

Last : this is not a problem with futur developments, this is a problem  
with today softwares (GEMtidy already exists for years for example).




About the simplification for programmers.

I see two kinds of GEM developers.

1. old scholl developers that re-invent the wheel on each development.  
When such developper want to develop a new application, then he copy 'n  
past another application and change what need to be changed to make the  
new application.

2. intelligent/lazy developpers that re-use already proven-to-work code,  
so that they don't have to redevelop anything for a new application : the  
.C files developped contains only the code specific to this application.  
All "common" stuff already developped are provided by libraries (windom,  
woutlib, gslib...).

The 2nd type of developpers has a lot of advantages :
- if a bug is fixed in the management of evnts (windom lib for example),  
then all the application will benefit this fix
- the developper has just to focus on code specific to the application,  
nothing more.
- if a new feature appears in the AES (mouse wheel, WM_REPOSED...), then  
this could be included in windom and then all windom applications will  
benefit.
- if the application contains an usual type of window, if the developper  
is cool then he could split its code to isolate the management of that  
window, and make a lib so that all other lazy developpers may benefit from  
its work in their applications.

You can class me (and windom users) in the 2nd type of developpers. AKAIK,  
toswin is in the first type (that application has its own evnt_multi loop).

If you want to simplify the programmer life, i suggest to become an  
intelligent/lazy developper, re-use already written code, and provide  
re-usable code to others. That's what we do with windom, and we want to go  
even further with next version of windom.

If the features introduced in the AES is already provided by high GEM  
library, then the benefit for programmers (2nd type) does not exist. The  
only consequence is that developper of library have to work on their lib  
to support the new AES feature... all that to have exactly the same  
feature ?

If feature introduced in the AES is a real new feature (mouse wheel, or  
WM_REPOSED message for example), i mean this is something new that old AES  
never report. If application want to use these new features, then  
applications have to support these AES functions, and the best place is  
the main GEM library.

For WCOWORK feature, there will be no advantage at all for developpers  
(only some hours of work for the library developper and some possible  
incompatibilities problem already explained).



To end, let's talk about WCOWORK.

At first, i though it was just an half step. Now i'm sure it's a really  
bad hack.

At the moment (without WCOWORK mode), application can control both FULL  
and WORK area.

I though (and sincerely hoped) that new mode will allow the application to  
control *only* the WORK area, and not at all the FULL area. I was wrong.  
Applications can still control both WORK and FULL area of the window. So  
how this feature can benefit for the futur ? AES still has the constraint  
that applications (even WCOWORK compliant applications) may control both  
WORK and FULL area. Such mode DOES NOT allow the AES to do more things,  
because the application can still be aware of the size of the border, of  
the size of the desktop, etc...

With WCOWORK, nothing has changed for the AES, except that old-school  
developpers may simplify a bit their application and intellignet/lazy  
developper may see their application no more work under XaAES...

For theme change, the only constraint for the application is to not store  
any AES data. It's independant of the WCOWORK mode... and windom  
applications do not store AES data, so windom applications are already  
ready for theme change for ages !!! There is nothing related at all with  
the WCOWORK feature. With WCOWORK as it is now, AES cannot modify the FULL  
area of a window without telling the application, even if the WORK area is  
kept unchanged, because the application can still have access to the FULL  
area and store these data.

If you want to detect that kind of application (ready for on the fly theme  
change), then just one bit is enought, just one bit for the application to  
declare it's a clean application that does not memorized AES data (size of  
border, etc...) : application asks the AES when needed. That kind of  
application do not need to be work with the WORK area of the window only.  
There no relationship between the two.



Conclusion

Now, i'm sure WCOWORK mode (as it is implemented now) won't help windom  
user, and won't give any further liberty to the AES (i really hoped this  
was the case)... so i will never use it. I don't want to spend hours  
coding new stuff just for the fun to introduce incompatibilities. As a  
consequence, none of the libraries will support this feature, and none of  
windom application will support this feature. If an application wants to  
use some of the libs, then the application shall not enable that mode.

Maybe we'll find later another way to implement a real "WORK-area only"  
feature, but this is for sure not this one...



best regards,
Arnaud.