[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-hardware-devel
Subject: [Kde-hardware-devel] status of udisks2 in Solid
From: Lisa Vitolo <syn.shainer () gmail ! com>
Date: 2012-12-03 22:51:46
Message-ID: CAJy2vLEePh5QqPAX9GDkj6Z=V3cnZ7igY1769EEdTudP_o=oZA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello,
due to personal commitments I unfortunately had few opportunities of
keeping track with the most recent events in the KDE community, but I
noticed there are still some uncertainties about how the switch to udisks2
will be managed. I know Solid has been testing its own backend for udisks2
from some time, so I just wished to know in few words what the
state-of-the-art is (you can point me to appropriate links, no need to
explain everything here in the list).
I'm asking this simply because I'm the student that developed the Solid
submodule for partitioning operations for this summer's GSoC, so of course
the switch to udisks2 will affect my work as well. Of course I had already
started working on it, but I just need some more clarifications. Regarding
this, if you need any help with the udisks2 backend, I'm available: I have
used udisks for a long time now and I can perhaps be of some usefulness to
the project :)
By the way, I talked with Alex in the Solid IRC channel, but it's worth
mentioning in a more official place: my code is now in a usable status and
awaiting for a review. I apologise for the huge delay from the end of the
GSoC project until last week or so, but as I said, other commitments kept
me away from this for longer than they were supposed to. Of course the code
is publicly available at my repository
https://gitorious.org/solid-partitioner/solid-partitioner in the
partitioner branch, and I am always around for any clarification you may
need.
Speaking about udisks2 again, I read that most projects intend to employ
caches to reduce the initial delay caused by udisks2's somewhat slower
detection. Since Solid has always used a cache to speed up access to
devices properties, I believe it will continue to do so. While developing
my module I noticed that under some circumstances some notifications where
delayed: to be more specific, the cache was re-built as a consequence of
receiving a deviceChanged signal *after* a notification warned the user of
a change in the accessibility status of mountable partitions, so
out-to-date data were read. A (not so elegant) trick can be seen in my code
that solves this, but I may have missed some other cases, so well, be
careful about it :)
Good day to everyone,
Lisa
--
“I'll be more enthusiastic about encouraging thinking outside the box when
there's evidence of any thinking going on inside it.”
[Attachment #5 (text/html)]
Hello,<div><br></div><div>due to personal commitments I unfortunately had few \
opportunities of keeping track with the most recent events in the KDE community, but \
I noticed there are still some uncertainties about how the switch to udisks2 will be \
managed. I know Solid has been testing its own backend for udisks2 from some time, so \
I just wished to know in few words what the state-of-the-art is (you can point me to \
appropriate links, no need to explain everything here in the list).</div> \
<div><br></div><div>I'm asking this simply because I'm the student that \
developed the Solid submodule for partitioning operations for this summer's GSoC, \
so of course the switch to udisks2 will affect my work as well. Of course I had \
already started working on it, but I just need some more clarifications. Regarding \
this, if you need any help with the udisks2 backend, I'm available: I have used \
udisks for a long time now and I can perhaps be of some usefulness to the project \
:)</div> <div>By the way, I talked with Alex in the Solid IRC channel, but it's \
worth mentioning in a more official place: my code is now in a usable status and \
awaiting for a review. I apologise for the huge delay from the end of the GSoC \
project until last week or so, but as I said, other commitments kept me away from \
this for longer than they were supposed to. Of course the code is publicly available \
at my repository <a href="https://gitorious.org/solid-partitioner/solid-partitioner">https://gitorious.org/solid-partitioner/solid-partitioner</a> \
in the partitioner branch, and I am always around for any clarification you may \
need.</div> <div><br></div><div>Speaking about udisks2 again, I read that most \
projects intend to employ caches to reduce the initial delay caused by udisks2's \
somewhat slower detection. Since Solid has always used a cache to speed up access to \
devices properties, I believe it will continue to do so. While developing my module I \
noticed that under some circumstances some notifications where delayed: to be more \
specific, the cache was re-built as a consequence of receiving a deviceChanged signal \
*after* a notification warned the user of a change in the accessibility status of \
mountable partitions, so out-to-date data were read. A (not so elegant) trick can be \
seen in my code that solves this, but I may have missed some other cases, so well, be \
careful about it :)</div> <div><br></div><div>Good day to \
everyone,</div><div>Lisa</div><div><div><br></div>-- <br><span \
style="color:rgb(24,24,24);font-family:georgia,serif;font-size:14px;line-height:18px;background-color:rgb(255,255,255)">“I'll \
be more enthusiastic about encouraging thinking outside the box when there's \
evidence of any thinking going on inside it.”</span><br \
style="color:rgb(24,24,24);font-family:georgia,serif;font-size:14px;line-height:18px;background-color:rgb(255,255,255)">
<br>
</div>
_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic