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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
