Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

søn, 17,.07.2005 kl. 23.15 +0200, skrev Arnaud BERCEGEAY:
> 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 ?

 I did not say WinDom is bad. I'm saying that if other libs TOO use the
AES like WinDom, the design of those libs are bad. Why? Because WinDom's
functions loose control. And this is the scenario you described when
saying that "one lib dont know what AES actions the other do". Terrble
if you ask me, and apparently I'm the only one thinking so. I'm being
outnumbered by a bunch, it seems and give up this discussion.

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

 Ok, probably great.

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

 Not familiar with GEMTidy...

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

 Agreed, this is the very purpose of libraries. However, I think more
specific approach is better than one large bloated lib.

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

 I can assure you that my own apps will have its own evnt_multi() apps
and use dedicated libs for each task needed within the app. I liker
smaller building blocks.

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

 Dont go too far, as doing so will make it work against its purpose.

> 
> 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 ?

 In lack of dynamically loaded libs, I think it would be a great idea to
include often-used or very good ideas into the AES itself. I'm probably
the only one thinking this as well.

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

 That depends largely on the nature of the feature, but for the big part
I do agee here.

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

 This is the problem, you refuse to the benefits, only whats 1 cm away
from your noses.

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

 Then you are sure about something thats wrong.

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

 And who was worried about applications NEEDING the outer extents of
windows? You see things in X number of ways, and now this?

>   
> Applications can still control both WORK and FULL area of the window. So

 Wrong. Applications can ONLY control WORK area when in WCOWORK mode.

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

 How many times have I stated that its either ONE or THE OTHER, and NOT
BOTH? This is why I'll keep the functions, not invent new ones, for
WCOWORK.

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

 You are wrong.

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

 Then that application will be breaking WCOWORK programming guidelines.
We both know that apps that broke Atari's programming guidelines wont
work under any AES that is multitasking aware. If you come up with a
sceme that is so foolproof that you dont need guidelines, let me know.
Add to this the fact that you dont see any advantages, and think I'm
doing this _just_ to ease AES programming.... we're at a dead end.

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

 If this was the only goal, that one bit would be enough. However, the
goal is much greater. This is what I think has been the problem a long
time, inventing things that look great with some things, assuming that
more is never gonna be necessary. This kind of thinking is what create
things we struggle with today, like WDIALOG, AV_PROTOCOL, OLGA, SLB,
etc., etc. I'm not gonna follow that way of thinking.

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

 Well, you do what you want to do, and I'll do what I want to do.
Narrowminded thoughts spanning no more than 5 mins ahead in time is
something I dont have the energy to argue against. There is no hope. So
I'll just settle for the fact that your stuff wont be supporting XaAES
in the future. Too bad.

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

 You obviously dont know what you are talking about here. Did you even
look at the TosWin sources to see why CALCx2x is there?


 Odd Skancke