Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Alright, we reached the deadline (actually it was yesterday but I was busy) and there's still no real agreement about this, however it seems most of you want the patch reverted, so I will remove it and document it properly. Thanks for your input. On Mon, Jan 9, 2012 at 5:14 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Bruno, while your example is valid, it's not how it will usually be. Most of the time people will use animations, which are bound to keyboard/mouse events. In my code for example, I can scroll a list using the arrow keys, but if you press the arrow twice, then two signals are sent, thus canceling the first animation.so the state of the swalowed object is undefined as it all depends on the elapsed milliseconds between the first and second press of the arrow key. I consider this a race condition. I also doubt that anyone is using edje, then suddenly unswallows the object and decides to keep it there and start to handle it manually in C.If he wanted to handle it in C directly, it wouldn't have been a swallowed part in the first place. i don't disagree though that this might chance the behavior of some really rare apps. As for trusting the .edj, you'd trust it to have specific groups/parts and handle/send specific signals, but you can't trust it to have an object as a specific position. The whole purpose of the edj is to allow the UI dev to decide where to position everything, what sizes to give them and what states. On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobiwrote: On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. Despite it wasn't documented when a person tried to unswallow she realized it was visible, or maybe she looked at the code. Consequently, she didn't forced to show the object with evas_object_show(), what will be mandatory now. So Hermet is correct, it can break applications and won't be something simple to see like an API breakage. People will spend a good time to realize what changed. Sure, we can help with that warning as we can (changelog, msg to mail list, docs, etc). I'm not against the change, but definitely this kind of change need to be more visible for users. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. Despite it wasn't documented when a person tried to unswallow she realized it was visible, or maybe she looked at the code. Consequently, she didn't forced to show the object with evas_object_show(), what will be mandatory now. So Hermet is correct, it can break applications and won't be something simple to see like an API breakage. People will spend a good time to realize what changed. Sure, we can help with that warning as we can (changelog, msg to mail list, docs, etc). This is a bug in the application, that rely on luck more than anything if it worked at any point in time. As I said, if any application rely on it now, just let me touch the edj and it will be broken completly. So no, this is not a big change. And I really doubt that any application outside as this kind of bug that goes unnoticed. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote:
On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote:
I think both are no problems if it has a documentation.
But your patch may break applications already released.
It will be better to apply your patch when major version is changed.
As I say, current behaviour is undefined. If you go out of an
animation (defined in the edj itself) in any state (hidden, moved,
resized, whatever), it will stay in that state. But this is completly
random and not defined (as in, depend on an external file). Now I do
like the raster proposal with an orphaned flag as it is the only sane
way to detect any leak. Relying on an undefined visual artefact would
not help at all.
It isn't documented. But it's defined, IMHO, since you can predict it.
As you said, in an animation it will keep the state, if it was
visible, it will stay visible.
So applications can be considering a unswallowed object will be
visible, since it was visible, and now it will be hidden.
No, as it is defined in the theme, it doesn't depend on the
application. If you change the theme, the animation, anything in the
.edj, it will change the behaviour in the application itself. It's
full of race condition. There is no sane way to expect any kind of
behaviour in the app. It is definitivly an undefined behaviour, as
their is no way you could know the state of the object without
requesting it after the unswallow.
OK, my concept of application is code and theme.
Anyway, a simple case is to add an rectangle to a swallow in a layout.
I've attached a quick example. As you can see, no luck required. After
3 seconds the rectangle is unswallowed and displayed at 0,0.
I agree that most of time people will be hiding or deleting the
object, but as far as I saw we can't predict how user will use our
documented API, what about not documented behaviour...
Despite it wasn't documented when a person tried to unswallow she
realized it was visible, or maybe she looked at the code.
Consequently, she didn't forced to show the object with
evas_object_show(), what will be mandatory now. So Hermet is correct,
it can break applications and won't be something simple to see like an
API breakage. People will spend a good time to realize what changed.
Sure, we can help with that warning as we can (changelog, msg to mail
list, docs, etc).
This is a bug in the application, that rely on luck more than anything
if it worked at any point in time. As I said, if any application rely
on it now, just let me touch the edj and it will be broken completly.
So no, this is not a big change. And I really doubt that any
application outside as this kind of bug that goes unnoticed.
--
Cedric BAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi
#include Ecore.h
#include Evas.h
#include Ecore_Evas.h
#include Edje.h
Eina_Bool
_unswallow_cb(void *data)
{
Evas_Object *layout, *rect;
layout = data;
rect = edje_object_part_swallow_get(layout, swallow);
edje_object_part_unswallow(layout, rect);
evas_object_move(rect, 0, 0);
return ECORE_CALLBACK_CANCEL;
}
int
main (int argc, char *argv[])
{
Ecore_Evas *ee = NULL;
Evas *evas;
Evas_Object *layout, *rect;
ecore_evas_init();
edje_init();
ee = ecore_evas_new(NULL, 0, 0, 200, 200, NULL);
ecore_evas_show(ee);
evas = ecore_evas_get(ee);
layout = edje_object_add(evas);
edje_object_file_set(layout, test.edj, main);
evas_object_resize(layout, 200, 200);
evas_object_show(layout);
rect = evas_object_rectangle_add(evas);
evas_object_color_set(rect, 255, 0, 0, 255);
evas_object_resize(rect, 100, 100);
edje_object_part_swallow(layout, swallow, rect);
ecore_timer_add(3, _unswallow_cb, layout);
ecore_main_loop_begin();
return 0;
}
test.edc
Description: Binary data
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. From my point of view, an edj is a black box that can do anything. There is no such thing like when I unswallow all my theme will always resize the object and make them properly visible. That's why I see this as an undefined behaviour. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. From my point of view, an edj is a black box that can do anything. There is no such thing like when I unswallow all my theme will always resize the object and make them properly visible. That's why I see this as an undefined behaviour. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
2012/1/9 Bruno Dilly bdi...@profusion.mobi: Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. The application has to define a certain policy for the theme, designers can't just go crazy and do whatever crap comes out from their minds without adhering to those specified rules, so it's perfectly possible for a program to expect an unswallowed object to be in a somewhat known state. That said, I don't care whether the change goes in or not, I still believe the undefined behavior is not a reason not to document the change. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Bruno, while your example is valid, it's not how it will usually be. Most of the time people will use animations, which are bound to keyboard/mouse events. In my code for example, I can scroll a list using the arrow keys, but if you press the arrow twice, then two signals are sent, thus canceling the first animation.so the state of the swalowed object is undefined as it all depends on the elapsed milliseconds between the first and second press of the arrow key. I consider this a race condition. I also doubt that anyone is using edje, then suddenly unswallows the object and decides to keep it there and start to handle it manually in C.If he wanted to handle it in C directly, it wouldn't have been a swallowed part in the first place. i don't disagree though that this might chance the behavior of some really rare apps. As for trusting the .edj, you'd trust it to have specific groups/parts and handle/send specific signals, but you can't trust it to have an object as a specific position. The whole purpose of the edj is to allow the UI dev to decide where to position everything, what sizes to give them and what states. On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. -Regards, Hermet- -Original Message- From: Youness Alaouilt;kakar...@kakaroto.homelinux.netgt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt; Cc: Sent: 12-01-08(일) 16:03:53 Subject: Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib I still personally see it as just confusing and an abnormal behavior, and it wasn't helpful at all in finding leaks (because in my case the unswallow happens after the part is 0x0, so the glitch/artifact only happened on race conditions). I will wait for cedric/gustavo's opinion on this, if one of them agrees with you, I'll revert my patch, if not, we can discuss it a bit more. If we can't reach a consensus by monday, I'll just revert my patch and add a note in the documentation instead (although there is already a note about the object not being deleted in the docs). Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 11:45 PM, Daniel Juyung Seo lt;seojuyu...@gmail.comgt;wrote: Yes, I understand what you mean. Both opinion have their own reasons. I was so confused when I first unswallowed my object :( Even I agree with both opinions, how about just letting them as is and just document it? reason1. As Gustavo and Raster said, this is a warning that we have to handle unswallowed object and it's not deleted/hided at all. reason2. We already released edje 1.1 and changing this default behavior doesn't look good at the moment because this will confused our existing customers. If we really need to change it, do this edje 2.0 or whatever. My 2 cents. I'm actually poor so no more 10 cents. Daniel Juyung Seo (SeoZ) On Sun, Jan 8, 2012 at 10:50 AM, Youness Alaoui lt;kakar...@kakaroto.homelinux.netgt; wrote: @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL lt;cedric.b...@free.frgt; wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz lt;michael.blumenkra...@gmail.comgt; wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) lt;sachi...@gmail.comgt; wrote: 2012/1/7 Gustavo Sverzut Barbieri lt;barbi...@profusion.mobigt;: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN lt;no-re...@enlightenment.orggt; wrote: Log: Edje: hide an object after unswallow
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if the part was not visible, unswallow would have issued an hidden object, like this patch does. So I don't know now, if the best is to force its visibility or to hide. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
@Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if the part was not visible, unswallow would have issued an hidden object, like this patch does. So I don't know now, if the best is to force its visibility or to hide. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sat, 7 Jan 2012 20:50:26 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: the real issue here is, leak-wise, that there is no tool to help u find such leaks as the object will never appear in any leak checker as it is tracked by evas anyway. :( (nb - unswallow == edje releases control of the object.) @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if the part was not visible, unswallow would have issued an hidden object, like this patch does. So I don't know now, if the best is to force its visibility or to hide. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Understood, but I don't consider this behavior as a tool :p I don't know about others who use unswallow, but in my case, the unswallow was happening after an animation put the part in a 0x0 geometry state, so it wasn't visible anyways. Either way, what do you think the behavior should be? should I understand from your comment that unswallow should not hide it ? On Sat, Jan 7, 2012 at 9:12 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 7 Jan 2012 20:50:26 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: the real issue here is, leak-wise, that there is no tool to help u find such leaks as the object will never appear in any leak checker as it is tracked by evas anyway. :( (nb - unswallow == edje releases control of the object.) @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sat, 7 Jan 2012 21:27:13 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: well i lean towards leaving it as is. i do see your point though. and well the previous behaviour was a helpful indicator visually. we don't have any way to detect orphaned objects since ownership falls back into the flat base for objects which is where they are all born and they don't require ownership at all. it'd be nice to be able to detect and warn here. :) maybe literally add an orphaned flag to an object - edje can set it once it has orphaned item and if at evas_render it finds orphaned objects it can complain? any further evas calls (show/hide/move/resize etc.) always clear this flag? Understood, but I don't consider this behavior as a tool :p I don't know about others who use unswallow, but in my case, the unswallow was happening after an animation put the part in a 0x0 geometry state, so it wasn't visible anyways. Either way, what do you think the behavior should be? should I understand from your comment that unswallow should not hide it ? On Sat, Jan 7, 2012 at 9:12 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 7 Jan 2012 20:50:26 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: the real issue here is, leak-wise, that there is no tool to help u find such leaks as the object will never appear in any leak checker as it is tracked by evas anyway. :( (nb - unswallow == edje releases control of the object.) @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Yes, I understand what you mean. Both opinion have their own reasons. I was so confused when I first unswallowed my object :( Even I agree with both opinions, how about just letting them as is and just document it? reason1. As Gustavo and Raster said, this is a warning that we have to handle unswallowed object and it's not deleted/hided at all. reason2. We already released edje 1.1 and changing this default behavior doesn't look good at the moment because this will confused our existing customers. If we really need to change it, do this edje 2.0 or whatever. My 2 cents. I'm actually poor so no more 10 cents. Daniel Juyung Seo (SeoZ) On Sun, Jan 8, 2012 at 10:50 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if the part was not visible, unswallow would have issued an hidden object, like this patch does. So I don't know now, if the best is to force its visibility or to hide.
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
I still personally see it as just confusing and an abnormal behavior, and it wasn't helpful at all in finding leaks (because in my case the unswallow happens after the part is 0x0, so the glitch/artifact only happened on race conditions). I will wait for cedric/gustavo's opinion on this, if one of them agrees with you, I'll revert my patch, if not, we can discuss it a bit more. If we can't reach a consensus by monday, I'll just revert my patch and add a note in the documentation instead (although there is already a note about the object not being deleted in the docs). Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 11:45 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: Yes, I understand what you mean. Both opinion have their own reasons. I was so confused when I first unswallowed my object :( Even I agree with both opinions, how about just letting them as is and just document it? reason1. As Gustavo and Raster said, this is a warning that we have to handle unswallowed object and it's not deleted/hided at all. reason2. We already released edje 1.1 and changing this default behavior doesn't look good at the moment because this will confused our existing customers. If we really need to change it, do this edje 2.0 or whatever. My 2 cents. I'm actually poor so no more 10 cents. Daniel Juyung Seo (SeoZ) On Sun, Jan 8, 2012 at 10:50 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm
