Re: Communicate with Brasero through D-Bus ?

[ZedTuX <zedtux zedroot org>]

Hi Philippe,

A real big thank for your quick answer ! :)

I agree with all of your suggestions !
The only thing I was a bit annoyed is about the elapsedChange(). But I
understand your point.
There are no ways to request to D-Bus if someone have subscribe to a signal
?
In that case, you just have to do a check on it, and then send signal or
not.

About the StateChanged method:
You are right, translation will be a problem. That why I have suggest to
use D-Bus property (One per state).
In that case, we should work with integer to define the state.

What do you think about that?

On Mon, 17 May 2010 13:53:43 +0200, Philippe Rouquier
<bonfire-app wanadoo fr> wrote:
> 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