On Wed, 24 May 2017 20:10:34 -0400 "William L. Thomson Jr." <[email protected]> said:
> On Thu, 25 May 2017 08:40:04 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > On Wed, 24 May 2017 17:33:36 -0400 "William L. Thomson Jr." > > <[email protected]> said: > > > > > Another requirement for pinentry is to grab keyboard and mouse. Mike > > > did this originally in his version. However its using ecore_x > > > specific code. Like the other ecore_x_init issue. > > > > also wayland doesn't even allow grabbing of the kbd or mouse. it's > > considered a highly unsocial thing to do to block a user out of > > everything else with their input elsewhere. > > I agree, but there is another side of the coin as well. Not security > related, and I have read past posts on such. No more clock debates :) > > I do not like this scenario. I see things the opposite as I will state. > Both are valid scenarios. As such pinentry can be configured both > ways, grab or no grab. Like a woman :) > > You have chat client running. You are typing in your passphrase or > some pin, etc. Some chat dialog pops up, grabs focus, and you are > typing in that now. Possibly showing characters you may want hidden. this actually is exactly what grabbing kbd would do for your pinentry. i'm busy chatting and suddenly my kkbd is stolen mid sentence by pinentry... generally this would be why it shouldn't be allowed. so here this would be the job of the compositor to do the following (assuming click to focus plus "every new window should get focus" which is the kind that windows and mac use by default) 1. track where keyboard input is going (which windows) 2. if a new dialog pops up and keyboard input is going to the "parent window" of that new dialog, then keyboard focus would switch. else if key input was recently going to an unrelated window, then don't switch focus to the new dialog and keep it where it is, assuming the user is busy "chatting to a friend and doesn't want to be disturbed". yes. it's a heuristic, but this i the right way. the compositor (that also handles all input) would know where you are typing at all times and be able to make these decisions. > My gripe is the opposite. I am typing in some window, with a script > running in another. That script invokes git commit, which causes > pinentry to pop up. It grabs my keyboard and now I am typing in the > wrong window. > > Though sometimes it pops up and I forget and it times out, that sucks! yup. and this is why wayland developers have in general agreed to not support such grabbing. the above is what the compositor should do - intelligently guess if your focus should or should not go somewhere *IF* that is your policy. of course "focus every new window" is a policy a compositor may allow to be changed (enlightenment does). > Its the same problem either way. I say do not have a chat or something > running that will pop up windows when you are typing in such. But > others would say the opposite. Its valid both ways. i get it. the point is the annoyance. you want to minimize such annoyance. disallowing grabs to even exist is a way of minimizing it (as now clients simply cant be "rude" and steal your keyboard). > > i don't see how it is a REQUIREMENT. such a password entry dialog can > > work just fine without any explicit grabbing of keyboard or mouse. > > the grabs sure are not a security mechanism as they do not guarantee > > input is not faked. so what is the actual REQUIREMENT (this thing > > can't function correctly without grabbing keyboard and mouse)? > > I know, and I tried to start a discussion on such. Oddly enough Mike > preferred the grab approach. That was in his version[1] of EFL pinentry > and not mine[2]. We even discussed it and differed. > > This was a request from gnupg devs and I mentioned I had brought such > up on list[3]. Which still has not had any discussion and I need to aaah. ok. so it's a request, not a requirement. that was the point. :) > bring up again. It seems only GTK is doing that. The QT versions, QT4/5 > do not grab keyboard or mouse. That was new to me when using the GTK > version. Which is what both Mike and I used as a basis and reference. > > I am going to make the argument that for now the EFL version > cannot/will not support grab until Wayland does. That way it will not > crash under either. If I can get it to run under Wayland, per the > issues in the other thread. i think this is sensible. imho this should not even be done by grabs but via other means like a property on a surface/window saying "hi - i'm a password dialog" and then enough other metadata (knowing which other window this window is for) so the compositor can make an intelligent decision based on focus policies and user input hiroty etc. > 1. https://github.com/Obsidian-StudiosInc/pinentry > 2. https://github.com/Obsidian-StudiosInc/pinentry/tree/zmike/efl > 3. https://lists.gnupg.org/pipermail/gnupg-devel/2017-April/032820.html > > -- > William L. Thomson Jr. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
