unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	"43672@debbugs.gnu.org" <43672@debbugs.gnu.org>
Subject: bug#43672: 28.0.50; select-frame-set-input-focus does not set focus first time called
Date: Sun, 18 Oct 2020 16:10:44 +0200	[thread overview]
Message-ID: <VI1PR06MB452610A27974623BD467AA5196010@VI1PR06MB4526.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <c806694a-d3b5-fe6a-c473-4953e204bfa4@gmx.at> (martin rudalics's message of "Sun, 18 Oct 2020 09:56:38 +0200")

martin rudalics <rudalics@gmx.at> writes:

>> sorry for being a bit late with this. I have tested and it was very
>> strange, so I realized I need more time to play with it.
>>
>> Here is how I got it:
>>
>> If I pass parent in the frame-params list to make-frame, then all is
>> grandy-dandy;
>
> Even without emacsclient?
No I tested emacsclient only; didn't have time to test more I had to go
to sleep :-) 
>> but if I don't then the behaviour is as following:
>>
>> If parent is set after creation; the frame will be reparented correctly
>> and appear at correct place on the screen, but it won't switch focus.
>
> But it eventually does get focus if you insist by executing
> 'select-frame-set-input-focus' twice.  Right?
Yes. I think I said that  previously; tested now and it works when
setting focus twice.

>> If parent is not set after the creation; the frame will switch focus,
>> buf it will of course appear somewhere at the screen (absolute
>> coordinates I guess).
>>
>> I have tested only emacsclient. I hope it helps.
>
> Earlier you said:
>
>   It works correctly in emacsclient; not correctly when I run Emacs as a
>   standalone process, either with -Q flag or without.
>
> So shouldn't you try with a standalone Emacs?
Yes I know; but now I get the behaviour as described in the previous
mail in client too.

I have just tested with emacs -Q too, and I get same behaviour, so at
least now it seems to behave same in both client and standalone process.

>> I have attached a simplified test file:
>
> If setting the parent in 'make-frame' works, then we can warn about
> reparenting later possibly causing problems with focus transfer.  But
> if
Personally I can live with this, it is not problem for me; I reported
mostly because I thought it was rather an odd behaviour. I understand
it's a picky thing to debug.
> But if
> the problematic behavior occurs when you want to pop up an (already
> existing but invisible) child menu frame on a different parent and give
> the menu focus, I have no idea what to do.  So does the latter work for
> you?
I haven't come to that part yet :-). I just started to write a small
eperiment, got into that one and reported, and haven't had time to go
back to my experiment.





  reply	other threads:[~2020-10-18 14:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 13:34 bug#43672: 28.0.50; select-frame-set-input-focus does not set focus first time called Arthur Miller
2020-09-28 13:57 ` Lars Ingebrigtsen
2020-09-28 14:11   ` Arthur Miller
2020-09-28 14:14     ` Lars Ingebrigtsen
2020-09-28 14:40       ` Arthur Miller
2020-09-29 13:46         ` Lars Ingebrigtsen
2020-09-29 14:34           ` martin rudalics
2020-09-29 14:44             ` Lars Ingebrigtsen
2020-09-29 20:43             ` Arthur Miller
2020-09-30  8:15               ` martin rudalics
2020-09-30  9:31                 ` Arthur Miller
2020-09-30 17:33                   ` martin rudalics
2020-09-30 17:36                     ` arthur miller
2020-10-01  8:39                       ` martin rudalics
2020-10-17 21:51                         ` Arthur Miller
2020-10-18  7:56                           ` martin rudalics
2020-10-18 14:10                             ` Arthur Miller [this message]
2020-10-20  7:20                               ` martin rudalics
2022-04-21 14:02                               ` Lars Ingebrigtsen
2020-09-28 17:59   ` martin rudalics
2020-09-28 17:59 ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR06MB452610A27974623BD467AA5196010@VI1PR06MB4526.eurprd06.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=43672@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).