[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.