From mint-bounce@lists.fishpool.fi Wed Jul 20 20:57:32 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] WCOWORK implementation : conclusions. From: Odd Skancke To: MiNT List In-Reply-To: <42DE3FF8.6050802@utbm.fr> References: <1121808544.5660.30.camel@linuxbox> <20050719215349.6dlkrcbl47c4g88s@coolrunningconcepts.com> <42DDF84C.10409@asrael.franken.de> <42DE3FF8.6050802@utbm.fr> Content-Type: text/plain Date: Wed, 20 Jul 2005 20:53:19 +0000 Message-Id: <1121892800.5660.105.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, 20,.07.2005 kl. 14.13 +0200, skrev Olivier Landemarre: > Hello > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Hi! > > > >I followed the thread all the time and as there was the question for > >some comments, so here are my thougths on the topic. > > > >I understand the need for the WCOWORK-mode and i second it. As i started > >to code some smaller programs i found it quite anoying to convert > >between FULL an WORK-areas. WORK area was/is the area i cared about, > >FULL was what the AES told my about the windows. If there is a > >function-mode where a application only has to care about the WORK-area, > >i think this would be a clarifying and easier to handle step. > > > > > This thread is long, I can't read all and I was on hollyday's > > I just wan't to know exactly why WCOWORK-mode is for. I think only Odd > can explain it, is there a link for this that explain this? because when > I read some message it's not quite comprensive for me. Example here if > it's only to be more easy to convert from full to work area, there is no > interest it's less than 10 lines in a code, I don't think Odd add this > only for this! I suppose it was to be possible change at fly windframe, > I am wrong? If it is I think it's a way to do this (but I don't think > it's the best way). So if someone can explain exactly and simply. I will try to explain a few things that will be possible with WCOWORK mode. Mind you, these things have to be implemented first. This fact, that things have to be implemented first, is what makes certain ppl not see the benefit. New features or new things that dont have effect NOW is called incomatible, and of no use. Some of the things (altho not yet existing), will not be possible without WCOWORK mode. 1. The AES can setup offscreen bitmaps for the windows opened by the application. These 'window-bitmaps' only contains the WORK area of a given window, and this can be used for multitude of things. For example effectful windowing on hardware capable of it, or having the output sent over the network in a server/client solution. Ofcourse, much of this also needs VDI support. 2. Themes and changes thereof, as dicussed before, becomes unrestricted. The AES gains total control of a windows outer area without breaking anything within the application. 3. 'inplace windowing' -- in lack of a better term. This is an idea I have which I will test. Remeber that this is NOTHING DEFINATE, it is an idea I have which I will test out. Altho the stuff below is not defined in anyway it roughly outlines what its about. The idea is this; Each WCOWORK capable application can select to register itself as a IWS (Inplace Window Server, again lack of better term) by passing a structure like below to appl_register() (yes, a new call, which isnt only for this idea, or not at all. All hypothetical atm); struct iws_register { short iws_class; short iws_type; short iws_capabilities; char iws_name[32]; .... }; iws_class is a class code indicating what kind of service this applications provides, like; IWSC_VIEWER, IWSC_EDITOR, etc. etc. iws_type indicates what type of data or files it can work with, like; IWST_HTML, IWST_TEXT, IWST_WORD, IWST_JPG, IWST_HYP, IWST_IMG, etc. etc. iws_capabilities indicates what capabilities the server has, and iws_name is the name of the application. Now imagine HighWire and Qed each having structures like this; struct iws_server { IWSC_HTML, IWST_VIEWER, 0, "HigWire", ... }; struct iws_server { IWSC_TEXT, IWST_EDITOR|IWST_VIEWER, 0, "Qed", ... }; In addition to this, XaAES supports defining areas of an existing windows to be 'subwindows'. These 'subwindows' are 'windows in a window'. Each subwindow can be 'bound' to an IWS server. Now lets think about how an email program could use this, for example. The email program scans the available IWS servers installed in the system, and finds TEXT, HTML (and possibly JPG, IMG, PNG, etc). The emailer creates a window like normal. Then it defines a part of that window to be a subwindow for the message body, lets say x = 50%, y = 50%, w = 100%, h = 50%. This will make the subwindow relative to its parent, and resize accordingly. The rest of the window is used by the email program to show message-list. When the user reads a plain text message, the corresponding server is 'bound', using a wind_bind() call, which will do the following; Send a WM_WINDOW which contains the handle of the window the server should use. And here is the whole point of this idea; The only thing a WCOWORK client needs to do now is to NOT CREATE/OPEN the window for itself. It is already done. But the rest of the functions the server use for its own windows can now be used WITHOUT MODIFICATION. That is, the only thing necessary for HW to support to make this work is to skip wind_create() and wind_open() in its 'new_window()' function when 'new_window()' is called as a result of receiving WM_WINDOW. XaAES will deliver WM_REDRAWS, WM_MOVED, WM_REPOSED, etc. etc. to the correct application upon actions performed on the parent window. Please dont make comments about the hypothetical implementation above, unless one see something that may be a large, large problem. The idea is to illustrate what WCOWORK mode can do to our system while making it very easy for application authors to support. 4. Virtual desktops. This really falls into category 1, about offscreen bitmaps. 5. Ease normal application programming. This has been seen as the only reason I've implemented WCOWORK mode. Not even I am stupid enough to put hours into an implementation if it only removes some, as someone so adequately put it, window calculation logics. I had hoped you gave me greater credit than that :/ These are things I can think of right now. There are definately more things I cannot think of right now. If you see a problem that may appear in the future (other than it breaking compatibility with n.aes/magic, or making libprogramming harder), or have ideas about implementation or other features that may be wished for, I'm all ears. What I do know is that the above ideas will NEVER happen without WCOWORK mode. I also know that WCOWORK mode will make it very easy for application programmers to actually support new functionality that appear because WCOWORK makes it possible. .. oh, ok, not WinDom linked apps, as this will not support XaAES. > > I have my own gem library since 10 years, I have correct it with the > time, I not write any GEM code in my applications all interface is write > with GEM graphic C generator. As I can remember, I never look for wich > AES I use even use appl_getinfo (except perhaps for CICON support), I > look only if I use Mint or not for execution problems and at my know it > work fine on all AES (Even on single tos system), now I'm not against > new features, but I think it should be only new feature that are not > possible to add for a GEM client, the AES is a manager and should stay > manager. Perhaps now we should add new higher level feature as Windom > can provide, but it should be possible to add this on other older AES if > possible, I think it should stay GEM and not a clone of what it can be > find on X11, Windows or OSX (notice I dislike WDIALOG extension for this > and not support it in MyAeS) > > Just my opinion appl_getinfo() is what should be used :) The biggest problem with WCOWORK mode as I see it, is that applications that want to support WCOWORK and still be usable on older AES's need to do extra checks. This will complicate writing applications, and one needs access to both the older AES and XaAES. But I wont listen to arguments of that sort, because WCOWORK removes so many restrictions it deserves a shot. Best Regards Odd Skancke