From mint-bounce@lists.fishpool.fi Fri Jul 22 01:53:11 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <20050721174810.2cs9v9h6llkc4oss@coolrunningconcepts.com> Date: Thu, 21 Jul 2005 17:48:10 -0600 From: evan@coolrunningconcepts.com To: "olivier.landemarre@utbm.fr" Cc: MiNT List Subject: Re: [MiNT] WCOWORK implementation : conclusions. References: <1121808544.5660.30.camel@linuxbox> <20050719215349.6dlkrcbl47c4g88s@coolrunningconcepts.com> <42DDF84C.10409@asrael.franken.de> <42DE3FF8.6050802@utbm.fr> <1121892800.5660.105.camel@linuxbox> <42DF4B2A.1040603@utbm.fr> <1121986933.5660.159.camel@linuxbox> <1121984741.42e020e53a561@webmail2.utbm.fr> In-Reply-To: <1121984741.42e020e53a561@webmail2.utbm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - coolrunningconcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: evan@coolrunningconcepts.com 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.1 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, NO_REAL_NAME, TO_ADDRESS_EQ_REAL X-Spam-Level: Quoting "olivier.landemarre@utbm.fr" : >> Others have commented on this, all I want for now is to establish the >> fact that this is not possible with todays handling of window >> coordinates. Do we agree that WCOWORK is the first step on the long road >> to such functionality? I think that moving to a WORKAREA-only coordinate system is desireable. I don't believe that the implementation of WCOWORK is the best way. I understand that using new calls is a way to force the application to only use WORK coordinates, but it should also be possible for application to set the FULL window size in some situations. There is also the library issue, which I won't argue here again. For the "sub-window" idea, its very simple. There are no window borders or widgets around the sub-window, no their size is 0, so naturally wind_calc and the wind_xget conversaions should simply return the original coordinates that were passed into them when used with a sub-window. WCOWORK is cleaner, but the method I suggested is more likely to be acceptable by everyone. > Yes it is first step and yes it is a long road. Your talking about a complete API change, using the existing API calls. I would much rather see the new API be new calls. Mixing would be discouraged, but it would still be entirely possible so that linking with old libraries would work just fine. >> Also keep in mind that a 'mix' of WCOWORK and >> normal operation is not an option. I think that bring unnecessarily >> complexity to both the AES and the applications. Therefore I will not >> invent new functions for WCOWORK. Unless someone convince me otherwise. > Ok I have to do some try soon. I understand your concern. But I think if you look into it, the problems of mixing the two can be solved easily, especially if you use the API I outlined which completely seperates the two APIs. I'd be happy to address specific issues you have with the implementation I suggested. You have already had plenty of uproar against your current method. >> > > 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. Can be done I think as long as the application doesn't store the results of wind_calc. We've already been shown that windom allows this. If you switch solutions to one that windom developers are okay with, all that is needed is a "I can handle a theme change" call of some such, and I bet they would be more than willing to add a call that proclaimed they could handle on-the-fly theme changes. > I think only it should be possible already to change themechange(with > widframe > with different size of course) for older applications without adding > WCOWORK I'm > perhaps wrong but I think be able do it. I agree. > window, and if you need a part, you should probably extent this with a part > number with a wind_get(WF_WORKXYWH_PART) or something like this. There is > nothing more to do, and it's quite more logical than add a new mode, this is > only a default application design if software not use it and compute > diffrence > beetween fullarea and workingarea (my own softwares do this :-( ), as most > software patch themself RSC for example select an object not the best > but there > is already functions to do this. Imagine multiple windows right up against each other, with no lines seperating them and only 1 set of window widgets (one windframe) for all the window areas it contains. The application sees its own working area, but the user sees 1 window with multiple applications in it. >> Its for editing too. Lets take an emailer for example using Qed to >> compose messages. To Qed, the only difference between one of its own >> windows and a window handle received via WM_SUBWIN is that the SUBWIN >> isnt created/opened by Qed. Now the emailer can just forward kbd events >> to the service bound to the subwindow. Or perhaps the AES can housekeep >> topped subwindows, as if parent window was root window, this is a detail >> needing discussion, but in that case the AES sends the kbd directly to >> the 'owner' of the subwindow (which is the application 'bound' to that >> subwindow) The issue here is Qed wants to save the window contents to a file, and it expects its own menu bar. The mailer ideally, would just want a pointer to the data being held by Qed when you click "Send" or whatever. This is more of a component system. I have my own ideas on how component systems should work internally, but have not yet decided on the display semantics. You've got the display semantics, but haven't considered internal interaction. It will be a bit more complex than you describe since something has to share the data! I also think if you rewrite these apps to act as a component system to share the data, then sharing the window is just as simple and can be done in userspace. >> Yes, it is sort of a frame. But this is something a lib cannot >> housekeep. The AES has to support this at a low level for implementation >> to be 'complete'. The only reason the AES has to do it instead of the application is because you are trying to glue independant applications together by having more than 1 window per window handle. You haven't addressed data sharing at all,nor have you addressed the menu bar. This seems like a hack more than what you really want, which is a clean component system with the abstractions required to do it right. >> > > XaAES will deliver WM_REDRAWS, WM_MOVED, WM_REPOSED, etc. etc. to the >> > >correct application upon actions performed on the parent window. And in this "HW displays the rendered version of Qed" application, how does HW get the data that exists in Qed's edit buffer, and which menu bar is displayed? If there is a toolbar, which one is displayed and where? It looks like we have three people or more that want the features of a component system, windom wants the same thing, but implemented differently. This is where all the arguments come from.