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

Openmoko Public Trac bugs at
Sun Jul 20 17:51:49 CEST 2008

#1549: [exposure] want to launch exposure again while it is in the e-illume bar,
need 5~10 sec
 Reporter:  wendy_hung  |        Owner:  marek   
     Type:  defect      |       Status:  assigned
 Priority:  normal      |    Milestone:  ASU     
Component:  E - Illume  |      Version:          
 Severity:  normal      |   Resolution:          
 Keywords:  must have   |     Blocking:          
Blockedby:              |  

Comment(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.

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

Ticket URL: <> <>
openmoko trac

More information about the buglog mailing list