Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-11 Thread Florian Schaefer 
On 11.05.18 15:59, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 11 May 2018 08:43:06 +0900 Florian Schaefer  said:
> 
>> On 10.05.18 12:04, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer 
>>> said:
>>>
 Hi everyone,

 sorry for jumping into the discussion so suddenly. :-)

 On 10.05.18 01:12, Carsten Haitzler wrote:
 [...]
>> Ok, so basically you are confirming that 
>> https://photos.app.goo.gl/GFht7beUYWbobxpP6
>> is a bug in 0.21.11 and that 
>
> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> - ..." ... the pointer should/would focus the window it is over, even if
> that window is partly obscured by something on top.
>
>> 1) I'm the first one to see it, maybe because no one is using that
>> release with focus follow mouse?
>>
>> 2) it's not going to get fixed because 0.21.x is a dead branch
>
> correct. the answer is "use 0.22". we don't have the manpower to support
> multiple stable branches going back in time. we maintain one (the last
> release stable branch). :(
 [...]

 I'd just like to confirm that I observe a similar behavior here since
 some weeks perhaps. I'm currently using efl and e 0.22 recompiled from
 GIT on April 22nd.

 Basically I see the same behavior. Interestingly only Firefox (version
 56 in my case) seems to steal the focus from the top windows. And also
 only with some applications (e.g. FoxitReader) on top and not strictly
 always reproducible. Still, this is really unnerving as I tend to close
 my windows using keyboard shortcuts mostly and I always end up closing
 the Firefox beneath instead of the intended application...
>>>
>>> does it still do it on git master?
>>
>> Yes.
>>
>> I just recompiled (just to be sure) EFL and enlightenment from GIT
>> (master). Behaviour is unchanged: Firefox steals focus from FoxitReader
>> window. In that situation the FoxitReader is displayed on top of Firefox
>> and the cursor is residing within the Foxit window. My focus settings
>> are "sloppy" and "Ignore hint". Interestingly, Foxit regains focus for a
>> split second when my mouse curser changed from the main window area to
>> the title bar.
> 
> hmmm does focus get stolen on click to focus? can you examine to see precisely
> what areas the mouse has to go over for this to happen and see if there is a
> pattern that matches something else on screen (visible or maybe obscured).
> 
> i also am not sure if this also has to do with focus model or clients
> interacting with focus by setting focus too... trying to at least narrow it
> down to "clients involved or not" or is it simply something geometrical?

OK, I did some more tests and something like a pattern emerged. It's a
bit complicated perhaps but bear with me, I try to break it down.

My setup: Notebook with additional external monitor configured to extend
my desktop below the notebook screen.

I have Firefox running on my notebook screen.

Now I create another window on the external monitor, let's say leafpad.

I move leafpad up (remember the monitor is sitting below the notebook
screen) to cover the firefox window only partially. A part of leafpad is
still visible on the external screen. In that case if I move my mouse
cursor first to firefox and then from firefox into the leafpad window,
firefox steals the focus. Everywhere on the leafpad window. Only the
moment I pass a border to the leafpad windows' decorations (title bar or
other borders) I get the focus back for a split second. It then goes
right back to firefox. This also happens if I try to not move the mouse
away from the pixel where I recovered focus.

This was when entering leafpad from the firefox window. If I enter the
leafpad window directly form the desktop backgroudn without going
through firefox first, the focus is not stolen.

Also, the moment no part of leafpad is on the external screen but
completely on the notebook screen, the focus behaves as expected.

Further, this only happens with "Pointer" and "Sloppy" focus. With
"Click" focus no problems in all scenarios.

For know I observed this whole stuff only with a firefox window below.
It seems to be independent of the content firefox is displaying at that
moment.

I hope this is somehow understandable and helps. :-)

Cheers,
Florian

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11 [solved, kinda]

2018-05-11 Thread Carsten Haitzler 
On Thu, 10 May 2018 13:18:03 -0700 Marc MERLIN  said:

> On Thu, May 10, 2018 at 12:00:13PM +0900, Carsten Haitzler wrote:
> > when mouse enters or exits the window (events from the xserver). that is
> > how e decides to focus it or not.
>  
> Right, that's how it normally works.
> If you look at my video again you'll see focus is lost without me
> leaving the window I was in, just because I enter a region occupied by
> the window underneath (not visible), and that window is a special one
> (there is a hierachy where chrome steals from gnome-terminal, and the
> arduino gui also steals from gnome-terminal, but not the other way
> around.

yeah. it was hard to tell that. i saw the more general one as i described and
thought it was that. :)

> > > In what I'm seeing, some windows have higher priority and steal input even
> > > if they're below the window on top that I'm trying to write in.
> > 
> > either mouse is entering and exiting... or an app is explicitly setting or
> > stealing the focus. apps can do this. the enter/exit may be happening due to
> > "fake invisible" windows/rectangles being used to cover areas not covered by
> > windows to direct input to the one big canvas that is the screen for e's
> > compositor. there may have been a bug in it that messed up these rects OR
> > perhaps there were stray "0 0 0 0" rectangles (transparent rects but
> > visible to input, so color rgba is 0 0 0 0). if it was this then the bug
> > has since been fixed in 0.22 for sure.
> 
> Can't say, but this never ever happened to me with any E version before,
> including older ones.

it could also be that the evas object stacking is not perfectly mirroring the
window stacking (or vice-versa) thus the visual stacking is different in the
canvas to the stacking in the x window tree. i don't know... :(

> So, I thought going back to 0.21.5 would fix it, but it did not.
> I then did more digging and I found it's an unrelated problem where if
> you play with window stacking, things break and stay broken.

you might find it easiest to check out the stable branch (enlightenment-0.21)
and the git bisect your way there as it'll do it in log n steps :) you will
also find the exact commit that did it too...

> You've already seen my video, what you didn't see is that all my
> gnome-terminal windows have a stacking of none. I didn't ask for this, I
> have no idea how you get into that state.
> If I go to window stacking, nothing is checked.

i have no idea how that could happen... i certainly don't see that where - but i
don't use gnome-terminal ... but my terminology terminals don't seem to have
this...

this might be where the window layer value has gone totally out of scope/range?
maybe? but how? it's not something i can find out without reproducing and
adding lots of debug printfs to trace down where the stacking changes and how...

> To fix my problem, selecting window stacking normal to get the radio box
> is not enough.
> I need to do window stacking, on top. Then focus stays on my window that
> was already on top anyway.
> Then, I can reset it to stacking normal.
> After that input works ok and doesn't get stolen by the window
> underneath.

that doesn't help - need to know what the stacking layer value is internally and
how it got to there...

i need a reproduction case. gnome-terminal won't do as gnome-terminal is broken
for me. it just sleeps doing nothing for like 30 sec and never shows any
window. and exits with:

# Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0:
# Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

*shrug*. broken. :(

> I need to do this for every single gnome-terminal I have, one by one,
> all 24 of them, and hope the settings get saved.
> This is an E bug, is it not?

this probably is, but i don't see it day to day on any of my windows i can
find... and it may be a symptom of stacking issues where stack in canvas doesn't
match stack in x ... and that may have been cleared up by now in layer e's or
improved to have fewer holes.

> How or in which version the bug was created, I have no idea. I only
> managed to find a way out of it, not what I did to create it.

well to really get into it i'd need to reproduce on a current git master e so i
can work on something with the current state of play and then find any holes or
problems there. going back in time 1, 2, 3 etc. years is not very productive.

...

but as an aside this whole conversation got me to heavily suspend and resume
test on my laptop yesterday and today... and i have yet to have e hang. i have
opened and closed that lid so many times ... like at least 100 in the past day.
i did find some interesting things though.

1. kernel resume seems sluggish. or more specifically it does its resume work
then tries to get userspace started, it allows tasks to run again and then it
still takes about 2 seconds before any userspace process runs. i set a timer to
poll every 0.1

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-11 Thread The Rasterman 
On Fri, 11 May 2018 08:43:06 +0900 Florian Schaefer  said:

> On 10.05.18 12:04, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer 
> > said:
> > 
> >> Hi everyone,
> >>
> >> sorry for jumping into the discussion so suddenly. :-)
> >>
> >> On 10.05.18 01:12, Carsten Haitzler wrote:
> >> [...]
>  Ok, so basically you are confirming that 
>  https://photos.app.goo.gl/GFht7beUYWbobxpP6
>  is a bug in 0.21.11 and that 
> >>>
> >>> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> >>> - ..." ... the pointer should/would focus the window it is over, even if
> >>> that window is partly obscured by something on top.
> >>>
>  1) I'm the first one to see it, maybe because no one is using that
>  release with focus follow mouse?
> 
>  2) it's not going to get fixed because 0.21.x is a dead branch
> >>>
> >>> correct. the answer is "use 0.22". we don't have the manpower to support
> >>> multiple stable branches going back in time. we maintain one (the last
> >>> release stable branch). :(
> >> [...]
> >>
> >> I'd just like to confirm that I observe a similar behavior here since
> >> some weeks perhaps. I'm currently using efl and e 0.22 recompiled from
> >> GIT on April 22nd.
> >>
> >> Basically I see the same behavior. Interestingly only Firefox (version
> >> 56 in my case) seems to steal the focus from the top windows. And also
> >> only with some applications (e.g. FoxitReader) on top and not strictly
> >> always reproducible. Still, this is really unnerving as I tend to close
> >> my windows using keyboard shortcuts mostly and I always end up closing
> >> the Firefox beneath instead of the intended application...
> > 
> > does it still do it on git master?
> 
> Yes.
> 
> I just recompiled (just to be sure) EFL and enlightenment from GIT
> (master). Behaviour is unchanged: Firefox steals focus from FoxitReader
> window. In that situation the FoxitReader is displayed on top of Firefox
> and the cursor is residing within the Foxit window. My focus settings
> are "sloppy" and "Ignore hint". Interestingly, Foxit regains focus for a
> split second when my mouse curser changed from the main window area to
> the title bar.

hmmm does focus get stolen on click to focus? can you examine to see precisely
what areas the mouse has to go over for this to happen and see if there is a
pattern that matches something else on screen (visible or maybe obscured).

i also am not sure if this also has to do with focus model or clients
interacting with focus by setting focus too... trying to at least narrow it
down to "clients involved or not" or is it simply something geometrical?



-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-10 Thread Florian Schaefer 
On 10.05.18 12:04, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer  said:
> 
>> Hi everyone,
>>
>> sorry for jumping into the discussion so suddenly. :-)
>>
>> On 10.05.18 01:12, Carsten Haitzler wrote:
>> [...]
 Ok, so basically you are confirming that 
 https://photos.app.goo.gl/GFht7beUYWbobxpP6
 is a bug in 0.21.11 and that 
>>>
>>> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
>>> - ..." ... the pointer should/would focus the window it is over, even if
>>> that window is partly obscured by something on top.
>>>
 1) I'm the first one to see it, maybe because no one is using that
 release with focus follow mouse?

 2) it's not going to get fixed because 0.21.x is a dead branch
>>>
>>> correct. the answer is "use 0.22". we don't have the manpower to support
>>> multiple stable branches going back in time. we maintain one (the last
>>> release stable branch). :(
>> [...]
>>
>> I'd just like to confirm that I observe a similar behavior here since
>> some weeks perhaps. I'm currently using efl and e 0.22 recompiled from
>> GIT on April 22nd.
>>
>> Basically I see the same behavior. Interestingly only Firefox (version
>> 56 in my case) seems to steal the focus from the top windows. And also
>> only with some applications (e.g. FoxitReader) on top and not strictly
>> always reproducible. Still, this is really unnerving as I tend to close
>> my windows using keyboard shortcuts mostly and I always end up closing
>> the Firefox beneath instead of the intended application...
> 
> does it still do it on git master?

Yes.

I just recompiled (just to be sure) EFL and enlightenment from GIT
(master). Behaviour is unchanged: Firefox steals focus from FoxitReader
window. In that situation the FoxitReader is displayed on top of Firefox
and the cursor is residing within the Foxit window. My focus settings
are "sloppy" and "Ignore hint". Interestingly, Foxit regains focus for a
split second when my mouse curser changed from the main window area to
the title bar.

Cheers,
Florian

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11 [solved, kinda]

2018-05-10 Thread Marc MERLIN 
On Thu, May 10, 2018 at 12:00:13PM +0900, Carsten Haitzler wrote:
> when mouse enters or exits the window (events from the xserver). that is how e
> decides to focus it or not.
 
Right, that's how it normally works.
If you look at my video again you'll see focus is lost without me
leaving the window I was in, just because I enter a region occupied by
the window underneath (not visible), and that window is a special one
(there is a hierachy where chrome steals from gnome-terminal, and the
arduino gui also steals from gnome-terminal, but not the other way
around.

> > In what I'm seeing, some windows have higher priority and steal input even
> > if they're below the window on top that I'm trying to write in.
> 
> either mouse is entering and exiting... or an app is explicitly setting or
> stealing the focus. apps can do this. the enter/exit may be happening due to
> "fake invisible" windows/rectangles being used to cover areas not covered by
> windows to direct input to the one big canvas that is the screen for e's
> compositor. there may have been a bug in it that messed up these rects OR
> perhaps there were stray "0 0 0 0" rectangles (transparent rects but visible 
> to
> input, so color rgba is 0 0 0 0). if it was this then the bug has since been
> fixed in 0.22 for sure.

Can't say, but this never ever happened to me with any E version before,
including older ones.

So, I thought going back to 0.21.5 would fix it, but it did not.
I then did more digging and I found it's an unrelated problem where if
you play with window stacking, things break and stay broken.

You've already seen my video, what you didn't see is that all my
gnome-terminal windows have a stacking of none. I didn't ask for this, I
have no idea how you get into that state.

If I go to window stacking, nothing is checked.
To fix my problem, selecting window stacking normal to get the radio box
is not enough.
I need to do window stacking, on top. Then focus stays on my window that
was already on top anyway.
Then, I can reset it to stacking normal.
After that input works ok and doesn't get stolen by the window
underneath.

I need to do this for every single gnome-terminal I have, one by one,
all 24 of them, and hope the settings get saved.
This is an E bug, is it not?

How or in which version the bug was created, I have no idea. I only
managed to find a way out of it, not what I did to create it.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-10 Thread Marc MERLIN 
On Thu, May 10, 2018 at 12:00:13PM +0900, Carsten Haitzler wrote:
> when mouse enters or exits the window (events from the xserver). that is how e
> decides to focus it or not.
 
Right, that's how it normally works.
If you look at my video again you'll see focus is lost without me
leaving the window I was in, just because I enter a region occupied by
the window underneath (not visible), and that window is a special one
(there is a hierachy where chrome steals from gnome-terminal, and the
arduino gui also steals from gnome-terminal, but not the other way
around.

> > In what I'm seeing, some windows have higher priority and steal input even
> > if they're below the window on top that I'm trying to write in.
> 
> either mouse is entering and exiting... or an app is explicitly setting or
> stealing the focus. apps can do this. the enter/exit may be happening due to
> "fake invisible" windows/rectangles being used to cover areas not covered by
> windows to direct input to the one big canvas that is the screen for e's
> compositor. there may have been a bug in it that messed up these rects OR
> perhaps there were stray "0 0 0 0" rectangles (transparent rects but visible 
> to
> input, so color rgba is 0 0 0 0). if it was this then the bug has since been
> fixed in 0.22 for sure.

Can't say, but this never ever happened to me with any E version before,
including older ones.

I have to spend some time downgrading/upgrading versions to confirm it's
not in 0.21.5, and then find where it breaks.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-10 Thread Marc MERLIN 
On Thu, May 10, 2018 at 09:50:50AM -0700, Ross Vandegrift wrote:
> On Tue, May 08, 2018 at 05:59:18PM -0700, Marc MERLIN wrote:
> > Ah yeah, I forgot this relevant info:
> > ii  libdrm-intel1:amd64 2.4.91-2   
> > ii  xorg1:7.7+19   
> > ii  xserver-xorg-video-intel2:2.99.917+git20171229-1
> 
> I don't have anything to add on the focus issue.  But unless you've
> manually taken steps to use the intel driver, you are probably using the
> modesetting driver instead.  So before spending time troubleshooting
> intel, check the Xorg logs to make sure you know which you are using.

Oooh, good point, I forgot about that.

[537263.054] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[537263.057] (II) Module glamoregl: vendor="X.Org Foundation"
[537263.057]compiled for 1.19.6, module version = 1.0.0
[537263.057]ABI class: X.Org ANSI C Emulation, version 0.4
[537263.057] (II) glamor: OpenGL accelerated X.org driver based.
[537263.065] (II) glamor: EGL version 1.4 (DRI2):
[537263.068] (II) modeset(0): glamor initialized
[537263.069] (II) modeset(0): Output eDP-1 has no monitor section
[537263.070] (II) modeset(0): EDID for output eDP-1
(...)
[537263.071] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[537263.071] (==) modeset(0): DPI set to (96, 96)
[537263.071] (II) Loading sub module "fb"
[537263.071] (II) LoadModule: "fb"
[537263.071] (II) Loading /usr/lib/xorg/modules/libfb.so
[537263.071] (II) Module fb: vendor="X.Org Foundation"
[537263.071]compiled for 1.19.6, module version = 1.0.0
[537263.071]ABI class: X.Org ANSI C Emulation, version 0.4
[537263.071] (II) UnloadModule: "fbdev"
[537263.071] (II) Unloading fbdev
[537263.071] (II) UnloadSubModule: "fbdevhw"
[537263.071] (II) Unloading fbdevhw
[537263.071] (II) UnloadModule: "vesa"
[537263.071] (II) Unloading vesa
[537263.071] (==) Depth 24 pixmap format is 32 bpp
[537263.134] (==) modeset(0): Backing store enabled
[537263.134] (==) modeset(0): Silken mouse enabled
[537263.134] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR 
disabled message.
[537263.187] (==) modeset(0): DPMS enabled
[537263.188] (II) modeset(0): [DRI2] Setup complete
[537263.188] (II) modeset(0): [DRI2]   DRI driver: i965
[537263.188] (II) modeset(0): [DRI2]   VDPAU driver: i965

Kernel 4.15.6.

glxinfo
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)  (0x191b)
Version: 13.0.6
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 4.50

I'm not finding any obvious errors in my Xorg.log, but I suppose I could
build a newer kernel.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-10 Thread Ross Vandegrift 
On Tue, May 08, 2018 at 05:59:18PM -0700, Marc MERLIN wrote:
> Ah yeah, I forgot this relevant info:
> ii  libdrm-intel1:amd64 2.4.91-2   
> ii  xorg1:7.7+19   
> ii  xserver-xorg-video-intel2:2.99.917+git20171229-1

I don't have anything to add on the focus issue.  But unless you've
manually taken steps to use the intel driver, you are probably using the
modesetting driver instead.  So before spending time troubleshooting
intel, check the Xorg logs to make sure you know which you are using.

Ross

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread The Rasterman 
On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer  said:

> Hi everyone,
> 
> sorry for jumping into the discussion so suddenly. :-)
> 
> On 10.05.18 01:12, Carsten Haitzler wrote:
> [...]
> >> Ok, so basically you are confirming that 
> >> https://photos.app.goo.gl/GFht7beUYWbobxpP6
> >> is a bug in 0.21.11 and that 
> > 
> > oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> > - ..." ... the pointer should/would focus the window it is over, even if
> > that window is partly obscured by something on top.
> > 
> >> 1) I'm the first one to see it, maybe because no one is using that
> >> release with focus follow mouse?
> >>
> >> 2) it's not going to get fixed because 0.21.x is a dead branch
> > 
> > correct. the answer is "use 0.22". we don't have the manpower to support
> > multiple stable branches going back in time. we maintain one (the last
> > release stable branch). :(
> [...]
> 
> I'd just like to confirm that I observe a similar behavior here since
> some weeks perhaps. I'm currently using efl and e 0.22 recompiled from
> GIT on April 22nd.
> 
> Basically I see the same behavior. Interestingly only Firefox (version
> 56 in my case) seems to steal the focus from the top windows. And also
> only with some applications (e.g. FoxitReader) on top and not strictly
> always reproducible. Still, this is really unnerving as I tend to close
> my windows using keyboard shortcuts mostly and I always end up closing
> the Firefox beneath instead of the intended application...

does it still do it on git master?

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Carsten Haitzler 
On Wed, 9 May 2018 09:29:56 -0700 Marc MERLIN  said:

> On Thu, May 10, 2018 at 01:12:10AM +0900, Carsten Haitzler wrote:
> > > Ok, so basically you are confirming that 
> > > https://photos.app.goo.gl/GFht7beUYWbobxpP6
> > > is a bug in 0.21.11 and that 
> > 
> > oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> > - ..." ... the pointer should/would focus the window it is over, even if
> > that window is partly obscured by something on top.
>  
> Thanks for confirming, as well as the other questions.

i saw the other bits at first with terminal focusing while it was still behind
the main browser window on top and thought that is what you were complaining
about. it was this above instead. got it now.

> > you shouldn't. e is like your favorite browser there - chrome. you cant' use
> > configs too new for the browser (i've hit it before thanks to rsync :))
> > configs are one way upgrades. you could manually downgrade configs. it's
> > possible with some time and effort using the eet tool. but older code
> > doesn't know how to downgrade config from some e version in the future it
> > knows nothing about.
>  
> Thanks for confirming. So basically any downgrade, even a .1 downgrade,
> .e will detect it and delete the entire profile. Correct?

no. e shouldnt change config versions within micro versions as it wouldn't be
upgrading config... normally. BUT it may be that a bug fix required a version
upgrade. it is in theory possible. i don't know if this was actually done in
real life during 0.21.xxx ... you'd have to check the commits to the stable
branch to see if any bumped cfg version.

> > > 5) if my profile is going to get lost, can I at least somehow backup all
> > > my saved window settings, which literally take me 30 to 45mn to
> > > painstakenly recreate one by one?
> > 
> > yes. eet. tool. you can decode/ecode config from the files to text files,
> > edit them, splice them together then encode/insert them again.
> 
> I'll see which one is less pain/time lost, thanks.
> But first I have to find which 0.21 does not have that bug, given that
> 0.22 is mostly unusable for me (details in upcoming message).
> 
> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/   | PGP
> 7F55D5F27AAF9D08
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread The Rasterman 
On Wed, 9 May 2018 17:05:03 -0700 Marc MERLIN  said:

> On Thu, May 10, 2018 at 09:32:03AM +0930, Simon Lees wrote:
> > 
> > 
> > On 09/05/18 23:50, Marc MERLIN wrote:
> > > On Wed, May 09, 2018 at 11:16:52AM +0200, Jérémy Zurcher wrote:
> > >> Hello Marc,
> > >>
> > >> I don't like that default behaviour either.
> > >> but it's very easy to disable :
> > >>   Settings -> Windows -> window focus -> Click window to focus
> > > 
> > > Yeah, thanks for that workaround, I could do this if I had to.
> > > 
> > > However, sorry if I'm being dense here:
> > > I've had focus follow mouse for literally 20 years.
> > > I've never had my mouse pointer focus a window underneath the window I'm
> > > pointing on.
> > > I sure don't want that, and E has never ever done this, until now with
> > > 0.22.11.
> > 
> > I used to do that all the time, with semi transparent terminal windows
> > that over lapped or other cases where I was re writing in text I went
> > back to click to focus years ago though.
> 
> If you use focus follow mouse, how does it or you get to decide if input
> goes to the window on top or below?
> With click to focus, sure, but without, how can E know that you want to type
> under the current window?
> 

when mouse enters or exits the window (events from the xserver). that is how e
decides to focus it or not.

> In what I'm seeing, some windows have higher priority and steal input even
> if they're below the window on top that I'm trying to write in.

either mouse is entering and exiting... or an app is explicitly setting or
stealing the focus. apps can do this. the enter/exit may be happening due to
"fake invisible" windows/rectangles being used to cover areas not covered by
windows to direct input to the one big canvas that is the screen for e's
compositor. there may have been a bug in it that messed up these rects OR
perhaps there were stray "0 0 0 0" rectangles (transparent rects but visible to
input, so color rgba is 0 0 0 0). if it was this then the bug has since been
fixed in 0.22 for sure.

> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/  
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Florian Schaefer 
Hi everyone,

sorry for jumping into the discussion so suddenly. :-)

