On Wed, Jun 12, 2013 at 12:43 AM, Leif Middelschulte < leif.middelschu...@gmail.com> wrote:
> Am Dienstag, 11. Juni 2013 um 16:19 schrieb Rafael Antognolli: > > Hi, > > > > On Tue, Jun 11, 2013 at 9:54 AM, Daniel Juyung Seo > > <seojuyu...@gmail.com(mailto: > seojuyu...@gmail.com)> wrote: > > > On Tue, Jun 11, 2013 at 9:42 PM, Leif Middelschulte < > > > leif.middelschu...@gmail.com (mailto:leif.middelschu...@gmail.com)> > wrote: > > > > > > > Am Dienstag, 11. Juni 2013 schrieb Daniel Juyung Seo : > > > > > > > > > Hello, this follows elementary policy. > > > > > > > > > > 1. focused object A lose its focus when another object is going to > get > > > > > focus. > > > > > 2. an object is focused when it's clicked. > > > > > > > > > > so the sequence is > > > > > 1. click object B > > > > > 2. focused object A lose its focus > > > > > 3. object B gets focus > > > > > > > > > > So only one object is focused at any point. > > > > > > > > > > It's not possible to unfocus other object before any other object > is > > > > > clicked. > > > > > Because clicked signal will trigger unfocus signal. > > > > > > > > > > > > > > > > > So, as I already imagined, it's due to the current implementation. > > > > > > Not just an implementation. It's a policy. > > > > > > > > > > Can't we trigger "unfocused" callbacks, before we trigger "clicked" > > > > callbacks? I assume that it's the way it is, because Edje understands > > > > > > > > > > > > > How come? > > > I repeat. > > > 1. An object is focused when it's clicked. > > > 2. An object is unfocused when other object is going to be focused. > > > > > > It means mouse click -> unfocused -> focused. > > > > If I understood correctly, Leif is saying that this is not what is > > happening, and his test proves that (I didn't try it). He is saying > > that the current order is: > > > > mouse click -> focused -> unfocused > I haven't considered "focused" events yet, because I want to react to > "clicked while focused" (sets stuff) and "unfocused" (resets stuff) events. > Well, contradiction here. If an object is already focused, click does not emit focused signal again. So "clicked while focused" doesn't happen. > But with current behavior I get: set (click) -> reset (unfocused) > So, afaics, we basically ignore the concept of object focus for "clicked" > events. > Maybe we can have "focused,clicked" or whatever? > Well maybe I should check your fundamental requirement first, not wasting my time on this topic. >From your example I don't get what you really want to do as the final outcome. Even your first email does not describe your goal. Can you show me more code? Thanks. Daniel Juyung Seo (SeoZ) > > Thanks for your explanations, > > Leif > > > > Regards, > > -- > > Rafael Antognolli > > > > > ------------------------------------------------------------------------------ > > This SF.net (http://SF.net) email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net (mailto: > enlightenment-devel@lists.sourceforge.net) > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
