On 10/25/2013 12:03 PM, Robert Schroll wrote:
...
I'd prefer arbitrary locations, to allow the user to choose where
to save their
files and to allow for run-time localization. But if we restrict
it to a give
sub-directory at compile time, that wouldn't be the worst thing in
the world.
Perhaps I'm thinking too much about files because that's what I'm
used to. What
I really want to do is access content that the user already has on
the device
and add additional content for the user to take off the device. I
had thought
that's what the Content Hub was about, but...
I think you are thinking too much about files. The design of Unity,
scopes,
content-hub, etc is more about content and less about file names and
locations.
I see several things here that will help you and others when they are
implemented:
* system file picker/dialog content provider for the content-hub.
This is an
unconfined process. Beru talks to content-hub, content-hub calls
file
picker, user chooses what to read, content-hub gives it to Beru.
This might
be a copy of the file or in the future a file handle. AIUI, the
goal is to
abstract those kinds of details away so app deverlopers don't have
to worry
about them
* epub content provider for the content-hub. This is the equivalent
of the
gallery content provider for ebub files. Ie, it can be
fancier/prettier/more
useful then a traditional file dialog. Otherwise works just like
above (fyi,
you can see the content-hub in action by changing the background
on the
phone)
* epub unity scope. This allows users to search for/within epub
files and
launch them directly in an app that can handle them
* sharing to other apps implemented-- ie, you can share files from
the file
manager, browser, etc to Beru so it can read them
The main problem right now is everything isn't written yet.
Specifically, I
think there is only one content provider: the gallery-app. More need
to be
written but once more are written multiple content providers need to
be handled
gracefully (ie, should the epub, fpub, gpub, or file picker be
used?). Sharing
to other apps isn't implemented nor is there an epub scope (both
would also need
a way for Beru to easily hook into them).
Our application security model has each application owning its own
data, and
sharing it with other applications. In other words, the ebook
reader should be
storing its files in its own directory, and offering them to other
applications via the content hub.
How does this work for content the user already has? The main
point of Beru is
to let the user read the epubs the user already owns. Can the user
only copy
the content over after they've chosen which reader to use? That
seems
backwards. Furthermore, what if I become evil (well, more evil
than usual) and
stop offering Beru's books to other apps? This locks users into
using Beru (or
forces them to wade through hidden directories to recover their
content).
This approach seems completely counter-intuitive to me. Is the
rationale behind
it documented somewhere?
That is indeed counter-intuitive and is not the intent of the design,
however it
would work at this moment in time. In the future the content-hub and
scopes
solve this-- the user puts content wherever he/she wants and then can
search for
it (scope), open it from within Beru (content-hub) or launch Beru
from another
app (sharing) and Beru doesn't know or care about file locations of
content.
I'm not on the Unity team so I can't give ETAs on when this stuff is
going to
land. I can say that these problems are known though and mainly what
Beru needs
is for someone to implement a content provider so Beru can just use
qtdeclarative5-ubuntu-content0.1 and let the magic happen.
--
Jamie Strandboge http://www.ubuntu.com/
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