On 10.05.18 01:12, Carsten Haitzler wrote:
[...]
>> Ok, so basically you are confirming that 
>> https://photos.app.goo.gl/GFht7beUYWbobxpP6
>> is a bug in 0.21.11 and that 
> 
> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> - ..." ... the pointer should/would focus the window it is over, even if that
> window is partly obscured by something on top.
> 
>> 1) I'm the first one to see it, maybe because no one is using that
>> release with focus follow mouse?
>>
>> 2) it's not going to get fixed because 0.21.x is a dead branch
> 
> correct. the answer is "use 0.22". we don't have the manpower to support
> multiple stable branches going back in time. we maintain one (the last release
> stable branch). :(
[...]

I'd just like to confirm that I observe a similar behavior here since
some weeks perhaps. I'm currently using efl and e 0.22 recompiled from
GIT on April 22nd.

Basically I see the same behavior. Interestingly only Firefox (version
56 in my case) seems to steal the focus from the top windows. And also
only with some applications (e.g. FoxitReader) on top and not strictly
always reproducible. Still, this is really unnerving as I tend to close
my windows using keyboard shortcuts mostly and I always end up closing
the Firefox beneath instead of the intended application...

Cheers,
Florian

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Marc MERLIN 
On Thu, May 10, 2018 at 09:32:03AM +0930, Simon Lees wrote:
> 
> 
> On 09/05/18 23:50, Marc MERLIN wrote:
> > On Wed, May 09, 2018 at 11:16:52AM +0200, Jérémy Zurcher wrote:
> >> Hello Marc,
> >>
> >> I don't like that default behaviour either.
> >> but it's very easy to disable :
> >>   Settings -> Windows -> window focus -> Click window to focus
> > 
> > Yeah, thanks for that workaround, I could do this if I had to.
> > 
> > However, sorry if I'm being dense here:
> > I've had focus follow mouse for literally 20 years.
> > I've never had my mouse pointer focus a window underneath the window I'm
> > pointing on.
> > I sure don't want that, and E has never ever done this, until now with
> > 0.22.11.
> 
> I used to do that all the time, with semi transparent terminal windows
> that over lapped or other cases where I was re writing in text I went
> back to click to focus years ago though.

If you use focus follow mouse, how does it or you get to decide if input
goes to the window on top or below?
With click to focus, sure, but without, how can E know that you want to type
under the current window?

In what I'm seeing, some windows have higher priority and steal input even
if they're below the window on top that I'm trying to write in.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Simon Lees 


On 09/05/18 23:50, Marc MERLIN wrote:
> On Wed, May 09, 2018 at 11:16:52AM +0200, Jérémy Zurcher wrote:
>> Hello Marc,
>>
>> I don't like that default behaviour either.
>> but it's very easy to disable :
>>   Settings -> Windows -> window focus -> Click window to focus
> 
> Yeah, thanks for that workaround, I could do this if I had to.
> 
> However, sorry if I'm being dense here:
> I've had focus follow mouse for literally 20 years.
> I've never had my mouse pointer focus a window underneath the window I'm
> pointing on.
> I sure don't want that, and E has never ever done this, until now with
> 0.22.11.

I used to do that all the time, with semi transparent terminal windows
that over lapped or other cases where I was re writing in text I went
back to click to focus years ago though.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Marc MERLIN 
On Thu, May 10, 2018 at 01:12:10AM +0900, Carsten Haitzler wrote:
> > Ok, so basically you are confirming that 
> > https://photos.app.goo.gl/GFht7beUYWbobxpP6
> > is a bug in 0.21.11 and that 
> 
> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
> - ..." ... the pointer should/would focus the window it is over, even if that
> window is partly obscured by something on top.
 
Thanks for confirming, as well as the other questions.

> you shouldn't. e is like your favorite browser there - chrome. you cant' use
> configs too new for the browser (i've hit it before thanks to rsync :)) 
> configs
> are one way upgrades. you could manually downgrade configs. it's possible with
> some time and effort using the eet tool. but older code doesn't know how to
> downgrade config from some e version in the future it knows nothing about.
 
Thanks for confirming. So basically any downgrade, even a .1 downgrade,
.e will detect it and delete the entire profile. Correct?

> > 5) if my profile is going to get lost, can I at least somehow backup all
> > my saved window settings, which literally take me 30 to 45mn to
> > painstakenly recreate one by one?
> 
> yes. eet. tool. you can decode/ecode config from the files to text files, edit
> them, splice them together then encode/insert them again.

I'll see which one is less pain/time lost, thanks.
But first I have to find which 0.21 does not have that bug, given that
0.22 is mostly unusable for me (details in upcoming message).

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Carsten Haitzler 
On Wed, 9 May 2018 07:57:56 -0700 Marc MERLIN  said:

> On Wed, May 09, 2018 at 11:31:30PM +0900, Carsten Haitzler wrote:
> > > I don't want this either.
> > > I want the window under to stay under and not exist as far as focus and
> > > input are concerned, the way E has behaved for me for literally 20 years
> > > now.
> > 
> > e never behaved that way. if you have pointer focus the window the pointer
> > was over would get focused. always. you could have it autoraise or not, but
> > you're imagining things because i never wrote any such feature like this.
> > no wm i have ever seen does this either. :)
> 
> Ok, so basically you are confirming that 
> https://photos.app.goo.gl/GFht7beUYWbobxpP6
> is a bug in 0.21.11 and that 

oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps
- ..." ... the pointer should/would focus the window it is over, even if that
window is partly obscured by something on top.

> 1) I'm the first one to see it, maybe because no one is using that
> release with focus follow mouse?
> 
> 2) it's not going to get fixed because 0.21.x is a dead branch

correct. the answer is "use 0.22". we don't have the manpower to support
multiple stable branches going back in time. we maintain one (the last release
stable branch). :(

> 3) Is it a known bug that got fixed in 0.22 or we don't even know what the
> bug was and how it got fixed/went away?

i never saw it. you may be unlucky and happen to have a situation that brings it
out, but as part of wayland work there has been also work with event areas etc.
and something for wayland may have broken this etc. but it has since been
fixed... in 0.22 :)

> Related questions:
> 4) if I start building 0.21.10, .9, .8 until the introduced
> bug goes away, am I going to lose my ~/.e profile and all my settings
> every time, or is it at least backwards compatible if I stay within
> 0.21?

you shouldn't. e is like your favorite browser there - chrome. you cant' use
configs too new for the browser (i've hit it before thanks to rsync :)) configs
are one way upgrades. you could manually downgrade configs. it's possible with
some time and effort using the eet tool. but older code doesn't know how to
downgrade config from some e version in the future it knows nothing about.

> 5) if my profile is going to get lost, can I at least somehow backup all
> my saved window settings, which literally take me 30 to 45mn to
> painstakenly recreate one by one?

yes. eet. tool. you can decode/ecode config from the files to text files, edit
them, splice them together then encode/insert them again.

> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/   | PGP
> 7F55D5F27AAF9D08
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Marc MERLIN 
On Wed, May 09, 2018 at 11:31:30PM +0900, Carsten Haitzler wrote:
> > I don't want this either.
> > I want the window under to stay under and not exist as far as focus and
> > input are concerned, the way E has behaved for me for literally 20 years
> > now.
> 
> e never behaved that way. if you have pointer focus the window the pointer was
> over would get focused. always. you could have it autoraise or not, but you're
> imagining things because i never wrote any such feature like this. no wm i 
> have
> ever seen does this either. :)

Ok, so basically you are confirming that 
https://photos.app.goo.gl/GFht7beUYWbobxpP6
is a bug in 0.21.11 and that 

1) I'm the first one to see it, maybe because no one is using that
release with focus follow mouse?

2) it's not going to get fixed because 0.21.x is a dead branch

3) Is it a known bug that got fixed in 0.22 or we don't even know what the
bug was and how it got fixed/went away?

Related questions:
4) if I start building 0.21.10, .9, .8 until the introduced
bug goes away, am I going to lose my ~/.e profile and all my settings
every time, or is it at least backwards compatible if I stay within
0.21?

