Re: [E-devel] Behavior break
On 07/31/2015 07:03 PM, Stefan Schmidt wrote: Hello. On 30/07/15 13:38, Simon Lees wrote: Hi All, I'm guessing this is maybe the reason why mouse clicks no longer work in the enlightenment-git wizard, created T2622 This bug was closed as resolved. Simon, does it all work for you know or you still see problems? I'll rebuild and test. regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Based on my tests just now, the workaround was broad enough that it still functions as expected now. I'll be putting out a 19.8 release soon, but this is independent of any EFL releases. On Fri, Jul 31, 2015 at 5:38 AM, Stefan Schmidt ste...@osg.samsung.com wrote: Hello. On 30/07/15 07:20, Jean-Philippe André wrote: Hi, On Thu, Jul 30, 2015 at 9:09 AM, Dave d...@flex.com.au wrote: In the year 2015, of the month of July, on the 29th day, Michael Blumenkrantz wrote: There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. Behaviour was also triggered with a sloppy focus policy. That's what I had configured when I noticed the issue. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. I believe I finally understand the issue correctly and: - It should affect only E and potentially other compositors written in EFL - EFL 1.15 should exhibit an issue with E17, E18 and E19 = E19.5 I tested E17.6, E18.8 and E19.5 with EFL 1.15 (git). I played with various focus policies, too. I could not reproduce the issue. According to Mike, E19 E19.6 had other bugs that may cancel this one. All new behaviour has now been disabled by Ji-Youn, so CANCEL will not happen, unnless an env var is set. ok, this is all now hidden behind ECORE_INPUT_CANCEL as env var. https://git.enlightenment.org/core/efl.git/commit/?id=be2a4342b40f7ec073c39e785c39e4c629762ef4 This restores the old behavior and should give us time to sort things out before enabling it by default again. Means it can stay that way for 1.15 and for 1.16 we can have another look. This would also mean that the workaround in E19 is no longer needed and you would want to have another E19 release out before 1.15, right Mike? I delayed until Tuesday anyway. Let me know if that works for you. Anybody else happy with this? regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
This issue was unrelated to EFL. On Fri, Jul 31, 2015 at 5:33 AM, Stefan Schmidt ste...@osg.samsung.com wrote: Hello. On 30/07/15 13:38, Simon Lees wrote: Hi All, I'm guessing this is maybe the reason why mouse clicks no longer work in the enlightenment-git wizard, created T2622 This bug was closed as resolved. Simon, does it all work for you know or you still see problems? regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hello. On 30/07/15 13:38, Simon Lees wrote: Hi All, I'm guessing this is maybe the reason why mouse clicks no longer work in the enlightenment-git wizard, created T2622 This bug was closed as resolved. Simon, does it all work for you know or you still see problems? regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hello. On 30/07/15 07:20, Jean-Philippe André wrote: Hi, On Thu, Jul 30, 2015 at 9:09 AM, Dave d...@flex.com.au wrote: In the year 2015, of the month of July, on the 29th day, Michael Blumenkrantz wrote: There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. Behaviour was also triggered with a sloppy focus policy. That's what I had configured when I noticed the issue. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. I believe I finally understand the issue correctly and: - It should affect only E and potentially other compositors written in EFL - EFL 1.15 should exhibit an issue with E17, E18 and E19 = E19.5 I tested E17.6, E18.8 and E19.5 with EFL 1.15 (git). I played with various focus policies, too. I could not reproduce the issue. According to Mike, E19 E19.6 had other bugs that may cancel this one. All new behaviour has now been disabled by Ji-Youn, so CANCEL will not happen, unnless an env var is set. ok, this is all now hidden behind ECORE_INPUT_CANCEL as env var. https://git.enlightenment.org/core/efl.git/commit/?id=be2a4342b40f7ec073c39e785c39e4c629762ef4 This restores the old behavior and should give us time to sort things out before enabling it by default again. Means it can stay that way for 1.15 and for 1.16 we can have another look. This would also mean that the workaround in E19 is no longer needed and you would want to have another E19 release out before 1.15, right Mike? I delayed until Tuesday anyway. Let me know if that works for you. Anybody else happy with this? regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi All, I'm guessing this is maybe the reason why mouse clicks no longer work in the enlightenment-git wizard, created T2622 Cheers Simon On 07/30/2015 02:50 PM, Jean-Philippe André wrote: Hi, On Thu, Jul 30, 2015 at 9:09 AM, Dave d...@flex.com.au wrote: In the year 2015, of the month of July, on the 29th day, Michael Blumenkrantz wrote: There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. Behaviour was also triggered with a sloppy focus policy. That's what I had configured when I noticed the issue. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. I believe I finally understand the issue correctly and: - It should affect only E and potentially other compositors written in EFL - EFL 1.15 should exhibit an issue with E17, E18 and E19 = E19.5 I tested E17.6, E18.8 and E19.5 with EFL 1.15 (git). I played with various focus policies, too. I could not reproduce the issue. According to Mike, E19 E19.6 had other bugs that may cancel this one. All new behaviour has now been disabled by Ji-Youn, so CANCEL will not happen, unnless an env var is set. And double down can probably not happen outside a compositor. My current stance on this is: this is not really an issue. If anyone else finds a bug in an actual application or in older versions of E, please chime in! Best regards, -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Wed, 29 Jul 2015 21:09:10 +0900 Jean-Philippe André j...@videolan.org wrote: Hi On Wed, Jul 29, 2015 at 7:46 PM, Jean-Philippe André j...@videolan.org wrote: On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt ste...@datenfreihafen.org wrote: On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote: On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. See, my mail about it. I cc'ed her and quoted the problem Dave reported. JP seems also to look into it. I couldn't reproduce the issue (with E 19.5 and EFL git). Weird. Anyways I think Ji-Youn will try to reproduce more and protect the new feature with an environment variable if necessary. But after talking to her, the feature should indeed not change behaviour (in theory). I tested EFL git with E 19.5. In Xephyr and natively. Went to Settings and clicked some checkboxes around without seeing any particular issue. (On the other hand right click in the shelf would crash badly.) IMHO, E 19.6 was a bad release wrt. this issue, but 19.7 fixes it. What matters here is to verify that EFL 1.15 does not introduce an app-breaking behaviour change. Mike, would you mind sharing more details on this issue? Is it actually relevant? There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
In the year 2015, of the month of July, on the 29th day, Michael Blumenkrantz wrote: There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. Behaviour was also triggered with a sloppy focus policy. That's what I had configured when I noticed the issue. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hello. On 29/07/15 08:44, Jean-Philippe André wrote: Hi, On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Wed, 29 Jul 2015 12:21:07 +0900 Jean-Philippe André j...@videolan.org wrote: On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael cpmich...@osg.samsung.com wrote: On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. Sorry to sound so naive, but did you report those behaviour breaks? Why work around instead of fixing EFL? These sorts of things happen regularly. Every time I update Elementary on my desktop, I find new bugs in applications that I've written as a result of behavior changes. We usually say that such changes are justified because it's a bug fix or the previous behavior was broken, but these are still behavior changes which break applications. Ok, this is something that should not happen, but did in the past. That's why I have been advocating for proper behavior checking of the whole stack for a long time and that is finally moving forward with exactness starting to get some love, but much more is needed (still we also need espion to move forward on this). One of the thing we should not let slide, is to report any future breakage as soon as it happen, ideally we should be able to record a trace for an exactness tests suite and make sure that doesn't get broken. If I understand correctly, E 19.6+ are compatible with EFL 1.15, but only E from git is compatible with EFL 1.15? E19.6 requires EFL 1.15 due to behavioral changes E19.6 requires EFL = 1.15 because I didn't get the backwards compatibility right on the first try E19.7 requires EFL = 1.11 (as in E19.0 release) E-git requires = 1.15 for API usage Ok, now I am super confused ! So if we revert the change from current EFL tree, E19.7 should be fine as it is compatible with previous version of EFL. Will E-git still be fine ? If it wil, we can just revert and have the situation fixed. Then we have a problem IMHO since our release cycles are not in sync, we can't just go and break everyone's E by updating EFL. This includes forked versions of E, as well as other applications using ecore events directly. I don't think the release cycle timelines are an issue here, especially considering you're citing forked versions of E which we have no control over. If E19 compatibility is something that we are concerned with, the 19.7 release from last week resolves those issues and will have already been out for long enough that any distributions which ship EFL should have already picked it up by the time the final 1.15 release occurs. That's not how it should work. Any release of EFL should not break a released software that use the expected behavior of EFL. Especially when we only have so few of them. Yeah, we're talking about EFL here, which apparently broke behaviour in such a way that it broke existing apps (E). If we're concerned with theoretical other applications which may be affected by this, I can produce a 19.8 release to remove this codepath in E prior to the 1.15 release, assuming that a decision is made which provides me with enough time to do so. Ideally anyone who has picked up 19.6-7 will also pick up a 19.8 release in time for users to not be affected by any issues. I may misunderstand your sentences here, but the issue is in EFL 1.15 which is breaking existing software not in E. So I believe we should remove the breakage from EFL, and if by reverting things from EFL we have E fixed then we are good. That's the main question here. Is there a precise path to observe the original bug? I'm running E 19.5 with EFL from git but can't see anything special. Or did you actually fix ecore to restore similar behaviour as before? Look at Dave's mail replying to the E 0.19.6 release. He raised the point there. Let me quote it: Something crazy wrong with the settings dialogs in this release. The
Re: [E-devel] Behavior break
On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hello. On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote: On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. See, my mail about it. I cc'ed her and quoted the problem Dave reported. JP seems also to look into it. regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi, On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Wed, 29 Jul 2015 12:21:07 +0900 Jean-Philippe André j...@videolan.org wrote: On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael cpmich...@osg.samsung.com wrote: On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. Sorry to sound so naive, but did you report those behaviour breaks? Why work around instead of fixing EFL? These sorts of things happen regularly. Every time I update Elementary on my desktop, I find new bugs in applications that I've written as a result of behavior changes. We usually say that such changes are justified because it's a bug fix or the previous behavior was broken, but these are still behavior changes which break applications. Ok, this is something that should not happen, but did in the past. That's why I have been advocating for proper behavior checking of the whole stack for a long time and that is finally moving forward with exactness starting to get some love, but much more is needed (still we also need espion to move forward on this). One of the thing we should not let slide, is to report any future breakage as soon as it happen, ideally we should be able to record a trace for an exactness tests suite and make sure that doesn't get broken. If I understand correctly, E 19.6+ are compatible with EFL 1.15, but only E from git is compatible with EFL 1.15? E19.6 requires EFL 1.15 due to behavioral changes E19.6 requires EFL = 1.15 because I didn't get the backwards compatibility right on the first try E19.7 requires EFL = 1.11 (as in E19.0 release) E-git requires = 1.15 for API usage Ok, now I am super confused ! So if we revert the change from current EFL tree, E19.7 should be fine as it is compatible with previous version of EFL. Will E-git still be fine ? If it wil, we can just revert and have the situation fixed. Then we have a problem IMHO since our release cycles are not in sync, we can't just go and break everyone's E by updating EFL. This includes forked versions of E, as well as other applications using ecore events directly. I don't think the release cycle timelines are an issue here, especially considering you're citing forked versions of E which we have no control over. If E19 compatibility is something that we are concerned with, the 19.7 release from last week resolves those issues and will have already been out for long enough that any distributions which ship EFL should have already picked it up by the time the final 1.15 release occurs. That's not how it should work. Any release of EFL should not break a released software that use the expected behavior of EFL. Especially when we only have so few of them. Yeah, we're talking about EFL here, which apparently broke behaviour in such a way that it broke existing apps (E). If we're concerned with theoretical other applications which may be affected by this, I can produce a 19.8 release to remove this codepath in E prior to the 1.15 release, assuming that a decision is made which provides me with enough time to do so. Ideally anyone who has picked up 19.6-7 will also pick up a 19.8 release in time for users to not be affected by any issues. I may misunderstand your sentences here, but the issue is in EFL 1.15 which is breaking existing software not in E. So I believe we should remove the breakage from EFL, and if by reverting things from EFL we have E fixed then we are good. That's the main question here. Is there a precise path to observe the original bug? I'm running E 19.5 with EFL from git but can't see anything special. Or did you actually fix ecore to restore similar behaviour as before? -- Jean-Philippe André --
Re: [E-devel] Behavior break
Hello, On Wed, Jul 29, 2015 at 07:46:55PM +0900, Jean-Philippe André wrote: Hi, On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote: On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. See, my mail about it. I cc'ed her and quoted the problem Dave reported. JP seems also to look into it. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I couldn't reproduce the issue (with E 19.5 and EFL git). Weird. Anyways I think Ji-Youn will try to reproduce more and protect the new feature with an environment variable if necessary. But after talking to her, the feature should indeed not change behaviour (in theory). On the other hand, some users reported that entrance does not work with EFL 1.15 and I can confirm this. But I couldn't find out how to debug E (can we force it to log to a file, when running from entrance?) entrance should log to ~/.entrance_session.log by default. Greetings bu5hm4n Best regards, -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi, On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote: On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. See, my mail about it. I cc'ed her and quoted the problem Dave reported. JP seems also to look into it. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I couldn't reproduce the issue (with E 19.5 and EFL git). Weird. Anyways I think Ji-Youn will try to reproduce more and protect the new feature with an environment variable if necessary. But after talking to her, the feature should indeed not change behaviour (in theory). On the other hand, some users reported that entrance does not work with EFL 1.15 and I can confirm this. But I couldn't find out how to debug E (can we force it to log to a file, when running from entrance?) Best regards, -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi On Wed, Jul 29, 2015 at 7:46 PM, Jean-Philippe André j...@videolan.org wrote: On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt ste...@datenfreihafen.org wrote: On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote: On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL cedric.b...@free.fr said: I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. fundamentally this feature shouldn't break anything in e - it's a new cancel event etc. - but something about the way it is implemented creates an issue. so it really needs fixing, but i think the issue is - that to reproduce the issue requires fairly special situations. jyon needs to be brought into the loop and the issue explained in detail etc. See, my mail about it. I cc'ed her and quoted the problem Dave reported. JP seems also to look into it. I couldn't reproduce the issue (with E 19.5 and EFL git). Weird. Anyways I think Ji-Youn will try to reproduce more and protect the new feature with an environment variable if necessary. But after talking to her, the feature should indeed not change behaviour (in theory). I tested EFL git with E 19.5. In Xephyr and natively. Went to Settings and clicked some checkboxes around without seeing any particular issue. (On the other hand right click in the shelf would crash badly.) IMHO, E 19.6 was a bad release wrt. this issue, but 19.7 fixes it. What matters here is to verify that EFL 1.15 does not introduce an app-breaking behaviour change. Mike, would you mind sharing more details on this issue? Is it actually relevant? -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi, On Thu, Jul 30, 2015 at 9:09 AM, Dave d...@flex.com.au wrote: In the year 2015, of the month of July, on the 29th day, Michael Blumenkrantz wrote: There were a number of issues here, and the only case I found which triggered them was to run Enlightenment with click focus policy (due to how x11 grabs are used. The reporter of the issue for 19.6 was using this, as do I, which is why it was easy for us to notice. Behaviour was also triggered with a sloppy focus policy. That's what I had configured when I noticed the issue. IIRC there were two main issues: 1) mouse event sequencing was rewritten - previous behavior when clicking the mouse went something like DOWN UP, but now if there is a modified down event (eg. DOUBLE DOWN), fake UP events are added before each new DOWN. This caused internal windows to interpret clicks differently in certain cases, such as checkbox widgets behaving as though each single click was a double click. Also after a click, the mouse button would be locked in the DOWN position at the original coordinates, preventing clicks from triggering anywhere else on the canvas 2) fake events were added regardless of device - the way that the new UP events were added involved keeping track of the state of the mouse button, but no information about which device was pressed was tracked. This resulted in issues where multiple input devices would start triggering events for each other, as well as conflicts between different EE engine events. #1 was worked around by both [adding special case behavior for internal windows so that x11 grabs would apply differently and not send events] and [blocking events on internal window canvases during a compositor grab]. The 19.6-7 releases have the first fix, and the second one is pending for a 19.8 release. #2 I made some changes to ee-input to track device state so that at least there would not be conflicts between devices/engines. No other behavioral changes were made in this commit. All current versions of Enlightenment (E19, E-git) will require changes to continue functioning as expected if this EFL behavior is rolled back. I believe I finally understand the issue correctly and: - It should affect only E and potentially other compositors written in EFL - EFL 1.15 should exhibit an issue with E17, E18 and E19 = E19.5 I tested E17.6, E18.8 and E19.5 with EFL 1.15 (git). I played with various focus policies, too. I could not reproduce the issue. According to Mike, E19 E19.6 had other bugs that may cancel this one. All new behaviour has now been disabled by Ji-Youn, so CANCEL will not happen, unnless an env var is set. And double down can probably not happen outside a compositor. My current stance on this is: this is not really an issue. If anyone else finds a bug in an actual application or in older versions of E, please chime in! Best regards, -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. -- Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. dh -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
Hi, On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael cpmich...@osg.samsung.com wrote: On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. -- Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. Sorry to sound so naive, but did you report those behaviour breaks? Why work around instead of fixing EFL? If I understand correctly, E 19.6+ are compatible with EFL 1.15, but only E from git is compatible with EFL 1.15? Then we have a problem IMHO since our release cycles are not in sync, we can't just go and break everyone's E by updating EFL. This includes forked versions of E, as well as other applications using ecore events directly. I have alerted the author of the offending commit and will check with her. Best regards, -- Jean-Philippe André -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Wed, 29 Jul 2015 12:21:07 +0900 Jean-Philippe André j...@videolan.org wrote: Hi, On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael cpmich...@osg.samsung.com wrote: On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. -- Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. Sorry to sound so naive, but did you report those behaviour breaks? Why work around instead of fixing EFL? These sorts of things happen regularly. Every time I update Elementary on my desktop, I find new bugs in applications that I've written as a result of behavior changes. We usually say that such changes are justified because it's a bug fix or the previous behavior was broken, but these are still behavior changes which break applications. If I understand correctly, E 19.6+ are compatible with EFL 1.15, but only E from git is compatible with EFL 1.15? E19.6 requires EFL 1.15 due to behavioral changes E19.6 requires EFL = 1.15 because I didn't get the backwards compatibility right on the first try E19.7 requires EFL = 1.11 (as in E19.0 release) E-git requires = 1.15 for API usage Then we have a problem IMHO since our release cycles are not in sync, we can't just go and break everyone's E by updating EFL. This includes forked versions of E, as well as other applications using ecore events directly. I don't think the release cycle timelines are an issue here, especially considering you're citing forked versions of E which we have no control over. If E19 compatibility is something that we are concerned with, the 19.7 release from last week resolves those issues and will have already been out for long enough that any distributions which ship EFL should have already picked it up by the time the final 1.15 release occurs. If we're concerned with theoretical other applications which may be affected by this, I can produce a 19.8 release to remove this codepath in E prior to the 1.15 release, assuming that a decision is made which provides me with enough time to do so. Ideally anyone who has picked up 19.6-7 will also pick up a 19.8 release in time for users to not be affected by any issues. I have alerted the author of the offending commit and will check with her. Best regards, -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Wed, 29 Jul 2015 12:21:07 +0900 Jean-Philippe André j...@videolan.org wrote: On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael cpmich...@osg.samsung.com wrote: On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. Also not advicating in either direction, but this DID cause US a lot of HEADACHE because it changed expected behaviour. IMO, a bit late in the process to introduce a major change like this. This SHOULD have been done earlier in the cycle and had time to flush out. Sorry to sound so naive, but did you report those behaviour breaks? Why work around instead of fixing EFL? These sorts of things happen regularly. Every time I update Elementary on my desktop, I find new bugs in applications that I've written as a result of behavior changes. We usually say that such changes are justified because it's a bug fix or the previous behavior was broken, but these are still behavior changes which break applications. Ok, this is something that should not happen, but did in the past. That's why I have been advocating for proper behavior checking of the whole stack for a long time and that is finally moving forward with exactness starting to get some love, but much more is needed (still we also need espion to move forward on this). One of the thing we should not let slide, is to report any future breakage as soon as it happen, ideally we should be able to record a trace for an exactness tests suite and make sure that doesn't get broken. If I understand correctly, E 19.6+ are compatible with EFL 1.15, but only E from git is compatible with EFL 1.15? E19.6 requires EFL 1.15 due to behavioral changes E19.6 requires EFL = 1.15 because I didn't get the backwards compatibility right on the first try E19.7 requires EFL = 1.11 (as in E19.0 release) E-git requires = 1.15 for API usage Ok, now I am super confused ! So if we revert the change from current EFL tree, E19.7 should be fine as it is compatible with previous version of EFL. Will E-git still be fine ? If it wil, we can just revert and have the situation fixed. Then we have a problem IMHO since our release cycles are not in sync, we can't just go and break everyone's E by updating EFL. This includes forked versions of E, as well as other applications using ecore events directly. I don't think the release cycle timelines are an issue here, especially considering you're citing forked versions of E which we have no control over. If E19 compatibility is something that we are concerned with, the 19.7 release from last week resolves those issues and will have already been out for long enough that any distributions which ship EFL should have already picked it up by the time the final 1.15 release occurs. That's not how it should work. Any release of EFL should not break a released software that use the expected behavior of EFL. Especially when we only have so few of them. If we're concerned with theoretical other applications which may be affected by this, I can produce a 19.8 release to remove this codepath in E prior to the 1.15 release, assuming that a decision is made which provides me with enough time to do so. Ideally anyone who has picked up 19.6-7 will also pick up a 19.8 release in time for users to not be affected by any issues. I may misunderstand your sentences here, but the issue is in EFL 1.15 which is breaking existing software not in E. So I believe we should remove the breakage from EFL, and if by reverting things from EFL we have E fixed then we are good. That's the main question here. -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Behavior break
Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Behavior break
On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, I have learned that commit 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl tree break all the past version of Enlightenment. Without patching Enlightenment itself, there is no way to fix this apparently. We are now very close to the release and this is breaking one of the few application we have. I think this patch should be reverted asap. Cheers, -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I am not advocating in either direction, but I will need to immediately do another E19 release as well as make changes in E-git if this is reverted; internal windows will remain permanently unclickable in this case since hacks were added to work around these changes. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
