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

[Odd Skancke <ozk@atari.org>]

ons, 13,.07.2005 kl. 00.01 +0200, skrev Arnaud BERCEGEAY:
> 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.

 Well, the idea here is to make things as flexible as possible, and
guess why that is a goal? So the USER can benefit from it.

> 
> > 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 what you have stated before, but ok

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

 Ok, here you should really take a second and consider what these
components should know about. In my optinion such libraries should only
know the cooridnate of where to output 'its function'. Be it in an
offscreen bitmap, be it inside an apps window or whatever. All the above
libs should not even know the AES exists. These libs should have
functions to update part of its output area, etc. It is the job of the
AES kernel (.app) to figure out which lib outputs to what area of the
application window, and call that libs 'redraw" function upon
WM_REDRAWs, for example. The .app is the administer, while libs are
slaves. If you bake in AES awareness into these libs, you will kill the
libs versatibility greatly.

 For example, the editbox lib should get MFDB describing its output
area, same should any function doing any kind of graphics/text output.
When user wants to print something (lets say a web-page) including that
editbox, it should be possible to just create an offscreen bitmap with
enhanced resolution, build a new MFDB for the page to print and have the
lib output to this page by redrawing with a MFDB describing its position
within the page. Or the area could be an offscreen bitmap for network
features, or it could be direct to screen, located somwhere in a window.
Nothing at all to do with the AES.

> 
> This is the idea of the modularity approach.

 And a very nice idea it is. But dont confuse things, and dont
overcomplicate it.

> 
> This modularity feature mechanism is still under construct. The first  
> piece was gemlib 43. Now, we're working on COMPONENT stuff and MT-windom.

 This sounds like overkill. These libs should not be part of a gem
library.

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

 Ok, this is death by implementation instantly. I wont let such
designflaws affect my development. The libs described above MUST NOT use
the AES indipendantly. That is the user of the lib's (the .APP) job!

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

 workspace reorg is the applications task. Not a library task at all. At
least not without the application asking it to do such a task.

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

 As long as the libs run in the context of the caller, this is not a
problem. All info needed for such a reorganizer is available via
wind_get().

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

 Because you loose a lot of overhead caused by less traps. The AES is
given total freedom related to window borders. This can be useful in a
future scenario were the AES gets networking capabilities where the
server renders the window and the client owns the theme (borders). Theme
handling is greatly enanced locally too. If you look at the TosWin2
sources you can see this mode simplifies the application programming.
Ofcourse, in a transitional period where one wants to support as many
AES's as possible, this is, as you said, 'complicaing' things. But one
needs to move on sometimes to gain access to new future features.
Besides, if gemlibs support new things such as this, the application
programmers job would be even easier.

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

 I cant think of all benefits that may arise in the future. But I can
see that it lifts a lot of todays restrictions.

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

 Take that above and apply to your dynamically loaded lib idea (the
components) above and you get somehwere. And yes, this is possible with
WCOWORK mode, without the application actually knowing it.

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

 You think a new set of functions is better?

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

 Well, atm I see what restrictions WCOWORK removes. I will collect the
good points as I come across them and add to newcall.txt. Sometimes I
get the feeling that the good points need to be available for WCOWORK to
be considered a good idea. But that is impossible because it is WCOWORK
that makes such featurs possible, imo.

 Please rework your idea for the libs described above. The idea is great
but the implementation is terrible if each lib works like I think you
described.


 Odd Skancke