From mint-bounce@lists.fishpool.fi Wed Jun 29 21:23:00 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] XAAES slow? From: Odd Skancke To: MiNT List In-Reply-To: <1120069366.7070.39.camel@taro.coolrunningconcepts.com> References: <42B09A61.9020204@yahoo.fr> <1118887948.12057.11.camel@linuxbox> <42B18304.3030406@yahoo.fr> <1118934446.15790.7.camel@linuxbox> <42B1AEE7.3010707@yahoo.fr> <1119105225.15790.70.camel@linuxbox> <20050619015454.t7xyf5g6awisk0o4@coolrunningconcepts.com> <1119177626.15790.88.camel@linuxbox> <42B6B87A.1080108@seznam.cz> <1119298313.15790.119.camel@linuxbox> <42B75568.3000709@seznam.cz> <1119340933.15790.149.camel@linuxbox> <42B850F7.7030503@seznam.cz> <1119384685.15790.177.camel@linuxbox> <1119388246.42b8825611b1f@imp4-q.free.fr> <1119389933.15790.180.camel@linuxbox> <1120069366.7070.39.camel@taro.coolrunningconcepts.com> Content-Type: text/plain Date: Wed, 29 Jun 2005 21:17:10 +0200 Message-Id: <1120072630.19330.68.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.7 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: ons, 29,.06.2005 kl. 13.22 -0500, skrev Evan Langlois: > On Tue, 2005-06-21 at 23:38 +0200, Odd Skancke wrote: > > > I cant believe this. wind_calc() does NOT work on a given window > > goddamned it! It has not window context. wind_get/set() does! What the > > hell is the problem with you all? I'm about to give up this shit! > > I can understand your frustration, but don't give up! I was a bit unstable when that came out ,-) > > The problem is people are talking about 3 different things - > 1 - The possibility that apps can deal with a theme change if they use > wind_calc to always check the deltas for the current theme. > 2 - The idea of backwards compatibility for broken apps that use > wind_calc wrong, and so wind_calc() should still return data for the old > theme for theme - and yes I know a window id not passed, but read on! > > My point was that if Windom is over-using wind_calc(), it would always > get the deltas of the current theme, and so it might allow the > application to automatically deal with a theme change while running > without having to tell it (maybe send all apps a resize message and hope > they figure everything out), assuming wind_calc() always gives the data > for the new theme. I don't think this is likely. If the application works exclusively on WORK area of its windows (using the WCOWORK mode, see other posting or newcalls.txt), no messaging by the AES would be necessary, unless the WORK itself changed in which case WM_xxx is sent, as if a normal move or resize happened. But I think that some form of notification will be present anyway, just in case unforseen situations require it. > > I think your idea of a "theme has changed" message is better, but its > not yet decided how an application is to react to this. It may be > better for the application to tell the AES - I can survive theme > changes, and I'll accept "theme has changed" messages, and only in that > case, and that case only, have wind_calc return data for the new theme, > not the old, AFTER the message has been recieved and somehow responded > to. Perhaps when an application has told the AES it supports this, send > those apps a RESIZE and then a REDRAW and assume those apps will respond > correctly. I think that we can say that when an application enters WCOWORK mode, it it also expected that it knows about Theme changes. > > wind_calc() for older apps would report the same data, for the old theme > that that application is still using, and new windows from that > application would use the old theme. > > Now - to make that work ... > > Have you considered storing the theme (or the deltas used by a > particular theme) by the application's pid (in the process table or > something along those lines)? wind_calc would then lookup which theme > that application is using and act accordingly. If themes for a > particular application aren't to change while they are running, then > this would provide the backwards compatibility that people seem to > expect. Yes, this close to what is done now. And this will be kept to be backwards compatible. What I want to see is new apps not act like old apps :) Best Regards Odd Skancke