Re: [AD] MSG_IDLE in grabber and menus

[ Thread Index | Date Index | More Archives ]

Elias Pschernig wrote:
> Yes, I agree. Otherwise do_dialog would silently have gone deprecated if
> it contains a d_menu_proc (the grabber being the main reason for the GUI
> - and do_dialog not used there anymore..).
> So the solution would be, while a d_menu_proc is active - scan the
> dialog for d_yield_proc entries. Maybe another, similiar solution would
> be to introduce a new flag - D_IDLE, which keeps objects active during
> menu display.

A little late perhaps, I didn't follow the start of the thread. What
exactly is the problem with just bluntly adding a yield_timeslice in
the menu procedure? If I understood correctly, a simple dialog can
already include a d_yield_proc and that works. So the problem is
apparently that while a menu is _active_, all CPU is eaten and you
can't influence this yourself.

I can't for the life of me imagine a case where, while navigating a
menu with the mouse, one would object against a yield_timeslice or
even a usleep(1000) in the menu code to reduce the CPU usage.

Did I misunderstand the problem?
    Hein Zelle

 Unix is user friendly. It's just very particular about who 
 it's friends are.

 Hein Zelle                     hein@xxxxxxxxxx

Mail converted by MHonArc 2.6.19+