Re: fourth report: cheese integration

["Marc-André Lureau" <marcandre lureau gmail com>]

Hi

I will do my best to give a simple answer, because I might be wrong.
Don't hesitate to ask more questions.

On Mon, Jun 23, 2008 at 11:34 AM, Felix Kaser <f kaser gmx net> wrote:
>
> The problem is: When cheese gets called via dbus, it enters a specific
> method (remote method). In this method cheese should wait until the user has
> taken a picture, then return the path via dbus. But what about the waiting?
> Well the client blocks, but this is not a problem in my opinion. The thing

The dbus client don't have to block when they make calls. They can
call asynchronously with a reply handler (this might be specific to
your dbus bindings).

> is, how to make the "waiting" of the cheese-method? Active waiting (while
> (return_path == null) wait(1); ) sounds really ugly! But what else? Make a
> new thread? Work with signals? Change the whole work flow?

I am not sure about what you mean.
You should be able to stay in a stacked context (within the "remote
method"), if you run your own main loop and wait until it exits. Look
at what gtk_dialog_run() is doing. This is somewhat special though.

Or you can probably add a particular signal handler that will "resume"
your context to answer the call. It might be also interesting to have
a variable that say that you are under this "remote" context and
resume/reply at certain point.

Maybe I am off topic ;)

> opinions also here, what do you think is the best way to make the slim
> version? With a parameter like "-s" for slim or a variable which is set by
> the dbus-remote-method?

Yeah why not!  Why do you want to run a slim version? Cheese is not
that much big or is it?

best regards,

-- 
Frank Lloyd Wright  - "TV is chewing gum for the eyes."