From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3186 invoked by alias); 16 Mar 2003 21:57:42 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 3144 invoked from network); 16 Mar 2003 21:57:41 -0000 Received: from unknown (HELO sunny.pacific.net.au) (203.2.228.40) by sources.redhat.com with SMTP; 16 Mar 2003 21:57:41 -0000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h2GLveOG000586 for ; Mon, 17 Mar 2003 08:57:40 +1100 (EST) Received: from localhost (ppp58.dyn228.pacific.net.au [203.143.228.58]) by wisma.pacific.net.au (8.12.8/8.12.8) with ESMTP id h2GLvcqn011688 for ; Mon, 17 Mar 2003 08:57:39 +1100 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 18ug8B-0000Wf-00; Mon, 17 Mar 2003 07:57:23 +1000 To: guile-gtk@sources.redhat.com Subject: Re: gdk-window-get-events returns all-events-mask From: Kevin Ryde Mail-Copies-To: never Date: Sun, 16 Mar 2003 21:57:00 -0000 In-Reply-To: (Daniel Skarda's message of "Sun, 16 Mar 2003 09:50:36 +0100") Message-ID: <877kazgeke.fsf@zip.com.au> User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i386-pc-linux-gnu) References: <87bs0s9hka.fsf@zip.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q1/txt/msg00018.txt.bz2 Daniel Skarda <0rfelyus@ucw.cz> writes: > > if ((val & info->literals[i].value) == info->literals [i].value) That should do the trick in practice, though I still think all-events-mask shouldn't be returned at all. > Fortunately it is not necessary (after the bugfix). all-events-mask == 0xffff > and the last event substructure-mask == 1 << 20, so equality in above "if" is > not going to be problem anymore. Actually, the absense of any event equal to "1 << 0" will ensure it doesn't occurs. But I think this is merely a bug in gtk, GDK_ALL_EVENTS_MASK in gtk 2.2.1 has been corrected to 0x3FFFE (there's a new 1<<21 bit added).