Accept ~ in U1Db database path to support config folder

Lucio - I gather you'll now where to redirect this :)

I think it's important to point out that you want the user's config folder. You don't actually need their home.

I don't think you should make that decision for the developer. I may want to create u1db docs in .cache or .local/share/ if I really want to. Don't force me to using ~/.config (even though that's what we'll go for in this particular case of Telegram).

That's not in fact what I wanted to suggest, apologies for the confusion - I wanted to clarify the context of this bug because "support for ~" is too vague to come up with a better solution. My rule of thumb for good bugs: tell me what you want to achieve, not how ;-)

Ah, I see. Thank you for the clarification :)

On a related note - by setting the bug to "in progress" -- would you consider Giulio's MP is not good?

As I suggested on the merge request comment thread, a solution would be
allow the developer to choose in which destionation the database can be
placed. Since the places allowed by apparmor are limited (I think only
~/.config, ~/.local/share and ~/.cache are available, correct me if wrong),
we could provide an option to choose which one will be used by u1db and
translated accordingly in the correct path. This would avoid the use of ~
and other hardcoded path from the qml side. What do you think about this?

Giulio

On Thursday, October 30, 2014, Michał Karnicki <
<email address hidden>> wrote:
> Ah, I see. Thank you for the clarification :)
>
> On a related note - by setting the bug to "in progress" -- would you
> consider Giulio's MP is not good?
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1387294
>
> Title:
> Accept ~ in U1Db database path to support config folder
>
> Status in Libqtelegram - a qt library to access telegram.:
> Confirmed
> Status in U1DB Qt/ QML:
> In Progress
>
> Bug description:
> Similar to:
> https://bugs.launchpad.net/u1db/+bug/907710
>
> but can't expand home dir from QML. So, to me, the decision to close
> the bug wasn't correct.
>
> See:
>
http://bazaar.launchpad.net/~uonedb-qt/u1db-qt/trunk/view/head:/src/database.cpp#L143
>
> In Telegram, we'd like to use ~/.config/<app package>/foo.u1db -- from
> QML.
>
> PS Please don't point me to
>
http://stackoverflow.com/questions/16408691/get-home-and-or-username-in-qml
- it's a pain.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/libqtelegram/+bug/1387294/+subscriptions
>

On Thu, Oct 30, 2014 at 3:09 PM, Giulio Collura <email address hidden>
wrote:

> Since the places allowed by apparmor are limited (I think only
> ~/.config, ~/.local/share and ~/.cache are available, correct me if wrong),
>

​Not on the desktop. At least not yet. I think your u1db-qt patch is good.
and we should simply use ~/.config/com.ubuntu.telegram/settings.u1db​
(temporarily /home/phablet/...)

Not sure if that answers your question.

--
Software Engineer
Professional and Engineering Services
Canonical Ltd.

Ubuntu - Linux for human beings | www.ubuntu.com

This affects ABI and work-arounds stick like super glue. U1Db already has some tricky compatibility issues delaying major bugs in Query. Hard-coding /home/phablet in the app on the other hand is trivial to change later without affecting anything else.

I'm liking the idea of the enum.

It's true that the desktop is not confined yet. I assume that it won't be long, though - if all apps are confined soon it seems moot to add support now in new code. Do we expect trusted helpers in QML that will still run unconfined and for that matter use U1Db?

Yes, we've temporarily hardcoded /home/phablet.

As to other technicalities, I don't know, I will leave it up to (any active?) U1DB developers to answer.

I suppose this will not be worked on? We may as well use plain sqlite to store settings, but that's not the point. The point is easing developer annoyances in our offer, really.

Maybe we should just go with the "location: Database.ConfigLocation" proposal at this point. It solves the problem sensibly and, so far as I've seen, there's still no real use case for arbitrary path handling in QML. Other APIs like ContentHub are similarly opaque even when files are being passed around.

Been a year, I'm giving up on this one. Removing from Telegram bug list.