=== salem_ is now known as _salem
[09:48] <dpm> timp, zsombi_, kalikiana, good morning! Quick question: do you happen to know how we relocate the path where the sql databases for app data are looked for in clicks? I think the sqlite databases for apps that use LocalStorage are included inside the click package's directories, right?
[09:52] <kalikiana> dpm: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/src/Ubuntu/Components/plugin/ucapplication.cpp#L73
[09:55] <dpm> thanks kalikiana. Is there a way I could use e.g. an environment variable to define the location? The context is that I'm creating a snap package for the desktop, which installs the calculator app in a write-only location. It all runs, but it expects the DB on that write-only location, and obviously, it can't write to it. Here's what it looks like when I launch it:
[09:55] <dpm> https://paste.ubuntu.com/15252970
[09:57] <kalikiana> write-only? not sure what that really means here
[09:57] <kalikiana> dpm: you can override XDG_DATA_HOME
[09:57] <dpm> kalikiana, that whole directory where the snap is installed is write-only: /snaps/ubuntu-calculator-app.sideload/INeOcWEVXTPI/usr/share/com.ubuntu.calculator/
[09:58] <dpm> when the app tries to create a ./Databases directory in there it then fails
[09:58] <dpm> I'm already overriding XDG_DATA_HOME, that doesn't seem to have an effect on LocalStorage
[10:00] <dpm> http://pastebin.ubuntu.com/15253544
[10:00] <dpm> in fact, overriding a bunch of XDG_* locations
[10:02] <kalikiana> dpm: but... your export points to the folder that you can't used according to the logs...
[10:02] <dpm> kalikiana, actually... really good point
=== JMulholland_ is now known as JMulholland
[10:31] <dpm> kalikiana, overriding XDG_DATA_HOME worked for the databases, but it seemed to broke fontconfig (the app loaded, with no fonts visible). I'll keep trying :)
[10:44] <nik90> appdevs, can one of you review https://code.launchpad.net/~nik90/ubuntu-calendar-app/migrate-listitemlayout/+merge/287309 when you're free. thnx
[10:49] <kalikiana> timp: zsombi_ although I can also mention it here to increase visibility ;-) https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1551665
[10:49] <ubot5> Launchpad bug 1551665 in ubuntu-ui-toolkit (Ubuntu) "was created without a valid QML Engine" [Undecided,New]
[10:50] <zsombi_> kalikiana: good catch :)
[10:50] <zsombi_> to discuss it here I mean ÉÖ
[10:50] <zsombi_> :) stupid layout
[10:51] <timp> kalikiana: can you include some text on how to reproduce (which uitk revision and which qml app to start)?
[10:52] <kalikiana> timp: the word "building" is not clear?
[10:52] <timp> oh, right :)
[10:53] <timp> why are items created while building?
[10:53] <timp> I just built staging without errors
[10:54] <kalikiana> timp: https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-amd64-stable/412/consoleFull
[11:01] <DanChapman> nik90, done :-)
[11:01] <nik90> DanChapman, thnx :)
[11:07] <nik90> DanChapman, pushed the fixes
[11:08] <DanChapman> hah that was ninja quick :-)
[11:09] <nik90> the fixes required were too small
[11:10] <DanChapman> nik90, have you got a link handy to the new design spec? Would be cool to take a look
[11:10] <nik90> DanChapman, https://www.dropbox.com/sh/suo2jb5liedn1x5/AADuNFySY3wsxit0JGl9LsFAa?dl=0
[11:10] <nik90> I also added it to the v0.5 milestone description at https://launchpad.net/ubuntu-calendar-app/+milestone/0.5
[11:17] <zsombi_> timp: those logs are created by the qmlapicheck itself (and/or with qmlplugindump?), as that creates the components to get their API and so it doesn't get a QML engine set...
[11:19] <DanChapman> nik90, thanks :-)
[11:19] <timp> zsombi_, kalikiana: maybe it is just that branch that has the failures? I don't get warnings when I run qmlapicheck.sh locally on staging
[11:20] <kalikiana> timp: it's not just that branch, as I also see them locally
[11:21] <kalikiana> timp: and you won't see any warnings if you just re-build
[11:21] <kalikiana> be sure to do a clean build
[11:22] <kalikiana> timp: oh, why apicheck?
[11:26] <timp> because of what zsombi_ said^
[11:31] <kalikiana> timp: I don't see how apicheck would ever show them given that it suppresses QML errors by default...
[11:32] <kalikiana> (which it does because the real amount of errors from Ubuntu.Components is unbearable)
[11:34] <kalikiana> timp: I think it might be "qmlplugindump Ubuntu.Components 1.3"
[11:35] <kalikiana> which wouldn't run on an unchanged build
[11:36] <timp> zsombi_: do we set a custom flickDeceleration or maximumFlickVelocity somewhere for the flickables and/or listviews that we use?
[11:42] <zsombi_> timp: nope
[11:42] <zsombi_> timp: but we have a bug for that
[11:46] <timp> zsombi_: this bug is related I guess https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1551681
[11:46] <ubot5> Launchpad bug 1551681 in ubuntu-ui-toolkit (Ubuntu) "Sections scroll too fast" [Medium,In progress]
[11:47] <zsombi_> timp: not only that one
[11:47] <zsombi_> timp: picker has at least one, then ListView another one
[11:47] <timp> zsombi_: I'm trying to find the other one. Do you happen to have the link?
[11:47] <zsombi_> timp: nope, but I remember having those... just write the keywords in the search
[11:49] <timp> faenil: yeah, I wanted to quickly fix that scrolling-speed bug together with the left/right arrows bug on the sections. But I think for the scrolling we need more specs.
[11:51] <faenil> timp: a solution for "too fast" is to to slow it down, right? not disable the kinetic scrolling :D
[11:52] <timp> faenil: right. Basically that would be an infinite flickDeceleration ;)
[11:52] <faenil> ??
[11:53] <timp> faenil: you decelerate from a velocity > 0 to a velocity of 0 instantly
[11:53] <faenil> if you set a high deceleration, then you should be able to scroll without it scrolling too fast
[11:53] <faenil> timp: why you want it to go to 0 instantly, that I don't get :)
[11:53] <timp> faenil: I meant that you are right, setting it to 0 instantly is probably a bit too extreme.
[11:54] <faenil> timp: ah, alright :)
[11:54] <timp> faenil: maybe this is a bug for you to take? Because it will need some testing&feedback from a UX designer
[11:54] <faenil> timp: I'm full, full
[11:54] <timp> oh, ok
[11:54] <timp> I was just about to ask you for a review of https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/75-sectionsScroll/+merge/287620
[11:54] <timp> faenil: ^
[11:58] <faenil> timp: sorry, I'd have to read the logic again to make sure that makes sense, and I dont have time now :/ I will leave a comment though
[11:59] <timp> faenil: ok, I will ask for another reviewer
[12:00] <faenil> timp: thanks, sorry, otherwise I can have a look later today if you remind me
[12:00] <timp> faenil: it is not super urgent. So if you can review it today that is fine.
[12:00] <timp> otherwise I can ask another reviewer, no problem as well
[12:00] <faenil> ok, please remind me later timp
[12:00] <timp> ok
[12:32] <faenil> timp: reviewed! :)
[12:33] <timp> faenil: great, thanks :) I'll read your comments after the standup
[12:33] <faenil> thanks
[12:41] <timp> *after lunch
=== _salem is now known as salem_
[13:20] <renatu> nik90, hi are you working on calendar app?
[13:20] <nik90> renatu, yes :)
[13:21] <nik90> renatu, Working on implementing https://www.dropbox.com/sh/suo2jb5liedn1x5/AADuNFySY3wsxit0JGl9LsFAa?dl=0
[13:21] <renatu> nik90, I am rewriting all event layout code
[13:36] <dpm> kalikiana, another question: how do we get i18n.tr() to load the translations from the click app's directory instead of the system one? I'll need to make sure that happens as well for the calculator snap, and I can't recall how we're doing it for clicks
[13:52] <kalikiana> dpm: Similar to other paths but slightly less elegant because it's not using a standard variable http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/src/Ubuntu/Components/plugin/i18n.cpp#L116
[14:23] <nik90> JMulholland, hey, we have a bug with the clock app -> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1518892
[14:23] <ubot5> Launchpad bug 1518892 in Ubuntu UX "[clock] Switching alarm on/off" [Medium,Triaged]
[14:24] <nik90> JMulholland, one proposed solution by michal is "What do you all think about adding trailing action to edit an alarm? That way we can have all area of alarm's ListItem for enabling/disabling an alarm."
[14:24] <nik90> I think that is a really good solution to fix the issue.
[14:44] <timp> faenil: in the SectionsStyle, do you remember why you used sectionsListView.originX to clamp the animation.to?
[14:44] <timp> faenil: originX should be 0, and it seems that some times (when you are scrolled to the right), the estimation of originX by the ListView is wrong
[14:46] <faenil> what do you mean "originX should be 0" ?
[14:46] <faenil> originX changes
[14:50] <timp> faenil: maybe it shouldn't
[14:50] <timp> faenil: some times when I use the left button, it overshoots when we use originX for the clamping.
[14:50] <timp> faenil: with 0 it works fine
[14:51] <timp> why should it change?
[14:52] <timp> http://doc.qt.io/qt-5/qml-qtquick-flickable.html#originX-prop says: This is usually (0,0), however ListView and GridView may have an arbitrary origin due to delegate size variation, or item insertion/removal outside the visible region.
[14:52] <timp> but it seems like in this case when it is not 0 it is just wrong
[14:55] <timp> faenil: interesting, on the right side it overshoots if I DON'T use originX.. on the left it breaks if I DO use it.
[14:55] <faenil> timp: because that's the way ListView works, originX change swhen the content starts triggering the dynamic contentWidth/height algo
[14:55] <faenil> timp: and that algorithm is why sections should have moved away from listview
[15:41] <popey> balloons: yay. 2.1.308 built!
[15:42] <balloons> woot
[15:42] <balloons> with a proper version number!
[15:43] <popey> balloons: thanks!
[15:44] <balloons> running https://core-apps-jenkins.ubuntu.com/view/Maintenance%20Jobs/job/fix-samba-chroot/ to fix samba again
[15:45] <popey> k
=== _salem is now known as salem_
[16:20] <Asdf__> Hello
=== Qwerty is now known as Guest61511
[16:23] <Guest61511> Hello
[16:30] <Guest61511> Hello there..
[16:32] <Guest61511> Anyone tell me .. is it possible to take info from input field of html5 and use it in CPP file
[16:32] <mpt> Hi everyone, I’m working on the design of the toolkit itself, specifically the text field control. There are some cases, like Contacts and Notes, where it’s obvious that a particular area is for typing into, so it doesn’t need a border or a background. Rather than having to remove those properties individually, I think maybe there should be a single property for saying to the toolkit, “just show the text, please”
[16:33] <mpt> The question is: What would be a good name for that property? Ideas so far: unrendered, undrawn, flat, noDecoration, basic, noVisuals
[16:35] <Guest61511> Any developer there???
[16:36] <Guest61511> appdevs
[16:43] <timp> faenil: I updated https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/75-sectionsScroll/+merge/287620
[16:44] <timp> mpt: it could be that we shouldn't have a separate property, but use a different TextFieldStyle
[16:44] <DanChapman> mpt, well UbuntuShape uses an "aspect" property to change the graphical style. Maybe do the same for Text inputs. i.e aspect: TextField.Flat
[16:44] <mpt> timp, sure, but then, what should the style be called :-)
[16:44] <timp> mpt: that would mean that the developer has to set something like styleName: "TextFieldNoDecorationStyle"
[16:44] <timp> mpt: right
[16:45] <timp> mpt: in that case, TextFieldNoDecorationStyle :)
[16:46] <timp> or TextFieldCleanStyle
[16:48] <faenil> timp: commented
[16:50] <timp> faenil: for the hovering logic, the function was executed on every mouse move event, but we need it only when pressed
[16:50] <timp> faenil: right, contains() is a good name. I'll change that. I still have to think about the unit tests
[16:51] <faenil> timp: I think the new logic is broken, read latest comment
[16:53] <timp> faenil: I thought the amount of movement between pressed and released is restricted for a click. Let me check that.
[16:54] <faenil> timp: no
[16:54] <faenil> "This signal is emitted when there is a click. A click is defined as a press followed by a release, both inside the MouseArea (pressing, moving outside the MouseArea, and then moving back inside and releasing is also considered a click).
[16:54] <faenil> "
[16:55] <mpt> (I’m off until Thursday, but I’ll check scrollback for other ideas to name the style ^^^^ when I’m back)
[16:57] <timp> faenil: check again, I pushed an update.
[16:59] <faenil> timp: can you just add "and then released outside the icon, BUT INSIDE THE SAME MOUSEAREA"
[16:59] <faenil> because if he just released outside the icon clicked() wouldn't be fired
[17:00] <faenil> it has to be inside the same area
[17:00] <faenil> timp: also, I'm not 100% sure about the change with originX -> 0.0
[17:00] <faenil> are you sure contentX == 0 is the beginning of the content even when originX != 0?
[17:01] <timp> faenil: I updated the comment
[17:02] <timp> faenil: I am sure that I can click the left icon to get in a state where it scrolls too far when I use originX, and when I change that to 0 it all works as expected
[17:02] <timp> faenil: so I think when you are scrolled to the right, and select a section with a long name, the estimation of originX goes wrong
[17:02] <timp> and it gets corrected while scrolling to the left, but after the animation.to was set
[17:02] <dpm> popey, would you mind reviewing https://code.launchpad.net/~dpm/ubuntu-calculator-app/fix-deb-build-bug-1551848/+merge/287675 ? Trying to get the core app .deb builds (and snap builds :) in shape
[17:03] <faenil> timp: yes, but that's not because it goes wrong, it's because the algorithm is approximte
[17:03] <dpm> or any other calculator deb who is around? ^
[17:03] <faenil> listview doesn't know how much content there is out of view
[17:03]  * popey looks
[17:03] <timp> faenil: right. So then originX gets a wrong estimation
[17:03] <faenil> timp: I fear that using 0.0 only fixes it for the case that you tested
[17:03] <timp> or, if you prefer, an inaccurate estimation
[17:04] <timp> faenil: when would it not be 0.0? originX could change when adding items on the left while being scrolled to the right, but when the sections model changes, we automatically select the first section
[17:04] <faenil> timp: please test it when you have many sections and originX is != 0
[17:04] <faenil> then set contentX = 0 without animation
[17:05] <faenil> timp: no, originX changes even without model changes
[17:05] <timp> I don't think so, only the estimation of originX changes
[17:05] <timp> but when you scroll all the way to the left, the estimation becomes 0 again
[17:07] <faenil> timp: sure, because it's fixed as you slowly scroll
[17:07] <faenil> but try doing contentX=0 without animation, when you have originX != 0
[17:07] <popey> dpm: approved
[17:09] <timp> faenil: tried, and it seems to work fine with 0
[17:09] <faenil> timp: when originX != 0?
[17:12] <timp> faenil: this is interesting, when setting contentX without an animation, it works fine with both setting it to 0 or originX
[17:12] <timp> even when originX != 0
[17:12] <timp> but still originX becomes 0 after you set it
[17:13] <faenil> it's fine tha originX becomes 0, told you that it changes
[17:14] <faenil> but does console.log(contentX) actually print different values
[17:14] <faenil> ?
[17:14] <faenil> after you set it
[17:15] <timp> faenil: I set contentX to -145, and it becomes 0....
[17:15] <timp> somehow it gets fixed, but when using an animation, the animation overrides that
[17:16] <faenil> timp: sure, ok that's expected, that's ListView fixing up things
[17:16] <timp> but not when we have the animation
[17:16] <faenil> no, because we don't let it
[17:16] <faenil> originX probably changes while the animation is still in progress
[17:16] <timp> that's why I had the clamp with: 0.0, // estimation of originX is some times wrong when scrolling towards the beginning
[17:16] <faenil> so at the end of the animation there's nothing that fixes our contentX value
[17:21] <timp> faenil: at the end of the animation is too late. If it would happen there, you show the overshoot animation, and then it jumps to the correct position.
[17:21] <timp> I think we should simply clamp with 0.0
[17:21] <timp> it seems like the ListView does the same when you set its contentX directly
[17:22] <faenil> timp: ListView has fixupX/Y methods that it invokes to fix things
[17:22] <faenil> we don't have access to that
[17:22] <faenil> but if you're sure the solution is 0.0, go with that
[17:22] <faenil> from what I remember from my investigation months ago
[17:22] <faenil> 0.0 is wrong
[17:22] <faenil> but I don't have a proof now
[17:22] <faenil> so I will leave it to you, since it's your task :)
[17:27] <timp> faenil: your branch included code to position the selected section in the middle. Maybe that is where originX was important
[17:28] <timp> faenil: but the requirements changed and the positioning in the middle is no longer wanted
[17:29] <faenil> maybe, who knows, it was too long ago :)
[17:29] <timp> yeah the code with originX came from ensureItemIsInTheMiddle() (which does not exist any more)
[17:31] <faenil> it could have been just a bug that was discovered thanks to that feature
[17:31] <faenil> I don't know :/
[17:31] <faenil> anyway, your call ;)
[17:31] <timp> faenil: I'll leave it at 0
[17:32] <timp> faenil: the unit test for the bug itself is not too hard to do
[17:32] <timp> faenil: I will add the test tomorrow
[17:32] <faenil> ok
[17:32] <faenil> cool
[17:32] <faenil> thanks!
=== dpm is now known as dpm-afk
=== dpm-afk is now known as dpm
=== _salem is now known as salem_
=== salem_ is now known as _salem
[21:43] <nik90> zsombi_, regarding your post in g+, how do you suggest we proceed?
[21:44] <nik90> I mean system-theming was not thought about at all. Up until now, the only thing supported is using Ambiance or SuruDark and then inheriting it to create custom app themes.
=== ljp is now known as lpotter
[23:30] <balloons> popey, after much mangling, I got bzr installed in the chroots. Notice there's version numbers now on builds :-)
[23:30] <balloons> There's a job for it too: https://core-apps-jenkins.ubuntu.com/view/Maintenance Jobs/job/fix-bzr-chroot/
[23:31] <popey> \o/