Re: Communicate with Brasero through D-Bus ?

[ZedTuX <zedtux zedroot org>]

Hello Philippe,

I didn't receive answer from you.
Are here ? :)

On Mon, 17 May 2010 17:16:15 +0200, ZedTuX <zedtux zedroot org> wrote:
> 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
> _______________________________________________
> brasero-list mailing list
> brasero-list gnome org
> http://mail.gnome.org/mailman/listinfo/brasero-list