Re: [E-devel] Behavior break

[Simon Lees]

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

[Mike Blumenkrantz]

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 
wrote:

> Hello.
>
> On 30/07/15 07:20, Jean-Philippe André wrote:
> > Hi,
> >
> > On Thu, Jul 30, 2015 at 9:09 AM, Dave  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

[Mike Blumenkrantz]

This issue was unrelated to EFL.

On Fri, Jul 31, 2015 at 5:33 AM, 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?
>
> 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

[Stefan Schmidt]

Hello.

On 30/07/15 07:20, Jean-Philippe André wrote:
> Hi,
>
> On Thu, Jul 30, 2015 at 9:09 AM, Dave  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

[Stefan Schmidt]

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

[Simon Lees]

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  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

[Jean-Philippe André]

Hi,

On Thu, Jul 30, 2015 at 9:09 AM, Dave  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

[Dave]

 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

[Michael Blumenkrantz]

On Wed, 29 Jul 2015 21:09:10 +0900
Jean-Philippe André  wrote:

> Hi
> 
> On Wed, Jul 29, 2015 at 7:46 PM, Jean-Philippe André 
> wrote:
> 
> >
> > On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt  > > wrote:
> >
> >> On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote:
> >> > On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL 
> >> 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

[Jean-Philippe André]

Hi

On Wed, Jul 29, 2015 at 7:46 PM, Jean-Philippe André 
wrote:

>
> On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt  > wrote:
>
>> On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote:
>> > On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL 
>> 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

[marcel-hollerbach]

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 
> wrote:
> 
> > Hello.
> >
> > On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote:
> > > On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL 
> > 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.
> > 
> >
> 
> 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

[Jean-Philippe André]

Hi,

On Wed, Jul 29, 2015 at 5:55 PM, Stefan Schmidt 
wrote:

> Hello.
>
> On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL 
> 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.
> 
>

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

[Stefan Schmidt]

Hello.

On 29/07/15 10:52, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL  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

[The Rasterman]

On Tue, 28 Jul 2015 23:15:20 +0200 Cedric BAIL  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

[Stefan Schmidt]

Hello.

On 29/07/15 08:44, Jean-Philippe André wrote:
> Hi,
>
> On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL  wrote:
>
>> On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz
>>  wrote:
>>> On Wed, 29 Jul 2015 12:21:07 +0900
>>> Jean-Philippe André  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 
> 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 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 

Re: [E-devel] Behavior break

[Jean-Philippe André]

Hi,

On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL  wrote:

> On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz
>  wrote:
> > On Wed, 29 Jul 2015 12:21:07 +0900
> > Jean-Philippe André  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 
> >> > 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 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

[Cedric BAIL]

On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz
 wrote:
> On Wed, 29 Jul 2015 12:21:07 +0900
> Jean-Philippe André  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 
>> > 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 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

Re: [E-devel] Behavior break

[Michael Blumenkrantz]

On Wed, 29 Jul 2015 12:21:07 +0900
Jean-Philippe André  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 
> > 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?

= 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

[Jean-Philippe André]

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 
> 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

[Christopher Michael]

On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote:
> On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL  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

[Mike Blumenkrantz]

On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL  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