Re: Communicate with Brasero through D-Bus ?

[Luis Medinas <lmedinas gnome org>]

Seg, 2010-05-17 às 13:53 +0200, Philippe Rouquier escreveu:
> 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?

This was my idea when i worked on gnome-power-manager inhibit/uninhibit
feature for Brasero. This makes other applications work great with
Brasero so this is a must go for 3.0.

Just to remember that dbus-glib is deprecated and Brasero should use
gdbus from now on. Gdbus is available on the very latest glib release
(from today).
This also remembers me that we should work to port gconf to gsettings :/

Cheers
Luis