Ticket #1549 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

[exposure] want to launch exposure again while it is in the e-illume bar, need 5~10 sec

Reported by: wendy_hung Owned by: marek
Priority: normal Milestone: Om2008.8
Component: E - Illume Version:
Severity: normal Keywords: must have pm
Cc: testing@…, marek@…, zecke@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:


Kernel : 20080705-asu.stable-uImage.bin
Root file system :20080708-asu.stable-rootfs.jffs2

1) launch exposure from home screen
2) go back to home screen (application still running)
3) it need 5~10 seconds to open again

launch it imminently as first time open it up


after_animate.patch (507 bytes) - added by marek 10 years ago.

Change History

comment:1 Changed 10 years ago by wendy_hung

  • Type changed from enhancement to defect

test with the image below:

Root file system:20080714-asu.stable-rootfs.jffs2

don't know what happen, but getting worse, can not reopen it.

comment:2 Changed 10 years ago by marek

  • Cc marek@… added
  • Summary changed from want to launch exposure again whie it is in the e-illume bar, need 5~10 sec to want to launch exposure again while it is in the e-illume bar, need 5~10 sec

expected: exposure is made the top window

explanation: Once exposure (or any other application) is running it should not be started again (this is useless). Instead the user should see the already open application.

status: Exposure should have that feature implemented. It needs a part in exposure (which is done) and a part in illume / e (which is also done).

comment:3 Changed 10 years ago by marek

Just checked with:

Works for me. May be it is not in the stable build yet - feel free to bother Holger about that. :-)

comment:4 Changed 10 years ago by will

  • Keywords must have added
  • Cc zecke@… added

added holger to cc.
I'm sure he'll get to it.

comment:5 Changed 10 years ago by zecke

Playing the ball back to marek.Revision 55 of exposure is in the stable build.

comment:6 Changed 10 years ago by raster

  • Owner changed from raster to marek
  • Status changed from new to assigned

current rev 56 of exposure is pretty broken - doesnt even come up first time. i think exposure is missing using activate() to re-activate an existing shown window like qpe is doing to bring its windows up (now). in marek's court atm... :)

comment:7 Changed 10 years ago by marek

  • Summary changed from want to launch exposure again while it is in the e-illume bar, need 5~10 sec to [exposure] want to launch exposure again while it is in the e-illume bar, need 5~10 sec

I checked in revision 56 yesterday - no change to the activate() call since revision 54.
@raster: Please try to run your test more than once and you will see that it works.

We have 2 situations to make exposure the front window (while it is running):

  • via the launcher (home)
  • via illume bar

The first case is covered by the activate() call which gets called and returns immediately (I messured the time with python). But the result is different every time you try it. It can take a random time from 1 second to 10 seconds until you see the window. May be a problem in the binding ?!

The reactivation via the bar is not handled by exposure at all. Should it ? If so, what would be needed ?

comment:8 Changed 10 years ago by raster

  1. the bar. that is not in exposure's control. it is the same as a "Taskbar" - it's a window manager list and it lists all windows - u select one and e show/brings to the front and focuses the window. that works reliably all the time for all apps. (it could be that exposure is not RESPONDING and not REDRAWING its UI). you know that the window is up but not responding by doing this:
    1. start from home
    2. select "Exposure" from the illume bar
    3. try click on the visible "icons". if they dont respond - it's just framebuffer garbage you have and exposure is up, but not responding.
  1. as for activate() every time i try run exposure while it's already running (ie run from launcher), it NEVER comes oup. it's a 100% failure rate for me. i wrote a test app in c that uses the ecore_evas_activate() call and it works - 100% of the time.

i think it's python and/or the way you use it. first - threads. i have no idea how python does this, but i'd say remove the threads. EFL is NOT threadsafe. even if its not real "pthreads" under python's threads , you are asking for trouble and "bizarre bugs" that some can reproduce, others can not and only happen sometimes or are erratic. from what i see in app-launcherd.py your problem probably is that the client thread is running the main loop, BUT yu call the focus() call FROM the app-launcherd main thread/loop. this alone would explain it as you are just lucky you don't crash. that call will write data to the FD that is your unix socket connection to X - and X buffers these - xlib does, and until the mainloop of the client thread does something to somehow force the buffer to flush - which it may never do if no timers or anything are active, the command will never be sent to X.

so as such... you'll fix the problem if you remove threading.

comment:9 Changed 10 years ago by marek

I just quickly hacked a version which runs without threads. The results are mixed.

