Re: Communicate with Brasero through D-Bus ?

[Philippe Rouquier <bonfire-app wanadoo fr>]

Hi,

Le lundi 17 mai 2010 à 10:06 +0200, ZedTuX a écrit :
> The most important thing are signals.
> I will need a signal :
>  - for Brasero state changed. This mean that Brasero state changed from
> idle to burning for example. [priority: high]
>    Prototype should be something like stateChanged(int, string) that return
> a state id, and optionally the path of the file that Brasero is burning if
> the state id is burning.
The state thing is doable.

As for the path of the file, it is a bit more difficult as you can burn sometimes a collection of files in data projects. Of course this collection is always turned into an image before being burnt but in this case this means a temporary image file which would probably not be interesting. Take also the example of a disc copy, there could be no file written or read (provided you have two devices).
For these reasons, I'm not keen on the path argument.

On the other hand, if you are interested in status, we could come up with a string describing what brasero is currently doing (and even better a copy of what it is displaying in the dialog). My only concern would be translation as perhaps the language would not be the same between the source and the target machines (as I understand your application can work across machines).

So we would have:

StateChanged (int state, string state_description)

Moreover you probably want to have this as a method as well as if you start the application right after a burn process started then you won't be able to know what brasero's state is.
GetState () returning int state and string state_description.

>  - for Brasero elapsed changed when it is burning. [priority: high]
>    Prototype should be something like elapsedChanged(int) returning the
> elapsed seconds, or current progressbar value.
Instead of a signal I'd rather use a method here so that if nobody is listening on the bus, brasero does not bother posting a message on the bus every second or so. Something like
GetProgress (int elapsed_time, int progress_percent)

It would be up to the application to regularly poll brasero (according to its needs) for information.

> And now for methods.
> I will need a method:
>  - to get the Brasero version (need it if there are changes in the D-Bus
> between 2 versions) [priority: low]
>    Prototype should be something like version(string) returning the version
> string.
>    Maybe it could be a DBus property if it's easiest to implement.
A method is fine.
>  - to cancel a burn [priority: normal]
>    Prototype should be something like cancelBurn().
This is more problematic as in some situation (when actually burning for instance), it'd be better to re-ask the user if he really wants to cancel the current operation. I'd rather have a function that match brasero C API for cancelling that is:
CancelBurn (bool cancel_if_not_critical)
if you set cancel_if_not_critical to FALSE then the method would return FALSE (as in not cancelled) if it is called during a critical phase so that you can display a message to the user "It is dangerous to cancel now; if you cancel now, your data / disc / device may not ever be the same. .." and if the user answers yes nevertheless then you can call the above method with cancel_if_not_critical to TRUE to actually cancel the process.

What do you think?

Philippe Rouquier