Re: event/signal "on-top" [ clarification ]

Jan-Marek Glogowski wrote:
I have to say I still don't catch the idea :-(

If you control the "popup", you can simply set the state.

Yes but I want to keep that logic out of the driving ui code.

You can also hook into the signal emission to catch all signals of a type
via g_signal_lookup and g_signal_add_emission_hook.

Little bit confused

    Ok, the context is a didgital embedded jukebox system with a touchscreen,
so there is never a WM, the user is navigating a series of full screen top-level
windows (and sometimes there are popups).

Glade/libglade will be modified in order to comply with this widget that I'm
writing; this will allow the graphic artist to define an "intro" state to
his animated button without nagging us programmers ;-)

So, ofcourse there will be certain states that pertain only to certain widgets
(where the "set-state" will be done in the ui code and the animation description
will be done by the graphic artist), example; in the "Song Selection interface",
if a song is selected for 10 seconds and the "play button" has not been pressed
yet, it would be nice to set the play button in to an "insistant bling state",
on the other hand, a "screen intro state" can be offered to the graphic artist
as a widget primitive.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]