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

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

Hello,

Back to "open discussion" ? :)


"think about the USER"
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. 


and "Dont make
new things as they wont work on other AES's".


This has never been one of my arguments.
If we need to break backward compatibility to introduce usefull new feature, then go ahead ! 


This is not a problem of backward compatibility, this is a problem of
death of the ongoing hudge work we started since years now in order to
have a modularity approach of programming for *futur* AES applications.


 Enlighten me!
modularity approach. AES Application = a kernel (.app) and a lot of dynamical libraries, each specialized in one thing. For example a library to manage a text editor box, a lib to display an image, a lib to reorganise the workspace, and so on... A lib may use other libraries... It's a kind of puzzle game to develop an application. Then, if one want to develop an "internet suite" for example, he just have to "assemble" internet protocol lib, HTML viewer lib, text editor lib... If one want to develop a "help guide viewer", he just have to assemble "html render" lib, "1st guide render" lib, and so on... That's the idea of modularity. We call it COMPONENT in windom. For example, a form in a window may contain a COMPONENT "html render" which may use the "image viewer" COMPONENT, and so on... 

This is the idea of the modularity approach.
This modularity feature mechanism is still under construct. The first piece was gemlib 43. Now, we're working on COMPONENT stuff and MT-windom.
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.
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...
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.
About the benefit of WCOWORK, i'm still waiting for the aim of that solution. 

the snap stuff is clearly not a serious benefit IMHO.


Second biggest advantage, again from
an application authors point of view, no need to worry about what goes
on around its windows WORK area.
WHY is that an advantage ? Please explain ! And what about windows that want to control their FULL area ? 


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.
If so, we can discuss about the best way to reach this goal, and i really don't think we need to break the backward compatibility (meaning of data of AES API) for that purpose. 

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.
I stop here. The post is long enough and i've learned that long post are not carefully read. 

best regards,
Arnaud.