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