From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Deiconifying GTK frames on GNOME shell Date: Sat, 11 Sep 2021 10:38:12 +0200 Message-ID: References: <87e1a3cb-430d-ff6d-6244-6e20bbdced94@gmx.at> <635efeee-ffd5-28e3-d966-1086990b1aac@gmx.at> <366d9251-3609-9e0b-3d35-8af409af706a@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35102"; mail-complaints-to="usenet@ciao.gmane.io" To: Madhu , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 11 10:39:22 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOyXi-00091T-Kx for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Sep 2021 10:39:22 +0200 Original-Received: from localhost ([::1]:40024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mOyXh-0004bU-4g for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Sep 2021 04:39:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOyWo-0003jh-B4 for emacs-devel@gnu.org; Sat, 11 Sep 2021 04:38:26 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:35999) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mOyWm-0004lT-FC for emacs-devel@gnu.org; Sat, 11 Sep 2021 04:38:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631349494; bh=2KA2gVpmmmnx3ojhosePC+VWL1q8fSJGmLr6wa0aEq4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=EHfs+rmtJytRZvnxaLX7/4tuRIVnuCul2mjqQmxJohEUJv/5fkxo7iklvr6ZVES35 YhHjbNq65wZOT7H/fhcXapD1xZ9FRQU67DElSxqzAZoffgU8uEvJPG1oq0k0TS2xfg h6mN5/tx8IBiopR4xpnALGKTamn31hyKQrnvqBqs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.115]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MYvY2-1mTHx03BYW-00Uu5Q; Sat, 11 Sep 2021 10:38:14 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:+YBsGZ6RPLxBZtouHNV0V8WTAKK0Zvh4RSG+VQMpT/aCd7Xi8Vi AfuVFsG9VE/ft3Ie5tbZ9Kb/akHKIVD3UB8EI1HeM3HSdXQdmuloYu1jsmCj1TL4STY63gN IrNe5uNc0zpKMrEBTxxXxaTJb8wX1HzwfPM1WMLHEwcv+JvmBgwotBEiEQdwu7UbPkep8Qo 10e8Jztdm3rxhdvDU/m1Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:eo+dxAJC7Ko=:0j7n0nGfEymymoIt0vhl4L +mtfF4+BQ59ncJydxW5GNqO792x0TIgk+wwh6XIJako7KhySFtpO9Mkgg1mG5l+r6AjsV+PzA I29Mvru/gkPjnE8fcxfmx4ANybsBe+QhuKuAg9kxpnDg1N2vNJ7oAVYw2zsW090d0gr5z+KZ7 6rR2gnGFrV71O01t/j5D8GDblcbtIikGq8P3YB3RFW0NrlcGkuG6szWyVpxHg1EZQQ1C4AtM6 uzf1jYBW1Stsx3jLjgIT74b/C7aB56sR9iHtbgSQkKUeLRNhWhwCdLCmXIxU8+3tPyk+Rmk1U qYaHPMZMNTwFQP9ntK2gdzvtHvA5NIPaG/seCVvjPHxjDdkLsMU5xTYY4Hr/oGKSMoJzbKEMZ inNjArGfXNdsNl+Rqi97xDsVQgjWlHLwPyWdtXCHR4ygHnoOtNkL4wTTfSVPTDWhTYiJKXure S2gY5jDyFqB98ims1+/DGeNedQUrjc70BAA5gsX5tZLv4Yqm4J4HeBTFt1/qH2zdnnVRM7hD1 kV5imjGw+xg6pMEVnFMxu5LXMkJRYeNzykGae+urD9rI9HcSO8pLiC/nal+/UvAQtOxcH1bJe /mFvZLlRIpfmkxeBm1W6NmXpLXOsDoSvUmV9o7jUzKrgQd2s3FayLMiN0vjlgBopWgeEaJoPZ QYq1908DTdqeGlcjn90pOPLkyIk+kOegp9geQfPwoJA06TimWEH2XxX1MkffpScAMsIuat7Fu N0+wRmZ4GeNOJBkpssgw1fPlyyVoJC2iItD34TVf2WrrvKCVlT6T7imPfRGJ37BchrSl/Hn8 Received-SPF: pass client-ip=212.227.15.18; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274539 Archived-At: >>> [I thought I posted this workaround that I've been using at least since >> ... when? ... > > a year at least (i have it in my October 2020 backup) I wonder whether you had written it in response to some change in either Emacs or GNOME. > I've noticed the problem since march last year - the mutter-wayland folk > i chatted with at that time disclaimed any notion of "iconify", saying > hiding a window does not change the state Remarkable. We should and do get Expose events for such windows though. But we lack UnmapNotify and VisibilityNotify events for them. One major problem is that they seem to care about Wayland only now. Have you ever tried the pgtk branch and how it behaves in this regard? > and this is required for > live-previews when switching workspaces, etc. though they claimed full > support for ewmh NET_WM_STATE_HIDDEN And IIUC we have troubles with that as well. x_get_current_wm_state is not reliable in my experience (or maybe we don't call it often enough). > no, I couldn't figure out how to make raise-frame (select a different > frame and set input focus) work on mutter-wayland with gtkonly emacs. `raise-frame' calls Fmake_frame_visible. Are advices not working when called from C? Anyhow, you should try to do those advices in C in the first place - that's what I tried in the patch I sent to Dmitry and it works for `raise-frame' here (but causes havoc under xfwm). > gdk's calls do not work. In general? We do use them all the time. > I think that's being punted, and relief is expected from some > "xdg-activation protocol" Has that been implemented already? The pgtk branch should probably know about it first. > The mutter model means invisible frames are still supposed to keep > rendering - they just wont be composited on the main workspace. But how comes then that when users iconify a frame by clicking at the title bar icon or when they switch workspaces they get problems when deiconyfing a frame or switching workspace again. All that time Emacs should think of the frame as being exposed, visible, ... Is that x_get_current_wm_state striking again so Emacs _is_ somehow aware of the frame not being really visible and waits for a signal that the frame has become visible again? Basically we can adopt a model where Emacs thinks all the time that a frame is not visible and always asks to make it visible when it thinks that the frame should be visible. Just that `frame-list' could never tell in such a model what the visible and invisible frames are ... > [I try use it once in a while - try to get it to do what I want, > encounter problems, give up for a month, etc.] One evidence has become clear enough though: Our mutter clients don't use multiple frames. Thanks, martin