In general the response time is much better. But from time to time a click on "home" or "exposure" does not show any reaction. The buttons in the background are clickable though (no garbage in the framebuffer).

Exposure tries to catch a signal to call the activate() function. Once exposure gets the signal the windows is shown almost instantly but it may take up to 10 seconds until exposure receives it. Any idea why this happens ?

I uploaded version 57. Launch exposure.py directly and send SIGUSR2 to make it the top window.

comment:10 Changed 10 years ago by raster

ok 1. bar is not relevant to any changes in exposure. it is entirely done inside the window manager. for me here, it works 100% of the time, no lag. the problem may be that when u press, u press AND drag (a little) and that is not counted as a press (as that list is actually scrollable... so if it's long enough...) i can change the sensitivity to allow more drag to still be registered as a click. but other than that. so if you click on home or exposure and the top bar doesnt slide back on its own - it decided you clicked and DRAGGED and thus didnt want to select it - that may be what you see.if you use a fingernail or stylus its always accurate - with the "pad" of your finger - it wiggles about a lot when u press something... that's why i provided config values fortuning it. try this: click the wrench/spanner to get illume's config (thank god i haven't removed it!) and then in finger scrolling select "Very Low" and see if things improve for you :)

anyway - for the bar, there is not 1 thing you can do to exposure to affect it in any way as exposure isnot involved except in drawing itself when its window is shown.

  1. launcher - sigusr2... did u set up a sgnal handler? or are you using ecore's sigusr -> event conversion wrapper? (and you may have no idea because python has hidden it from you...).

normally signals are never delayed in linux... well - not by 10 seconds. so its something in the handler later...

comment:11 Changed 10 years ago by marek

  1. It may be the case that I move a little but why is the onclick animation shown ? That should only happen if we have a click or is this a onmousedown which can become a click or a drag ?
  1. Yes, I catch the signal. As I explained earlier the window comes to the front but it takes some time. I used the normal python handler to get the signal. May be that conflicts with your main loop somehow. How do I get ecores sigusr ?

comment:12 Changed 10 years ago by raster

  1. its an onmousedown that starts the green animation, but it is a mouse UP that ends the action. as between the mouse down and up you may or may not drag - the whole action may become either a click (a down then up with minimal movement) OR it becomes a drag (at which point it should not activate the selected item). same thing as in the etk scrolledview before - e has this and it has tuning parameters to determine what is a drag and what is just a regular click+release. thus why i suggest you play with the settings :)
  1. aaah you set your own signal handler. and i guess you call activate() from the signal handler? bad! signal handlers are just as bad as threads. they can interrupt anything - preemptively and when they return do nothing special. so the same explanation for threads not working above counts for signal handlers. in fact signal handles should do almost nothing - or as little as possible. don't use a signal handler, OR use ecore's signal handler wrappers (that convert signals to events). they were created for just this reason - that signal handlers are unreliable to use for any serious work, but if you just use them as signallers and then from there add events into an event queue - and process the event queue in the main loop as normal... it works fine.

so... you need some way of doing this without threads or signal handlers (or sysv ipc... i could start to think of other messaging/signalling systems you also dont want to use). you want a socket or a fd/pipe or something else.

comment:13 Changed 10 years ago by marek

  1. That means I can mousedown on one item and get the animation. Then I move my finger and nothing happens ? That seems pretty bad ...

I wrote a little patch for etk_list in our ninja theme to avoid this kind of problems. It creates an after_animation hook that you can grab. So, onmouseup launch the animation and then you wait for the signal from edje. Tick installed some ugly timeouts to get the same effect - that is why I provided that patch some weeks ago. I hope he applied it.
I attach the patch here.

  1. Why is E so weak in handling asynchronous events ? Is that a design decision, a X11 limitation or what ? I'm used to use all the godies my linux world offers to me. ;-)

How do I use the ecore's wrapper to get the signal ? Any documentation or example available ?

Changed 10 years ago by marek

