[00:10] hello [00:11] ls === chihchun_afk is now known as chihchun === chriadam is now known as chriadam|away [08:47] Hello [08:48] Somone already had a problem with translation ? [08:58] hi all [09:12] Good morning all; happy Friday, and happy No News is Good News Day! 😃 === JMulholland_ is now known as JMulholland === javiercrowsoft1 is now known as javiercrowsoft [13:59] 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] 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] mzanetti: it is fine in portrait, but landscape isn't [14:01] mzanetti: 'automaticOrientation: false' in MainView doesn't seem to inhibit the rotation. only if I use the indicator to pin it [14:01] jdstrand, i think thats handled by u-a-l, so needs to be in the .desktop file [14:02] 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] oh [14:03] https://wiki.ubuntu.com/Unity8/FullShellRotation [14:03] X-Ubuntu-Supported-Orientations=portrait [14:03] mzanetti: nm, but thanks anyway :) [14:03] ogra_: thank you :) [14:04] jdstrand, hey, sorry, having a day off and am mostly afk today [14:04] mzanetti: no worries at all-- sorry to disturb you :) [14:04] no prob. always happy to help [14:04] thanks :) [14:05] jdstrand, so, nothing to do in the code (except maybe adjust the layout of your buttons if width > height or similar) [14:06] 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] ack [14:08] mzanetti, it is also currently horridly broken [14:08] ogra_, what? [14:09] well, locking the screen forces to portrait ... unlocking usually gets you a mashed up image of the app then and such stuff [14:10] 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] yay it worked :) [14:21] 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] jdstrand, thats all popey's scripts :P [14:22] haha [14:23] fyi, I'm happy to add other wordlists if people want to submit them [14:24] I managed to cobble together a massive spanish one... [14:24] ok, really getting back to something productive [15:58] 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 ? === balloons_ is now known as balloons [16:01] t1mp: what if you would have enum there, and cover all? [16:02] t1mp: or have a status property and exposed bool [16:03] t1mp: in which case the exposed should be set 1) [16:06] zsombi: t1mp why not have a .moving property? in conjuction with .visible that should be self-evident [16:07] aside from that I would probably expect that .exposed is visible && !moving [16:24] kalikiana: I have visible, exposed, and moving [16:25] 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] t1mp: doesn't visible become false when it's hidden? [16:26] 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] kalikiana: I could make it false when it is completely hidden. [16:26] kalikiana: how is that related to when the value of exposed is changed? [16:27] t1mp: because to me !visible && !moving is the same as !exposed [16:27] or just !visible effectively [16:28] t1mp: I don't really see what case there is that's not explained by those two properties [16:28] kalikiana: right. when !moving, the values of visible and exposed are clear [16:28] kalikiana: ah [16:28] kalikiana: the developer can do exposed = false in order to hide the header [16:28] kalikiana: doing that will animate the header out of the view [16:28] kalikiana: when you set visible to false, it would just disappear [16:29] 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] t1mp: even if you have a behavior on it? [16:30] hmm yeah probably same thing [16:31] 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] right. So then the value is updated when the animation starts [16:33] 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] so basically the same. I update the value when the (internal) show()/hide() functions are called. [16:34] yeah [16:34] that would make sense to me [16:40] sverzegnassi, I'm rebuilding all the old mp's now. Jenkins is passing things [16:46] kalikiana: cool, thanks. I'll do it like that :) [16:47] kalikiana: actually I implemented updating exposed when the animation is done, but it is easier to update it when the animation starts [16:59] mcphail: another month, another ping ☺ [17:14] 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] ergo exposed updates at the start of the animation for consitancy [17:34] balloons: great! thank you! [18:05] kalikiana: right. That's what we agreed on now, but that's not what I have implemented yet [18:05] first I implemented the more complicated way of doing it ;) [18:06] ah I see now [20:52] nemo: how's it going? [20:52] evening mcphail [20:52] popey: good evening [20:53] nemo: you around on Monday evening? We can have another look at this === Inglebard1 is now known as Inglebard [22:42] zsombi: hey, is it possible to access Alarms enum variables like status, daysOfWeek etc from C++ ? [22:44] zsombi: and https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1486008/comments/13 :) [22:44] Ubuntu bug 1486008 in ubuntu-ui-toolkit (Ubuntu) "[sdk] leading actions width is too small making it very difficult to press" [Medium,Confirmed] [22:44] thnx Elleo [22:45] 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] 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] Elleo: Ah ok .. a temp style file for now should do the trick. [22:47] 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