5) if my profile is going to get lost, can I at least somehow backup all
my saved window settings, which literally take me 30 to 45mn to
painstakenly recreate one by one?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Carsten Haitzler 
On Tue, 8 May 2018 20:02:35 -0700 Marc MERLIN  said:

> Hi Raster, thanks for the answers.
> 
> On Wed, May 09, 2018 at 11:12:33AM +0900, Carsten Haitzler wrote:
> > yes. pointer focus will focus windows under others. as per video. that is
> > intended. i use it all the time. i like it. mostly windows under others are
> > only minimally obscured. if i dont want it behind it alt+click to raise to
> > the front.
>  
> Oh my, that's a big change. I really don't want this.
> I don't want the behaviour at all. How do I get a window under my active
> window to never take pointer focus?

don't use pointer focus? use click to focus?

> > if you want it to RAISE there is another feature called autoraise. enable
> > that. then it'll focus and raise... use them together if that is what you
> > prefer. autoraise also can work with click to focus. :) "Raise windows on
> > mouse over"" is the checkbox under window focus settings.
> 
> I don't want this either.
> I want the window under to stay under and not exist as far as focus and
> input are concerned, the way E has behaved for me for literally 20 years
> now.

e never behaved that way. if you have pointer focus the window the pointer was
over would get focused. always. you could have it autoraise or not, but you're
imagining things because i never wrote any such feature like this. no wm i have
ever seen does this either. :)

> How do I get back to that state? I did nothing to get out of it, but
> maybe something changed that I don't understand.
> 
> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/   | PGP
> 7F55D5F27AAF9D08
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Marc MERLIN 
On Wed, May 09, 2018 at 11:16:52AM +0200, Jérémy Zurcher wrote:
> Hello Marc,
> 
> I don't like that default behaviour either.
> but it's very easy to disable :
>   Settings -> Windows -> window focus -> Click window to focus

Yeah, thanks for that workaround, I could do this if I had to.

However, sorry if I'm being dense here:
I've had focus follow mouse for literally 20 years.
I've never had my mouse pointer focus a window underneath the window I'm
pointing on.
I sure don't want that, and E has never ever done this, until now with
0.22.11.

Is it a bug, or is it a setting I missed somehow?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-09 Thread Jérémy Zurcher 
Hello Marc,

I don't like that default behaviour either.
but it's very easy to disable :
  Settings -> Windows -> window focus -> Click window to focus

On Tuesday 08 May 2018  20:02, Marc MERLIN wrote :
> Hi Raster, thanks for the answers.
> 
> On Wed, May 09, 2018 at 11:12:33AM +0900, Carsten Haitzler wrote:
> > yes. pointer focus will focus windows under others. as per video. that is
> > intended. i use it all the time. i like it. mostly windows under others are
> > only minimally obscured. if i dont want it behind it alt+click to raise to 
> > the
> > front.
>  
> Oh my, that's a big change. I really don't want this.
> I don't want the behaviour at all. How do I get a window under my active
> window to never take pointer focus?
> 
> > if you want it to RAISE there is another feature called autoraise. enable 
> > that.
> > then it'll focus and raise... use them together if that is what you prefer.
> > autoraise also can work with click to focus. :) "Raise windows on mouse 
> > over""
> > is the checkbox under window focus settings.
> 
> I don't want this either.
> I want the window under to stay under and not exist as far as focus and
> input are concerned, the way E has behaved for me for literally 20 years
> now.
> 
> How do I get back to that state? I did nothing to get out of it, but
> maybe something changed that I don't understand.
> 
> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet 
> cooking
> Home page: http://marc.merlins.org/   | PGP 
> 7F55D5F27AAF9D08
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-08 Thread Marc MERLIN 
Hi Raster, thanks for the answers.

On Wed, May 09, 2018 at 11:12:33AM +0900, Carsten Haitzler wrote:
> yes. pointer focus will focus windows under others. as per video. that is
> intended. i use it all the time. i like it. mostly windows under others are
> only minimally obscured. if i dont want it behind it alt+click to raise to the
> front.
 
Oh my, that's a big change. I really don't want this.
I don't want the behaviour at all. How do I get a window under my active
window to never take pointer focus?

> if you want it to RAISE there is another feature called autoraise. enable 
> that.
> then it'll focus and raise... use them together if that is what you prefer.
> autoraise also can work with click to focus. :) "Raise windows on mouse over""
> is the checkbox under window focus settings.

I don't want this either.
I want the window under to stay under and not exist as far as focus and
input are concerned, the way E has behaved for me for literally 20 years
now.

How do I get back to that state? I did nothing to get out of it, but
maybe something changed that I don't understand.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-08 Thread The Rasterman 
On Tue, 8 May 2018 17:39:19 -0700 Marc MERLIN  said:

> My most taxing problem is this now:
> https://photos.app.goo.gl/Sz5i3LVFYhh79d9T8
> All windows are set to stacking normal but some windows have a stacking
> so that they steal the mouse focus even tough they're underneath.
> I don't understand how that's possible.
> 
> Should my mouse cursor ever be able to give focus to a window that's
> underneath the current one?
> 
> Background:
> E 0.21.5 would go into a CPU loop that didn't hang it, but sure sucked a
> lot of power.
> 
> So, I foolishly went to 0.22.x, which fixed that problem, but brought a
> load of completely new ones, which Raster says are likely my X server's
> fault (intel, latest version from debian. I was running an older
> version, but upgrading to the latest experimental fixed nothing).
> Basically I had a myriad of problems every time I resumed from sleep,
> not just the mouse cursor going away, but things being hung or not
> working and basically I had to restart E every time I resumed from
> sleep, although that was only one of the problems. I should have written
> the other ones down, but honestly they always happened when I was in the
> middle of other important things and I just needed my WM to work :-/
> 
> Raster, sorry, I know you asked me for some debug, but
> 1) never had time to even get anything building until today
> 2) 0.22 has too many different bugs for me to want to keep trying to use
> it. 

