[00:10] <brianMc> hello
[00:11] <brianMc> ls
[08:47] <NymeriaFr> Hello
[08:48] <NymeriaFr> Somone already had a problem with translation ?
[08:58] <kivi> hi all
[09:12] <JamesTait> Good morning all; happy Friday, and happy No News is Good News Day! 😃
[13:59] <jdstrand> mzanetti: hey, asking you cause you always seem to have the answer :) feel free to disregard/point me somewhere else if you don't know otoh (ie, don't waste time on this)
[14:00] <jdstrand> mzanetti: I have two apps that don't handle screen rotation well (blabble and a chess program I am writing)
[14:00]  * ogra_ notes down "zanetti always has the answer" ...
[14:00] <jdstrand> mzanetti: it is fine in portrait, but landscape isn't
[14:01] <jdstrand> mzanetti: 'automaticOrientation: false' in MainView doesn't seem to inhibit the rotation. only if I use the indicator to pin it
[14:01] <ogra_> jdstrand, i think thats handled by u-a-l, so needs to be in the .desktop file
[14:02] <jdstrand> mzanetti: is there something else in MainView I should be using or do I have to add logic to deal with the rotation (and if that is the case, is there a guide?)
[14:02] <jdstrand> oh
[14:03] <jdstrand> https://wiki.ubuntu.com/Unity8/FullShellRotation
[14:03] <jdstrand> X-Ubuntu-Supported-Orientations=portrait
[14:03] <jdstrand> mzanetti: nm, but thanks anyway :)
[14:03] <jdstrand> ogra_: thank you :)
[14:04] <mzanetti> jdstrand, hey, sorry, having a day off and am mostly afk today
[14:04] <jdstrand> mzanetti: no worries at all-- sorry to disturb you :)
[14:04] <mzanetti> no prob. always happy to help
[14:04] <jdstrand> thanks :)
[14:05] <mzanetti> jdstrand, so, nothing to do in the code (except maybe adjust the layout of your buttons if width > height or similar)
[14:06] <mzanetti> jdstrand, so far everything is handled by the .desktop file. but I'm arguing for an api that lets us change the setting at runtime for the future
[14:08] <jdstrand> ack
[14:08] <ogra_> mzanetti, it is also currently horridly broken
[14:08] <mzanetti> ogra_, what?
[14:09] <ogra_> well, locking the screen forces to portrait ... unlocking usually gets you a mashed up image of the app then and such stuff
[14:10] <ogra_> forcing something vs using the physical orientation doesnt really work well ... (i know that will be fixed once scopes and greeter support it)
[14:16] <jdstrand> yay it worked :)
[14:21] <jdstrand> huh, nearly half of the downloads by country are from the UK. guess it is a good thing I added the UK dictionary :)
[14:21]  * jdstrand goes back to something productive
[14:22] <ogra_> jdstrand, thats all popey's scripts :P
[14:22] <jdstrand> haha
[14:23] <jdstrand> fyi, I'm happy to add other wordlists if people want to submit them
[14:24] <jdstrand> I managed to cobble together a massive spanish one...
[14:24] <jdstrand> ok, really getting back to something productive
[15:58] <t1mp> zsombi, kalikiana: when should Header.exposed be updated? 1) when the animation to show/hide the header is finished 2) when the animation starts 3) when flicking such that releasing would cause the header to be shown/hidden ?
[16:01] <zsombi> t1mp: what if you would have enum there, and cover all?
[16:02] <zsombi> t1mp: or have a status property and exposed bool
[16:03] <zsombi> t1mp: in which case the exposed should be set 1)
[16:06] <kalikiana> zsombi: t1mp why not have a .moving property? in conjuction with .visible that should be self-evident
[16:07] <kalikiana> aside from that I would probably expect that .exposed is visible && !moving
[16:24] <t1mp> kalikiana: I have visible, exposed, and moving
[16:25] <t1mp> kalikiana: basically I don't touch visible so it is always true. It is the property inherited from QQuickItem and it is FINAL so I cannot replace it
[16:25] <kalikiana> t1mp: doesn't visible become false when it's hidden?
[16:26] <t1mp> kalikiana: moving is obvious, that one is true iff the user is flicking the flickable, or the header is animating to fully exposed/hidden position
[16:26] <t1mp> kalikiana: I could make it false when it is completely hidden.
[16:26] <t1mp> kalikiana: how is that related to when the value of exposed is changed?
[16:27] <kalikiana> t1mp: because to me !visible && !moving is the same as !exposed
[16:27] <kalikiana> or just !visible effectively
[16:28] <kalikiana> t1mp: I don't really see what case there is that's not explained by those two properties
[16:28] <t1mp> kalikiana: right. when !moving, the values of visible and exposed are clear
[16:28] <t1mp> kalikiana: ah
[16:28] <t1mp> kalikiana: the developer can do exposed = false in order to hide the header
[16:28] <t1mp> kalikiana: doing that will animate the header out of the view
[16:28] <t1mp> kalikiana: when you set visible to false, it would just disappear
[16:29] <t1mp> I cannot use 'visible' for opening/closing the header because it basically sets the opacity, doesn't animate the y-value as I want to
[16:29] <kalikiana> t1mp: even if you have a behavior on it?
[16:30] <kalikiana> hmm yeah probably same thing
[16:31] <kalikiana> t1mp: so if exposed is set by the developer it would have to be updated right away when the animation starts - that is what has to happen if the developer sets it, anything else would be inconsistent
[16:33] <t1mp> right. So then the value is updated when the animation starts
[16:33] <t1mp> exposed can also change because the user flicks the flickable. I can update 'exposed' then when the user releases and the animation starts
[16:33] <t1mp> so basically the same. I update the value when the (internal) show()/hide() functions are called.
[16:34] <kalikiana> yeah
[16:34] <kalikiana> that would make sense to me
[16:40] <balloons> sverzegnassi, I'm rebuilding all the old mp's now. Jenkins is passing things
[16:46] <t1mp> kalikiana: cool, thanks. I'll do it like that :)
[16:47] <t1mp> kalikiana: actually I implemented updating exposed when the animation is done, but it is easier to update it when the animation starts
[16:59] <nemo> mcphail: another month, another ping ☺
[17:14] <kalikiana> t1mp: I thought that's what we agree should happen anyway? if you manually set exposed = true that is necessarily before anything moves, which is why I argued in favor of that
[17:14] <kalikiana> ergo exposed updates at the start of the animation for consitancy
[17:34] <sverzegnassi> balloons: great! thank you!
[18:05] <t1mp> kalikiana: right. That's what we agreed on now, but that's not what I have implemented yet
[18:05] <t1mp> first I implemented the more complicated way of doing it ;)
[18:06] <kalikiana> ah I see now
[20:52] <mcphail> nemo: how's it going?
[20:52] <popey> evening mcphail
[20:52] <mcphail> popey: good evening
[20:53] <mcphail> nemo: you around on Monday evening? We can have another look at this
[22:42] <nik90> zsombi: hey, is it possible to access Alarms enum variables like status, daysOfWeek etc from C++ ?
[22:44] <nik90> zsombi: and https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1486008/comments/13 :)
[22:44] <nik90> thnx Elleo
[22:45] <Elleo> nik90: yeah, I've just been sorting out the last podbird tweaks and found that super annoying with the new listitems, so thought I'd better figure out what was going on :)
[22:46] <Elleo> nik90: I might temporarily ship a patched ListItemStyle.qml with podbird so we don't have to wait for OTA-7 for it to get fixed
[22:47] <nik90> Elleo: Ah ok .. a temp style file for now should do the trick.
[22:47] <Elleo> yeah, I've got a hacky fix at the moment that'll work, but I might wait to see how zsombi fixes it properly and include that instead