comment:14 Changed 10 years ago by raster

  1. i could have the animation happen on mouseup, but it happens to be on mouse down to provide instant feedback.
  1. async - efl is perfectly great at async... it is NOT threadsafe. everything you have been doing is doing things from threads or from what effectively acts as a thread (signals handlers interrupt any execution and jump straight to the handler - just like an preempting of a processor thread would just remove control on a single-cpu system to another thread). i have lots of async code. LOTS. you are just chosing to always do things with threads even though EFL is not threadsafe. BTW - you'd have the same problem with gtk and qt - if you DIDNT call some sort of "flush" to flush the x pipeline as you have written a command to a buffer - but that command isn't write()en to the file descriptor to x until you flush or it fills up. nothing to do with EFL here - it's to do with using thread-constructs and not flushing buffers. if the buffers were flushed it'd work (by sheer luck), but u'd have a thread-bug waiting to happen. making a system threadsafe is a huge amount of work and is runtime overhead (all data that could be shared between threads needs locking and unlocking at all points and it's not an insignificant amount of code that sooner or later you forget a lock or unlock somewhere, or u happen to create a deadlock condition). i chose not to do it from early on. btw - anyone who has done work with gui's and x will tell you not to use signal handlers to do actual gui work - as they can pretty much destroy the flow of logic, order of operation, create deadlocks etc. you should always do as absolutely little as possible in a signal handler and keep it really simple.

anyway - as for using ecore's handlers, in c it's very simple.

static int my_callback(void *data, int type, void *event_in) {

Ecore_Event_Signal_User *ev = event_in; get event info
if (ev->number == 2) ecore_evas_activate(data);
if sugusr2 (2 vs 1 for sigusr1)
return 1; let someone else handle the event if they like - return 1


in init code for canvas
Ecore_Evas *my_ecore_evas_handle;
handle for the canvas window
assuming you set up the canvas at some point with handle of my_ecore_evas_handle
Ecore_Event_Handler *handler;
handler handle

handler = ecore_event_handler_add(ECORE_EVENT_SIGNAL_USER, my_callback, my_ecore_evas_handle);

... other stuff

when done - ie dont need handler anymore (shutdown or deletion of canvas)

comment:15 Changed 10 years ago by marek

  • Keywords pm added
  1. We don't need feedback if nothing happens or did I misunderstand something ? At least our testing team is irritated. I think Will should make a decision here.
  1. Sorry, I did not mean you have to explain that here. We can discuss this next time we meet. We have to live with what we have although others might be different. It all comes down to decisions which have advantages and disadvantages - depends what death you are willing to die. ;-)

What kind of signaling is more suited for the e stuff ? What would you suggest regarding my problem ? I opt for simple and well working solutions.

comment:16 Changed 10 years ago by raster

1) i just changed the sensitivity... look at asu dev images built these days... have to wait for holger to propagate to stable.
2) the problem again is python (bindings). if u kept an ecore main loop running then you could use the Signal_User event and do it all cleanly... and in c it's trivial, as above, but python, i believe doesnt wrap these. thus blocks their use from you (until wrapped). they were put in there for this kind of usage scenario - if you want to use simple system signals for some form of ipc. as such i use this in several places myself - in e17 i use it for the init splash to synchronize startup, sigchilds are handled all the time for exiting subprocesses (and converted to events with the whole waitpid() thing done for you collecting exit code and other information all nicely delivered in an event). e17 also uses sighup as a restart and re-loadconfig signal... so it all works... but it works because it uses the constructs created for just this (to make it reliable and simple without "gotchas" of normal signal handlers). :( python is being your problem - or more specifically the bindings and the fact they are a subset. so as such signalling via sigusr1/2 will work just fine... IF you use the constructs designed to streamline this into the main loop. because you set your own signal handler - you removed that feature basically (which you couldn't use anyway as the bindings don't support it)...

now... choices are:

  1. add more to the python bindings to allow use of these events:


  1. try another mechanism that the bindings already support.

with #2 - you have fd_handlers.. you could create a pipe (named pipe somewhere - not unix socket) and then st up an fd handler to listen for a read on it - write to it to wake it up, on any data being written just activate...

look for fd_handler_add in the ecore bindings...

comment:17 Changed 10 years ago by will

Let's do this:

  1. At 'press down' animation starts filling space with green
  2. Only at 'release', animation finishes, green disappears

So each press and release should be a full animation,
not the short animation that we get now (release before animation is complete).

  • If screen recognizes a 'scroll' then animation does not start at all.
  • If 'press down' then 'scroll', animation stops at whatever point it is at, nothing gets launched.

comment:18 Changed 10 years ago by marek

  • Status changed from assigned to in_testing

Lets split up these 2 bugs. I created bug #1705 for illume.

The exposure bug has been fixed upstream. The stable image should be updated soon.

comment:19 Changed 10 years ago by wendy_hung

  • Status changed from in_testing to closed
  • Resolution set to fixed

Tested with the image below:

root file system:20080805-asu.stable-rootfs.jffs2

Now it's faster, less than 5 seconds.
Thank you.

Note: See TracTickets for help on using tickets.