From fnaumann@mail.cs.uni-magdeburg.de Thu Jun 24 15:43:54 2004 Message-ID: <40DAD865.1050002@seznam.cz> Date: Thu, 24 Jun 2004 15:34:29 +0200 From: Standa Opichal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] AES desktop extension References: <40DACB32.8070303@utbm.fr> In-Reply-To: <40DACB32.8070303@utbm.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at fishpool.fi Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel Hi! Olivier Landemarre wrote: >> BTW: another point against the userdef stuff: with most AESes (i >> don't know for XaAES), userdraw subroutines are not allowed to call >> AES functions (AES is not re-entrant). That may lead the system to >> crash. Yeah, yet another important problem. > It's true for old AES only in monotos, it work perfectly under Magic, > MyAeS and I think under NAES, XaAES and perhaps Geneva. The only > restriction can comme with supervisor stack size. Well, this proves that it is not possible to write an application to work on all these... >> I'd prefer the following: >> >> wind_open(0,dummy,dummy,dummy,dummy); >> >> This will ask the AES to send WM_REDRAW message to window handle 0 >> instead of drawing the desktop formular. Once, or from the time of that call? >> The window dimensions >> (dummy) shall not be taken into account by the AES. That window shall >> not be topped when a mouse event occurs on it (WF_BEVENT/BEVENT_WORK >> feature)) Yeah. >> wind_close(0); or wind_set(WF_NEWDESK); shall remove that desktop-window. Remove, or set the behaviour it the AES supports now? If the answers to the last two questions are 'the latter' then I agree with you completely Arnaud. Your proposal is better because it does not define any new AES API entity (no #define...) and is quite consistent with the other usage I must say. >> Note that there are no wind_create()/wind_delete() call for that >> particular window. Sure. It is a matter of the AES itself. >> Last point: other wind_xxx() functions shall be ready to manage the >> case 'window_handle == 0' (i think it's already ok). Yes, they are already working properly IIRC. > I have not understand exactly what you wan't to do with desktop, if you > wan't send a redraw for the desktop, I think you not need anything at > all, just wind_get WF_FIRSTXYWH and WF_NEXTXYWH on window 0 and then do > a form_dial( FMD_FINISH) on parts get with wind_get() I think it work > (to test) It is not a problem to send the 'desktop redraw', but rather handle the redraw action by the desktop application. Now it is different than the other window handling which is the thing we are trying to change. regards STan