From mint-bounce@lists.fishpool.fi Mon Aug 9 04:52:42 2010 Message-ID: <521888.500169979-sendEmail@descaro> From: "Helmut Karlowski" To: "mint@lists.fishpool.fi" Cc: "helmut.karlowski@ish.de" Subject: Re: [MiNT] XaAES: menus in windows - window handle? Date: Mon, 9 Aug 2010 08:50:59 +0000 X-Mailer: sendEmail-1.55 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----MIME delimiter for sendEmail-196157.183338986" X-Antivirus: avast! (VPS 100808-1, 08.08.2010), Outbound message X-Antivirus-Status: Clean X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: helmut.karlowski@ish.de Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: This is a multi-part message in MIME format. To properly display this message you need a MIME-Version 1.0 compliant Email program. ------MIME delimiter for sendEmail-196157.183338986 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Johan Klockars wrote: > >> Just wait some time, when things have settled. Would you agree to do it the windows-way? > > > > Windows-way... which means clicking on a menu bar in the background tops the window? (I'm on OSX, can't really test the it my > > > > In such case - I think it should be optional. In my project, it could make sense to use e.g. edit->paste on a non-topped wind > > It's optional in Windows as well. At least none of my Windows machines > top a window based on clicking anything within the window itself (they > do top when the window border is clicked, though). Menus do get drawn > on top of everything else on the screen, though, even if they belong > to a window in the background (I suppose that makes sense, since it > would be kind of difficult to see the menu items sometimes otherwise). > This can look a bit strange if you use the keyboard to navigate the > background menu, though. ;-) > > Of course, this is not the standard behaviour under Windows, but I've > not run into a single application that misbehaves. > (I use a tiny (42 kbyte) utility called TXMouse to give X-like mouse > behaviour. That is, keyboard and mouse events go to the window > currently under the mouse cursor.) I just tested this with keyedit in the background: It works and I think it's pretty cool. So we definitely need both variants. The behaviour should be controlled by the client. I'd suggest: v1: pass window-handle not apid, don't top v2: top window, pass apid The client then would have to: Set mn_keystate == 0x7f00 -> v1, else v2. OR: use hi-byte of mode to control this. mode&0xf >> 8 == 1 -> v1, else v2. Drawback is that keyedit would get topped unless updated. -Helmut ------MIME delimiter for sendEmail-196157.183338986--