[Kde-hardware-devel] Shared signals for solid devices

[Kevin Ottens]

On Sunday 7 March 2010 16:07:56 Jacopo De Simoi wrote:
> As far as I understand at the moment each device instance manages its own
> signals and doesn't react to changes induced by other instances which
> might have been created for the same device.

Well, yes and no. That's not the case within a given process, that's the case 
across processes though.

> I would like to add some common signals which would be sent to all instances
> referring to the same /storage/ device.

I think that it's indeed mainly relevant for the StorageAccess interface as 
it's the only one (IIRC) where signals get triggered by one of its method and 
not spontaneously in reaction to something changing in the backend.

OTOH, now that I think about it, it partly comes from a limitation with the 
HAL backend... maybe that won't be the case anymore with udisk, maybe need to 
be investigated a bit first?

> Here come some usecases:
> 
> Wouldn't it be nice if when finished unmounting a device with dolphin or
> with the solid runner the "green checkmark" comes up in the device
> notifier? Wouldn't it be nice if each instance of a device knows that the
> device is going to be unmounted soon and prepares itself accordingly (e.g
> by not polling the free space, since it gives no meaningful result in that
> situation) Wouldn't it be nice if when performing a job (e.g. some long
> backup is in progress), all devices would disable the "unmount" action,
> since it's going to fail anyways; or would be able to ask the user if
> (s)he wants to stop the job and go on with the unmounting...
> 
> If you answered yes to at least one of the previous questions, then we are
> in business =P
> 
> For the first two cases i can only think of a dbus signal containing the
> udi which is listened by every hal storage device, which will act by
> emitting another (qt) signal. I don't know about performance issues with
> this idea..

Only performance issue I see it related to potentially having all the Solid 
enabled applications waking up when the signal is emitted. OTOH that should be 
pretty limited if the signal they listen to is onto a given object path (and 
the the udi wouldn't be needed as parameter). This way they would wake up only 
for object they have in common.

> The last case should be also helped by kio but imho it
> shouldn't be extremely complicated.

Last one is definitely related to KIO indeed.
 
> I am willing to implement the bits, but I'd like to hear your thoughts
> first.

Well, I'm obviously in favor of such a thing, feel free to start a first patch 
that's generally a good base for discussion.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100327/f2594bf3/attachment.sig