From mint-bounce@lists.fishpool.fi Fri Jun 24 01:39:31 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42BB46F0.4090206@chello.nl> Date: Fri, 24 Jun 2005 01:34:08 +0200 From: Henk Robbers User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MiNT Mailing List Subject: Re: [MiNT] usage of wind_calc() References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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: h.robbers@chello.nl 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=2.1 tagged_above=-50.5 required=7.0 tests=BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** Arnaud BERCEGEAY wrote: > Hi list, > > > Now, it seems that wind_calc() is an heavy function in XaAES... For > sure, we can take this into account in windom, and try to use others > AES functions to do the same job if it works fine in other AESes too > (windom is not designed for XaAES only)... and that's because > wind_get(WF_WORKXYWH) is buggy in some AESes that windom uses > wind_calc() to compute the WORK area, so we cannot safely use > wind_get(WF_WORKXYWH). > In all my GEM programs I keep track of many rectangles about a window. One of them is the "border size" rectangle. Its components x,y,w,h contain the distances from the work area to the full area in all four directions. I use wind_calc to obtain these values. I use it after I know where I want the workarea and before I create and open the window. So I need and use wind_calc only once per window. I have always understood that this is the essential function of wind_calc. Whenever I need to recalc either full or work area, I use my own "border size" rectangle. I need only 4 adds or subtracts. Not even a AES call. Might be a good idee for WINDOM? You are right that wind_calc can not be deprecated, but its usage can easily be kept very low. wind_calc is essential because it gives you the amount of space occupied by window borders independent of AES and screen resolution. Part of this essence is that its usage is associated with windows in general, not a particular window. > > Now, some words about the evolution of XaAES. I think that themes are > great. Changing themes on fly is cool... i'm not sure it's very usefull > (this may add complexity in all applications), but i've nothing against > this ;) > > My point of view about themes is it's global to the AES (all the > applications should have the same look'n feel). > I would like to use different themes for different type of content within the same application. > Now if you want to make this configurable on the fly, then the > applications should do something (at least inform the AES that the > application can handle change of theme). Then, AES should update all > the windows created by this application (and maybe inform the > application about it). One important thing : when the theme changed, > the size of the work area shall stay unchanged. That is a very good point. > The FULL area may be > changed by the AES in order to keep the WORK area unchanged if the > widgets area bigger for example. > > Last point : saying that values returned by wind_calc() are only > relevant "in the moment if the window is not already opened" is not > acceptable. this function shall always returns relevant data for all > the windows (already opened or not) of the client. This is mandatory > to compute the FULL area of window before changing it. True, but you only need to call wind_calc after such a change. In stead of keeping poised on "already existing" windows I would suggest that wind_calc would get a version where you can specify both a widget mask and a theme identification. It can then be held independent of a given really existing window and would hold on to its original design constraints. To Odd: Hi Odd A version of wind_open that takes a work area rectangle as input might be an idee? -- Groeten; Regards. Henk Robbers. mailto:h.robbers@chello.nl http://members.ams.chello.nl/h.robbers/Home.html Interactive disassembler: TT-Digger; http://digger.atari.org A Home Cooked teXt editor: AHCX