From mint-bounce@lists.fishpool.fi Wed Jul 13 01:07:52 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib From: Odd Skancke To: MiNT List In-Reply-To: References: <42D3C702.3070205@seznam.cz> <1121198918.29088.12.camel@linuxbox> Content-Type: text/plain Date: Tue, 12 Jul 2005 23:04:06 +0000 Message-Id: <1121209446.29088.79.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.8 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: 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