[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] WCOWORK implementation : conclusions.



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.