well then we are at an impasse. nothing is going to change or be fixed because
there is no way to know what to change or why, so you will be on 0.21 forever
and we'll move on. sorry. we've been through this before. :(

> So, I went back to 0.21.5 which was painful since my profile was
> incompatible and I had to painstakenly recreate all my window placements
> and save everything.
> Sure enough, CPU hangs again.
> Looked around, no later 0.21.x version in debian, so I pulled the
> 0.21.11 source and after 1.5h of hammering stuff, got it to build in
> debian (missing a lot of build packages, some nicely depended on
> systemd which I don't want on that system).
> I'm now running 0.21.11 built from source using debian build files, and
> sure enough, yet another set of problems.
> 
> First, when I open too many E dialog boxes, everything hangs hard, so
> that I have to go to a text console and killall -9 enlightenment, and
> then things recover. Sigh, not great...
> 
> Can you help me get E 0.21 working well enough that I can go back to
> work and not have to worry about so many WM issues?

0.22 has this fixed... so either move to 0.22 and try what i suggested or go
through every commit in git between 0.21 and 0.22 and try it (unlikely it can
be tried on its own so you'll be bisecting), then read the commit and try modify
the source to suit. that is going to be the slowest possible path, but the one
you want to take. trying to find out what is up with 0.22 is going to be far
easier, and it has the possibility of there being a future to it (see
above) which what you are doing does not. :) even better just use git master
then we're on the same page and you get the latest fixes and improvements and
get to tell us if anything is wrong.

we don't try to put stuff in e or efl that is broken for us - in our testing,
but not all distros and hardware are the same. they contain different versions
and combinations of versions of things, different driver paths, speed and soon
and thus may exhibit bugs that are not seen (where the bug is varies - i have
often enough found bugs in drivers that were considered commercial quality
shipping drivers just because i used a feature in a specific way that was
meant to work by specs but wasn't tested that way). that is where users come in
to help out. what is there is obviously working for someone so what differs to
make it work there and not for you? 

> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/   | PGP
> 7F55D5F27AAF9D08
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-08 Thread The Rasterman 
On Tue, 8 May 2018 17:59:18 -0700 Marc MERLIN  said:

> On Tue, May 08, 2018 at 05:39:19PM -0700, Marc MERLIN wrote:
> > My most taxing problem is this now:
> > https://photos.app.goo.gl/Sz5i3LVFYhh79d9T8
> > All windows are set to stacking normal but some windows have a stacking
> > so that they steal the mouse focus even tough they're underneath.
> > I don't understand how that's possible.
> > 
> > Should my mouse cursor ever be able to give focus to a window that's
> > underneath the current one?
> 
> Ah yeah, I forgot this relevant info:
> ii  libdrm-intel1:amd64 2.4.91-2   
> ii  xorg1:7.7+19   
> ii  xserver-xorg-video-intel2:2.99.917+git20171229-1
> 
> Sadly even 
> saruman:~# apt-get install -t experimental xserver-xorg-video-intel
> does not give me a newer xserver-xorg-video-intel. Not sure if there are bad 
> bugs in there that are getting in the way.
> That said, my understanding was that input focus control was the WM's
> job, so I'm assuming it's E's responsibility.

window focus controls are the wm's job - well to an extent. any x client can
just set the focus too so it's a free-for-all that any client can mess with.

yes. pointer focus will focus windows under others. as per video. that is
intended. i use it all the time. i like it. mostly windows under others are
only minimally obscured. if i dont want it behind it alt+click to raise to the
front.

if you want it to RAISE there is another feature called autoraise. enable that.
then it'll focus and raise... use them together if that is what you prefer.
autoraise also can work with click to focus. :) "Raise windows on mouse over""
is the checkbox under window focus settings.

> Correct?
> 
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet
> cooking Home page: http://marc.merlins.org/   | PGP
> 7F55D5F27AAF9D08
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] problem with input focus and window layering in E 0.21.11

2018-05-08 Thread Marc MERLIN 
On Tue, May 08, 2018 at 05:39:19PM -0700, Marc MERLIN wrote:
> My most taxing problem is this now:
> https://photos.app.goo.gl/Sz5i3LVFYhh79d9T8
> All windows are set to stacking normal but some windows have a stacking
> so that they steal the mouse focus even tough they're underneath.
> I don't understand how that's possible.
> 
> Should my mouse cursor ever be able to give focus to a window that's
> underneath the current one?

Ah yeah, I forgot this relevant info:
ii  libdrm-intel1:amd64 2.4.91-2   
ii  xorg1:7.7+19   
ii  xserver-xorg-video-intel2:2.99.917+git20171229-1

Sadly even 
saruman:~# apt-get install -t experimental xserver-xorg-video-intel
does not give me a newer xserver-xorg-video-intel. Not sure if there are bad 
bugs in there that are getting in the way.
That said, my understanding was that input focus control was the WM's
job, so I'm assuming it's E's responsibility.

Correct?

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users