| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| davidcalle | Morning all | 07:34 |
|---|---|---|
| robin-hero | hi all! I'm trying to build ubuntu clock app from bzr. But got this error: "/ubuntu-clock-app/app/ubuntu-clock-app.qml:20 module "DateTime" is not installed" | 08:12 |
| robin-hero | Which package I need to install? | 08:12 |
| Mirv | how do I list available click chroots from command line? | 08:28 |
| Mirv | is it supposed to be done just via schroot -l ? | 08:28 |
| popey | with sudo, yes | 08:29 |
| popey | http://paste.ubuntu.com/12139782/ | 08:29 |
| Mirv | thank you, right. it's a bit confusing there's click chroot create / destroy but no list | 08:34 |
| karni | anyone seen dpm recently? trying to get a hold of him :) | 08:48 |
| didrocks | zsombi: hey, I would really appreciate if you talk with kenvandine and can coordinate between people who wrote that code for bug #1485222. I don't think I can add any value to the discussion other than ping-ponging on that bug as I already gave a simple reproducer. | 08:49 |
| ubot5 | bug 1485222 in ubuntu-ui-toolkit (Ubuntu) "Using ContentStore disables silently any StateSaver capability" [Undecided,New] https://launchpad.net/bugs/1485222 | 08:49 |
| zsombi | didrocks: well, I wrote the code... | 08:50 |
| didrocks | I'm happy to create the simple qml file which is failing if needed, it's only taking a minute for it (as per my instructions) | 08:51 |
| zsombi | didrocks: I am surprised that it only appeared now... | 08:51 |
| didrocks | zsombi: I can't tell you if that worked on vivid though, I didn't use the ContentStore back then | 08:51 |
| zsombi | didrocks: if the ContentStore alters APP_ID or application name in some way, then StateSaver will be screwed, it won;t find the state database anymore | 08:52 |
| zsombi | didrocks: but as said, unless it is getting priority for OTA, I cannot do much | 08:52 |
| didrocks | do we have a process for that, is that pinging Pat basically? | 08:53 |
| didrocks | so, it does mean that any bug opened and not getting management priority for the sdk are never going to be fixed? | 08:54 |
| zsombi | didrocks: also, but i also means that the bug is critical, meaning it blocks core apps from being released etc | 08:54 |
| zsombi | didrocks: dude, noone said that, it's just not righ tnow | 08:54 |
| popey | karni: he's on vacation this week and next, can I help? | 08:55 |
| didrocks | I'll then try to get it in the list, the other 30 bugs I opened were workaroundable at least, (even if not elegant), that one can't though, and it seems it's a pretty basic developer case | 08:56 |
| karni | popey: I think it can wait. But have you perhaps seen any app that allows interface language switching (other than via global phone setting)? I know how to add that, but I'm not sure how well it could fit with our i18n.tr / gettext story. | 08:57 |
| popey | karni: i haven't seen such an app | 08:58 |
| karni | popey: okay, no prob :) cheers | 08:59 |
| Mirv | so I'm getting stage=setup-start error every time I use the armhf in Qt Creator, and the schroot command there fails in mounting.. | 09:00 |
| Mirv | on this new machine I don't have the ecryptfs anymore, but I guess the mounts part is still somehow broken | 09:00 |
| t1mp | zsombi: I cannot override Item's visible, so we need another property for Header.visible | 10:16 |
| t1mp | I had "opened" for the toolbar before, but it doesn't seem like the perfect property name | 10:17 |
| t1mp | for now I'll go with readonly property opened, and functions open() and close() | 10:23 |
| t1mp | hmm | 10:23 |
| t1mp | or readonly property hidden, and functions show() and hide() | 10:23 |
| zsombi | t1mp: exposed? | 10:36 |
| t1mp | zsombi: maybe "hidden" is not so bad. Basically the Header Item is visible, but you cannot see it because it hide off the edge of the screen ;) | 10:37 |
| t1mp | so there is a header but you don't see it | 10:37 |
| zsombi | t1mp: that's opposite of visible, so not good | 10:37 |
| t1mp | unless you scroll or call show() | 10:37 |
| t1mp | zsombi: yeah, kind of the opposite.. maybe not 100% the opposite | 10:38 |
| t1mp | zsombi: you are visible but you can still hide ;) | 10:38 |
| zsombi | t1mp: uhm.. yoiu can be visible but hidden? | 10:38 |
| zsombi | t1mp: well, visible and not exposed... almost the same | 10:39 |
| zsombi | t1mp: flippedIn | 10:39 |
| t1mp | zsombi: I could use visible: header.y + header.height > 0 | 10:41 |
| t1mp | zsombi: but I cannot make that property readonly | 10:41 |
| zsombi | t1mp: you cannot even override, it's final, ain't it? | 10:41 |
| t1mp | yes | 10:41 |
| t1mp | so developers can say visible = false and the header disappears, without the animation | 10:41 |
| zsombi | t1mp: so you can only override it in cpp | 10:42 |
| t1mp | even if I can override, it is probably confusing to do so | 10:42 |
| t1mp | because the visible acts different from the visible of other Items then | 10:42 |
| zsombi | t1mp: not really, because you'll document the property in the component, and will be RO | 10:43 |
| t1mp | I wonder whether you ever want to set Item's visible on Header | 10:46 |
| t1mp | so if the Header is part of a Page that is made not visible, qt changes the Header.visible to false as well | 10:46 |
| t1mp | zsombi: header.visible would basically mean header.y + header.height > 0 | 10:48 |
| t1mp | I'm thinking if there are cases where you want to use header.visible instead of header.height | 10:48 |
| zsombi | t1mp: so you don't want to go for cpp | 10:49 |
| t1mp | zsombi: no, not for now. Needs to be done next week ;) maybe later for performance, but I still think we should not override the visible property | 10:50 |
| zsombi | t1mp: the problem with overriding visible is that you won't be able to keep the prev visible with the new one... | 10:50 |
| zsombi | t1mp: but hidden is not really a good name | 10:50 |
| t1mp | hmm | 10:51 |
| t1mp | zsombi: this seems to work fine actually --- visible: header.y + header.height > 0 | 10:51 |
| t1mp | zsombi: so I can access the visible property if I need it | 10:52 |
| t1mp | and I use show() and hide() to animate the header in and out | 10:52 |
| t1mp | I'm not sure if the binding breaks when Header.parent.visible is set to false and then true again | 10:52 |
| zsombi | t1mp: so idf someone changes visible, you'll get the header in/out? | 10:52 |
| t1mp | zsombi: no, it is just the Item.visible, so no animation | 10:53 |
| t1mp | they must use show() and hide() | 10:53 |
| zsombi | t1mp: what binding? on the property not, as the paret change is controlled under the hood | 10:53 |
| t1mp | zsombi: if item.parent.visible is set to false, item.visible also becomes false | 10:54 |
| zsombi | t1mp: the problem is that if parent is hidden, and the header visible evaluates to true, teh Header will be shown/rendered | 10:54 |
| zsombi | t1mp: yes, it does, but that happens under the hood not thru setVisible() calls | 10:54 |
| t1mp | zsombi: hiding the parent will override the header.visible | 10:54 |
| zsombi | t1mp: check the source code, you'll see no setVisible() on child items when you set the poroperty | 10:55 |
| zsombi | t1mp: so child item bindings on visible won't get broken | 10:55 |
| t1mp | zsombi: ok, so then using Item.visible in Header would work fine as long as apps don't set Header.visible | 10:55 |
| zsombi | yep | 10:55 |
| zsombi | t1mp: but | 10:55 |
| zsombi | with visible you could change the shown/hidden animations without calling show() hide() | 10:56 |
| zsombi | t1mp: is there a use case when you need funcs to show/hide? | 10:56 |
| t1mp | zsombi: let's call Item.visible ivis and Header.visible hvis for now | 10:57 |
| t1mp | zsombi: you mean if I really need the function instead of setting hvis? | 10:57 |
| zsombi | t1mp: yes | 10:58 |
| t1mp | no, but using the functions and treating hvis as readonly avoid some issues with the binding | 10:58 |
| zsombi | t1mp: what issues? | 10:58 |
| t1mp | because setting hvis must show/hide the header, and scrolling a flickable may change the value of hvis again | 10:58 |
| zsombi | t1mp: and? | 10:59 |
| zsombi | t1mp: aaah, I remember now | 10:59 |
| zsombi | t1mp: when Header is hidden intentionally, scrolling should not bring it back | 10:59 |
| t1mp | zsombi: depends on header.locked | 11:00 |
| t1mp | internally I need the show() and hide() functions for sure | 11:00 |
| zsombi | t1mp: I'd rather use property than functions :( | 11:00 |
| t1mp | when you are scrolling and release the flickable when the header is half-shown, | 11:00 |
| t1mp | I need to call show() or hide() depending on the position of the header | 11:01 |
| t1mp | setting hvis won't help, because its value might not even change | 11:01 |
| t1mp | hvis would be true if only part of the header is visible | 11:01 |
| t1mp | but show() always opens the header completely. And hide() hides it completely | 11:01 |
| t1mp | ivis always must be true except if the header is completely hidden | 11:01 |
| zsombi | t1mp: yes, I remembered it | 11:02 |
| t1mp | we also have header.enabled == false when the header is not fully opened | 11:03 |
| t1mp | hmm | 11:04 |
| t1mp | I was thinking to use header.enabled = false to also hide the header, but maybe you don't want that as an app developer | 11:04 |
| t1mp | ok let's not mix the visibility with enabled | 11:04 |
| zsombi | t1mp: and even that is controlled under the hood by parent being disabled :) | 11:04 |
| t1mp | Header.active? | 11:05 |
| t1mp | header.active = false would animate the header out | 11:06 |
| t1mp | not super obvious | 11:06 |
| t1mp | Header.on | 11:06 |
| zsombi | t1mp: kalikiana: oppinnion pls> should we have multiple ActionContexts active the same time or not | 11:07 |
| t1mp | dialogs have open() and close() functions | 11:07 |
| t1mp | zsombi: yes | 11:08 |
| t1mp | I didn't check how you are doing ActionContexts, but could a Page have an ActionContext? | 11:08 |
| zsombi | t1mp: kalikiana: AdaptivePageLayout can have multiple pages open, so in that sense we should... unless AdaptivePage layout IS keeping the ActionContext and not the Pages.... | 11:08 |
| t1mp | then if you have multiple pages open (AdaptivePageLayout), you want all of those ActionContexts active | 11:08 |
| zsombi | t1mp: yes, that's the way it is now | 11:09 |
| t1mp | zsombi: yeah you could have one ActionContexts that contains the actions of all the pages, but that will get complicated | 11:09 |
| zsombi | t1mp: yes, it will | 11:09 |
| t1mp | when we had the unity action contexts, there was a global ActionContexts in the MainView, and local ActionContexts from the Pages | 11:09 |
| t1mp | the global one was always active, and the local ones depending on the active page | 11:09 |
| zsombi | t1mp: anyways, Actions get registered into the closest ActionContext found in th ehierarchy | 11:09 |
| zsombi | t1mp: we have 3 now :) | 11:09 |
| t1mp | 3? | 11:09 |
| t1mp | a global one and two pages? | 11:10 |
| zsombi | t1mp: we have sharedContext as well, which is always inactive | 11:10 |
| zsombi | t1mp: global, shared and local ones | 11:10 |
| t1mp | zsombi: I think the ActionContext will be easiest to use if multiple can be active at the same time | 11:10 |
| zsombi | t1mp: so all Action items you declare in MainView not under an ActionManager for instance will end up in sharedContext | 11:10 |
| zsombi | t1mp: we have the Dialog problem | 11:11 |
| t1mp | why is sharedContext not active? | 11:11 |
| t1mp | so in the Dialog you want only the Dialog's ActionContext active.. | 11:11 |
| zsombi | t1mp: because the actions in that context can be triggered only if they are used in active contexts | 11:11 |
| zsombi | t1mp: let's get back to shared a bit | 11:11 |
| zsombi | t1mp: so, you don't want an action in shared pool to get triggered no matter if those are used or not | 11:12 |
| t1mp | ahh, all actions are automatically added to a Context? | 11:13 |
| zsombi | t1mp: at least that's how I thought.... | 11:13 |
| zsombi | t1mp: we can get rid of the shared pool | 11:13 |
| zsombi | t1mp: each action keeps track of the contexts it was added | 11:13 |
| t1mp | I was thinking you have to put them in an ActionContext explicitly | 11:14 |
| t1mp | hmm | 11:14 |
| t1mp | instead of the sharedContext you could have the action by default in no context? | 11:14 |
| zsombi | t1mp: no, otherwise we'd have a pile of apps not working at all when we introduce this | 11:14 |
| t1mp | right | 11:14 |
| zsombi | t1mp: so I have to find a context for them | 11:14 |
| zsombi | but | 11:14 |
| zsombi | if I don't put the action anywhere, that may actually work | 11:15 |
| * zsombi thinks why it introduced shared context | 11:15 | |
| zsombi | t1mp: basically having no context or being in shared is the same | 11:15 |
| t1mp | yeah | 11:15 |
| zsombi | t1mp: but a bit simplier codewise | 11:15 |
| t1mp | maybe there was a sharedContext for listing them all in HUD | 11:16 |
| t1mp | I haven't seen the code, but probably I would prefer no context over a disabled sharedContext that is not used | 11:16 |
| zsombi | t1mp: fair enough!!! | 11:16 |
| * zsombi noted | 11:16 | |
| zsombi | t1mp: so, if an action is not registered in any context, it cannot be triggered | 11:17 |
| zsombi | t1mp: trigger() wont emit the signal | 11:17 |
| zsombi | neither shortcuts, hotkeys are going to work | 11:18 |
| zsombi | t1mp: but the action is still enabled | 11:18 |
| zsombi | t1mp: now, the wiestion is whether should it be enabled at all.... | 11:18 |
| zsombi | question | 11:18 |
| zsombi | t1mp: and there I am too, handling enabled under the hood... | 11:19 |
| zsombi | t1mp: so I need oppinion on that | 11:19 |
| kalikiana | zsombi: let's count, 1 context per visible page in each column, 1+ global context(s), 1 component-specific context(s), popover open that's not modal, makes 5 seems like a good average number | 11:22 |
| zsombi | kalikiana: you can have 2 pages active | 11:23 |
| zsombi | or even more | 11:23 |
| kalikiana | zsombi: see my calculation :-) | 11:23 |
| zsombi | kalikiana: yes | 11:23 |
| zsombi | kalikiana: all active | 11:23 |
| zsombi | kalikiana: then comes the Dialog | 11:23 |
| zsombi | t1mp: ^ | 11:23 |
| zsombi | kalikiana: t1mp: I have the "overlay" property for that | 11:23 |
| kalikiana | zsombi: the Dialog will disable all contexts, though | 11:23 |
| zsombi | there cannot be more than one overlay active at a time | 11:24 |
| zsombi | kalikiana: yes, that's what overlay is doing | 11:24 |
| kalikiana | zsombi: so "overlay" is looked up in the hierarchy of parents? | 11:24 |
| zsombi | kalikiana: the Action's isActive() checks whether there is an active overlay set, if yes, and the action does not belong to it, it won't trigger | 11:25 |
| kalikiana | zsombi: looking at the branch I don't see how a Dialog with multiple context would work at all | 11:27 |
| zsombi | kalikiana: right now I'm not looking up in the hierarchy, but that may make sense... | 11:28 |
| zsombi | kalikiana: yes, the Dialog's overlay basically disables all its child contexts too... so this needs more love | 11:28 |
| zsombi | kalikiana: perhaps a lookup in the hierarchy would be needed each time the action is activated | 11:29 |
| kalikiana | zsombi: I would expect that it acts more like a container. if Dialog is visible all of the contexts inside it are enabled, but nothing else | 11:30 |
| zsombi | kalikiana: yes, but somehow the other containers should be disabled in Dialog case | 11:31 |
| * zsombi thinks he will restart the work on this | 11:31 | |
| kalikiana | zsombi: might make sense to figure out at the same time as what happens to Action's declared with no explicit ActionContext | 11:33 |
| zsombi | kalikiana: see above discussion with t1mp | 11:33 |
| zsombi | kalikiana: so far it works the way that Action detects the actionContext property and if found, registers itself in that context | 11:34 |
| zsombi | kalikiana: if none found, it registers in a sharedContext, which we just discussed there's no reason to have, as it is disabled, and that means practically like not being registered anywhere | 11:35 |
| kalikiana | zsombi: so if I declare an Action will it be in the context of the page, or dialog respectively? | 11:35 |
| zsombi | kalikiana: if the Action is declared in teh Page, it will be in the Page's one, if in Dialog, it'll be in Dialog's | 11:36 |
| zsombi | kalikiana: if declared in MainView, it will be "orphan" | 11:36 |
| zsombi | kalikiana: those are the shareable actions | 11:36 |
| zsombi | kalikiana: so if added to Header actions, Header will have to register those to the context | 11:37 |
| kalikiana | zsombi: okay, so the immediate problem is that you may have declared actions globally for re-use and they will stop working | 11:37 |
| zsombi | kalikiana: I was thinking to somehow add this logic somewhere so we can apply it without any pain | 11:37 |
| kalikiana | zsombi: hmmm Header should work as if they are in the Page probably | 11:38 |
| zsombi | kalikiana: if an action si declared as global (ActionMaanger.actions are those) those will never stop working | 11:38 |
| kalikiana | zsombi: you just said they will stop working if declared outside of a Page | 11:39 |
| zsombi | kalikiana: yes, but the thing is that Header needs to do this per action, because Header doesn't know whether the actoins properties re locally declared or shared ones | 11:39 |
| zsombi | kalikiana: there are 3 types of actions: global, shared and local ones | 11:39 |
| zsombi | kalikiana: globals are registered in ActionManger's global context | 11:39 |
| zsombi | kalikiana: that is always active, thus it is active no matter of where are used | 11:39 |
| zsombi | kalikiana: the shared ones are declared in MainView or other common place, outside of any ActionManager | 11:40 |
| zsombi | kalikiana: local actions are declared in place if use | 11:40 |
| zsombi | kalikiana: like Button { action: Action {...} } | 11:40 |
| kalikiana | zsombi: so the shared actions are the ones that must be treated equally to global actions then, because otherwise they will silently stop working | 11:41 |
| zsombi | kalikiana: well, not | 11:41 |
| zsombi | kalikiana: if we follow the principle that an action is only active if in an active context, then not | 11:42 |
| zsombi | kalikiana: shared (orphan) actions are not in any context | 11:42 |
| zsombi | kalikiana: so then shared actions must be registered | 11:42 |
| zsombi | kalikiana: they become active when they are in an active context | 11:43 |
| kalikiana | zsombi: yet they work just fine right now | 11:44 |
| t1mp | zsombi: the "overlay" disables previous action contexts? | 11:44 |
| zsombi | kalikiana: because they trigger no matter if they are active or not | 11:44 |
| t1mp | zsombi: you could also have an ActionContext.exclusive property | 11:44 |
| kalikiana | zsombi: yes. and changing that will break them silently | 11:45 |
| zsombi | kalikiana: we were talking at some point that even the action triggering should not happen if it is not in an active context | 11:45 |
| t1mp | zsombi, kalikiana: I'm doing some header work, and it more and more looks like we should move Header inside the Page | 11:45 |
| t1mp | I think we can even do that in 1.3 without breaking APIs | 11:46 |
| kalikiana | zsombi: when I'm looking at existing code I'm not expecting a perfect world. I only care that apps already out in the wild still do their job :-) | 11:46 |
| zsombi | kalikiana: if we put ActionContexts in 1.2 toolkit, than they'll work | 11:48 |
| kalikiana | zsombi: I don't understand that sentence | 11:50 |
| kalikiana | can you phrase it differently? | 11:50 |
| zsombi | [14:41:26] <kalikiana> zsombi: so the shared actions are the ones that must be treated equally to global actions then, because otherwise they will silently stop working | 11:50 |
| zsombi | kalikiana: shared actions are used somewhere | 11:51 |
| zsombi | kalikiana: we have to update the components so they all register actions | 11:51 |
| zsombi | kalikiana: we can do that for 1.2 apps as well, actually we have to | 11:51 |
| t1mp | zsombi: so the actions see where they are declared and then add themselves to a context? | 11:52 |
| zsombi | t1mp: yes, they do | 11:52 |
| t1mp | zsombi: that can give problems if you use references to the actions somewhere else, right? | 11:52 |
| zsombi | t1mp: but like Header.actions can have shared actions | 11:52 |
| zsombi | yes | 11:52 |
| zsombi | t1mp: unless Header declares a context inside and add the actions to that context | 11:53 |
| t1mp | zsombi: for an ActionBar you can say actions: [ Action { id: ac1 }; Action { id; ac2 } ], or actions: [ac1, ac2] with ac1/2 defined somewhere else | 11:53 |
| zsombi | t1mp: like I did with Sections | 11:53 |
| kalikiana | zsombi: you defined shared actions as those that are neither in Page, Dialog nor MainView.actionManager | 11:53 |
| kalikiana | zsombi: how would we know where those are declared? | 11:53 |
| t1mp | I think in these cases the ActionBar or Sections needs to add the actions to a context | 11:53 |
| zsombi | kalikiana: you dont' know that | 11:53 |
| t1mp | zsombi, kalikiana: let's go to the hangout already, easier talking :) | 11:54 |
| zsombi | kalikiana: you have to add the action to the closest context | 11:54 |
| kalikiana | yeah, let's use the hangout | 11:54 |
| === _salem is now known as salem_ | ||
| nik90 | zsombi: Hi, You were right! Bug 1486008 turned out to be a device specific issue affecting only Nexus 4. | 12:18 |
| ubot5 | bug 1486008 in ubuntu-ui-toolkit (Ubuntu) "leading actions width is too small making it very difficult to press on Nexus 4 (mako)" [Undecided,Confirmed] https://launchpad.net/bugs/1486008 | 12:18 |
| zsombi | mzanetti: ^ | 12:18 |
| zsombi | nik90: thx | 12:18 |
| nik90 | I seriously thought I was going paranoid about it :P | 12:19 |
| tsdgeos | zsombi: he is off today | 12:20 |
| * tsdgeos goes for late lunch | 12:20 | |
| zsombi | nik90: LOL | 12:21 |
| kenvandine | zsombi, i don't see how creating a ContentStore object could alter the APP_ID | 12:39 |
| kenvandine | it's a simple object with a couple properties | 12:39 |
| kenvandine | it actually does nothing | 12:39 |
| zsombi | kenvandine: then I hav eno idea what can be the problem... | 12:40 |
| kenvandine | zsombi, yeah, it makes no sense | 12:41 |
| seb128 | kenvandine, zsombi, should be easy to reproduce and poke a bit no? | 12:43 |
| kenvandine | cuc::Store{QStandardPaths::writableLocation(QStandardPaths::PicturesLocation) | 12:46 |
| kenvandine | that's all that happens in creating a store | 12:46 |
| kenvandine | zsombi, any chance use QStandardPaths messes something up? | 12:46 |
| kenvandine | actually for the app scope it does this | 12:47 |
| kenvandine | new cuc::Store{QStandardPaths::writableLocation(QStandardPaths::DataLocation) | 12:47 |
| zsombi | kenvandine: not that I know of... | 12:47 |
| kenvandine | writableLocation does need the appId to create the path | 12:47 |
| kenvandine | but that's all internal in qt | 12:48 |
| kenvandine | that's literally all that's done in creating the scope | 12:48 |
| zsombi | kenvandine: none of the standard paths need the app name, the QSettings does need that | 12:48 |
| kenvandine | whoops, store | 12:48 |
| zsombi | kenvandine: and we use that to store the properties | 12:48 |
| kenvandine | it does | 12:48 |
| kenvandine | that creates a path like ~/.local/share/appId/ | 12:48 |
| kenvandine | not creates, uses | 12:48 |
| kenvandine | oh you're right... how does it get the appid in there | 12:49 |
| kenvandine | never mind... it doesn't | 12:49 |
| kenvandine | ~/.local/share | 12:49 |
| kenvandine | it's rather simple | 12:49 |
| kenvandine | so if that's causing the appId to get changed, it QStandardPaths doing it | 12:50 |
| kenvandine | which i doubt | 12:50 |
| seb128 | get a simple example and print the value before/after? | 12:50 |
| seb128 | I can do that if you want | 12:51 |
| kenvandine | zsombi, how did you figure out the appId changed? | 12:51 |
| kenvandine | i figured someone had done that | 12:51 |
| zsombi | kenvandine: StateSaver not restoring the state can only happen if the state file is not found; state file nam euses app name | 12:51 |
| kenvandine | lets try to debug it with didrocks example | 12:52 |
| kenvandine | i've never used the StateSaver before myself | 12:52 |
| zsombi | kenvandine: so if the ContentStore is missing, the states are restored, otherwise not, my first guess was the app name | 12:53 |
| kenvandine | i know messaging-app uses it, i would have thought this would have broken an app like that | 12:53 |
| zsombi | right | 12:53 |
| didrocks | do they use a ContentStore? | 12:53 |
| kenvandine | maybe not... | 12:53 |
| zsombi | they use ContentHub | 12:53 |
| kenvandine | they do use ContentHub | 12:54 |
| didrocks | zsombi: yeah, but you don't have to use the ContentStore necessarily5~ | 12:54 |
| didrocks | and contentHub itself is fine | 12:54 |
| kenvandine | i really don't have time to debug this today though, i'm rather swamp cramming to get stuff done before the sprint | 12:54 |
| didrocks | $ grep -r ContentSt * | wc -l | 12:54 |
| didrocks | 0 | 12:54 |
| didrocks | in messaging app | 12:55 |
| kenvandine | instantiating a ContentStore is just the call to QStandardPaths::writableLocation | 12:55 |
| kenvandine | so it would have to be that | 12:55 |
| seb128 | easy to swap those | 12:55 |
| seb128 | I can have a try if you want | 12:55 |
| kenvandine | we could just add a ContentStore to an app that we know uses StateSaver | 12:56 |
| kenvandine | seb128, if you have time :) | 12:56 |
| seb128 | kenvandine, well, adding the ContentStore to an app that uses StateSaver isn't going to tell much, is it? | 12:56 |
| seb128 | it's going to tell you that it stops working | 12:56 |
| seb128 | then you are back at saying that it only call QStandardPaths::writableLocation | 12:57 |
| seb128 | no? | 12:57 |
| kenvandine | i guess | 12:57 |
| kenvandine | that call is done in libcontent-hub0 | 12:57 |
| t1mp | zsombi, kalikiana: Should we have a Title { property string text; property string subText" } property maybe? | 12:58 |
| kenvandine | so removing that would require a rebuild | 12:58 |
| t1mp | header contents will be easy then: Header { ActionBar { }; Title { }; ActionBar { }; Sections { } } | 12:58 |
| zsombi | t1mp: not a bad idea | 13:03 |
| zsombi | t1mp: it's just thi doesn't tell how the blocks will be laid out | 13:03 |
| seb128 | zsombi, is the statesaver a part of the process? where does it store the info? | 13:09 |
| seb128 | or is that a service? | 13:09 |
| zsombi | seb128: it is part of it, yes, and stores under XDG_RUNTIME_DIR | 13:10 |
| zsombi | seb128: uses QSettings | 13:10 |
| zsombi | seb128: a piece of code from StateSaver http://pastebin.ubuntu.com/12140892/ | 13:10 |
| zsombi | seb128: we are not using APP_ID though, we quesry the app name from QGuiApplication | 13:11 |
| seb128 | right | 13:11 |
| t1mp | zsombi: yeah, it doesn't tell how they are layed out because that would be a lot of code for one line in irc :) | 13:43 |
| t1mp | zsombi: so then I'm still not sure if the Header should have some default content, or the app developers have to put the stuff in there themselves | 13:44 |
| t1mp | zsombi: basically it will be Header { Row { Column { ActionBar{}; Title{}; ActionBar{}; }; Sections } } | 13:46 |
| t1mp | errr | 13:46 |
| t1mp | I mixed up the Row and Column | 13:46 |
| t1mp | we should have some default HeaderLayout | 13:48 |
| t1mp | putting the components is not so hard, but you also have to get all the margins etc right | 13:49 |
| seb128 | zsombi, kenvandine, do you know what that is/does | 13:55 |
| seb128 | QObject::connect(&QuickUtils::instance(), &QuickUtils::deactivated, | 13:55 |
| seb128 | this, &StateSaverBackend::initiateStateSaving); | 13:55 |
| seb128 | "QuickUtils::deactivated" | 13:55 |
| seb128 | zsombi, kenvandine, so, debugged a bit more, issue is that http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/plugin/statesaverbackend_p.cpp#L44 handle only SIG2/15 and not KILL=9, at least not with the UnixSignalHandler | 14:11 |
| seb128 | that callback triggers on SIGKILL though | 14:11 |
| seb128 | QObject::connect(&QuickUtils::instance(), &QuickUtils::deactivated, | 14:11 |
| seb128 | this, &StateSaverBackend::initiateStateSaving); | 14:11 |
| seb128 | but doesn't once ContentStore is used | 14:11 |
| seb128 | unsure how what that deactivated is and if it's normal to rely on it/why it stops triggering with content-hub | 14:11 |
| seb128 | but it's not an env/dir issue | 14:11 |
| kenvandine | weird | 14:12 |
| kenvandine | i'm not familiar with QuickUtils | 14:12 |
| seb128 | me neither | 14:12 |
| seb128 | but so the proper handlers work with ContentStore | 14:12 |
| kenvandine | so something must be disconnecting that? | 14:12 |
| seb128 | I guess | 14:12 |
| kalikiana | t1mp: is Title a Row { Label {} Label {} } in that case? what happens if you have head.contents? what happens if you have title in the Page? | 14:14 |
| kalikiana | or would this be only exposed if you manually use ActionBar? | 14:14 |
| t1mp | kalikiana: Title would be something like that, yes. Only a bit more complex because when you have a lot of space horizontally, the subtitle will go to the right of the title instead of under it | 14:15 |
| greyback | seb128: I think QuickUtils::deactivated is fired when the app moves from foreground to background - it indicates that the app should save state now, as it will be suspended shortly, and possibly killed | 14:15 |
| seb128 | greyback, kenvandine, is something in the sdk dealing with changing that in case of content-hub to avoid killing content hub "clients" in a transaction? | 14:16 |
| kalikiana | t1mp: hmm so more like a Flow. and not easy to replace. say for example an app needs custom coloring it's not as trivial to put labels in there | 14:16 |
| t1mp | kalikiana: I'd say the default header in a Page would be header: Header { HeaderLayout { title: page.title } } } | 14:16 |
| t1mp | kalikiana: it is getting a bit messy to put it here | 14:17 |
| t1mp | kalikiana: I'll try to work it out in the API doc https://docs.google.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# | 14:17 |
| greyback | seb128: nothing I'm aware of, but I'm no sdk expert | 14:17 |
| kenvandine | seb128, we do switch focus back to the requesting app, which would background the source app | 14:17 |
| kenvandine | but it sounds like it's not listening for that anymore | 14:18 |
| seb128 | kenvandine, well, doing the object instanciation shouldn't lead to anything like that though | 14:18 |
| kenvandine | getting disconnected from that signal | 14:18 |
| kenvandine | nope | 14:18 |
| kenvandine | but | 14:18 |
| kenvandine | it wouldn't save the state until it gets that deactivated signal | 14:18 |
| kalikiana | t1mp: oh, I need to look at that one. sorry, even in just 2 days off my inbox gets so full :-/ | 14:19 |
| kenvandine | so when it goes back to the background it should still get that | 14:19 |
| t1mp | kalikiana: it is still very much work in progress | 14:19 |
| t1mp | kalikiana: the HeaderLayoutStyle is tricky | 14:25 |
| t1mp | kalikiana: so the HeaderLayout will have ActionBar, Title, Sections | 14:25 |
| t1mp | kalikiana: all of their properties are defined in ActionBarStyle, TitleStyle (TODO), SectionsStyle | 14:25 |
| t1mp | should I somehow link to those from the HeaderLayoutStyle? | 14:26 |
| t1mp | zsombi: ^ | 14:26 |
| t1mp | faenil: how are you doing that with the ListItem layouts? | 14:26 |
| * faenil reads backlog | 14:26 | |
| t1mp | faenil: or are you not using other styled components inside the ListItem layouts? | 14:26 |
| faenil | nope, not styled | 14:27 |
| t1mp | faenil: to summarize, I'm thinking of APIs for the new new new Header in https://docs.google.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# | 14:27 |
| t1mp | faenil: ok.. maybe HeaderLayout is not the correct name then | 14:27 |
| t1mp | it is not just the layout, but the full contents | 14:27 |
| t1mp | HeaderContentsPreset maybe.. :s | 14:28 |
| faenil | mmm, don't know :/ | 14:28 |
| t1mp | good, I see more people are looking at the document | 14:28 |
| t1mp | everybody feel free to comment/suggest/ask questions. Now is the time. After we land it it becomes really difficult to change the API | 14:29 |
| t1mp | oh. After I ask for comments everybody closed the document.. ;) | 14:30 |
| t1mp | kalikiana: I can simply put the components that I want inside the HeaderLayout, and have aliases to them to expose them to the app developer | 14:31 |
| t1mp | but like that you'll have to set for example the actions like this: header.layout.trailingActionBar.actions: [ action1, action2 ] | 14:32 |
| t1mp | well I can add some more aliases so that header.trailingActions would work, but only in the default Header of the Page | 14:32 |
| t1mp | custom headers will need Page.header: Header { // all the contents } | 14:33 |
| t1mp | kalikiana: instead of the HeaderLayout we could also have a subclass of Header that has the contents | 14:42 |
| kalikiana | t1mp: I'm actually starting to think, if you're basically exposing some two dozen properties, why not make it one component. since otherwise the API is just a number of aliases to almost an entire component | 14:48 |
| faenil | +1 | 14:48 |
| t1mp | kalikiana: what do you mean? | 14:49 |
| t1mp | kalikiana: I have the Sections and ActionBar components | 14:49 |
| t1mp | kalikiana: those can now be used by themselves. And I like to re-use them in the Header | 14:49 |
| t1mp | kalikiana: so if I put them in one component, to expose its properties, that component will need to have all the aliases | 14:50 |
| t1mp | kalikiana: but, right. I don't like having so many aliases either... | 14:50 |
| kalikiana | t1mp: I mean that almost all of the alias seem to point tat the layout | 14:50 |
| kalikiana | at which point you could just use that | 14:50 |
| t1mp | kalikiana: but the layout has the subcomponents, | 14:51 |
| t1mp | kalikiana: so you have to say header.layout.leadingActionBar.actions: [] to set the leading actions | 14:51 |
| t1mp | that's clear, but ugly I think | 14:51 |
| t1mp | if there was a DefaultHeader that includes the subcomponents, instead of the HeaderLayout, it would be a bit shorter | 14:52 |
| t1mp | but still header.leadingActionBar.actions | 14:52 |
| t1mp | maybe it is not *that* bad ;) | 14:53 |
| kalikiana | t1mp: API-wise you're basicalling exposing a fake Header subclass through aliases | 14:53 |
| t1mp | yeah, right | 14:53 |
| t1mp | ah, so you meant to have the DefaultHeader which inherits from Header | 14:53 |
| t1mp | yes, maybe that's good | 14:53 |
| t1mp | or Header--> EmptyHeader, DefaultHeader --> Header | 14:54 |
| t1mp | meh | 14:54 |
| t1mp | DefaultHeader --> PageHeader? | 14:54 |
| kalikiana | hmm I get confused by terminology now | 14:54 |
| kalikiana | what is default? | 14:54 |
| t1mp | Header has no contents, but takes care of scrolling/showing/hiding/.. | 14:54 |
| t1mp | DefaultHeader: Header { ActionBar{}; Title{}; ActionBar{}; Sections{} } | 14:55 |
| t1mp | so DefaultHeader would replace Header { HeaderLayout{} } | 14:55 |
| t1mp | the naming is no good | 14:55 |
| t1mp | I'll update the doc | 14:56 |
| t1mp | kalikiana: ok the doc got better now :) | 14:56 |
| kenvandine | Elleo, do you have any thoughts on https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1485222 | 15:00 |
| ubot5 | Ubuntu bug 1485222 in ubuntu-ui-toolkit (Ubuntu) "Using ContentStore disables silently any StateSaver capability" [Undecided,New] | 15:00 |
| kalikiana | t1mp: will navigationActions become public? if not, where do you set them? | 15:01 |
| kalikiana | assuming Tabs gets replaced and there will be a new API for it | 15:01 |
| t1mp | kalikiana: yeah.. I'm still thinking about that one | 15:02 |
| t1mp | kalikiana: AdaptivePageLayout internally can determine for each page whether there should be a back button | 15:02 |
| t1mp | kalikiana: it would be nice if it can somehow set that for the page header, but only if the app developer doesn't give a custom back action | 15:02 |
| kalikiana | t1mp: should page.header.leadingActionBar.actions | 15:03 |
| t1mp | kalikiana: how does your sentence end? | 15:03 |
| kenvandine | zsombi, the hub client does have an event filter, but that would effect anything using the content-hub | 15:04 |
| kenvandine | http://bazaar.launchpad.net/~phablet-team/content-hub/trunk/view/head:/src/com/ubuntu/content/hub.cpp#L82 | 15:04 |
| kalikiana | t1mp: work with the header subclass? that would be one (awkward) way to set the navigation actions then. otherwise it'd have to be for example Page.navigationActions | 15:04 |
| t1mp | kalikiana: currently the headerstyle looks for some special properties that were attached by the AdaptivePageLayout, or PageStack/Tabs and then gets the action from there, if there is no backAction defined | 15:04 |
| kenvandine | zsombi, it's used so if an application needs to respond to a transfer request, and it's already running it calls the handler when activated | 15:04 |
| Elleo | kenvandine: my guess is it's the hub installing an event filter | 15:05 |
| kalikiana | t1mp: unlike the back action there is no new API for navigation actions | 15:05 |
| kenvandine | Elleo, but it only breaks with a ContentStore | 15:05 |
| Elleo | kenvandine: contentstore instantiates a hub object, and it looks like the hub install an event filter | 15:05 |
| kenvandine | not with anything else | 15:05 |
| kenvandine | yeah, but anything with a hub instance does that | 15:05 |
| kenvandine | not just a ContentStore | 15:05 |
| Elleo | kenvandine: oh, so this doesn't happen if you have other things? that's odd :/ | 15:05 |
| t1mp | kalikiana: right. It needs more thought. And also designs. I don't even know if only Actions will be enough, what if they need something completely different in the overflow panel on the left | 15:06 |
| kenvandine | didrocks said it works if you use the hub without a content store | 15:06 |
| Elleo | because the contentstore barely does anything | 15:06 |
| kenvandine | i know right? | 15:06 |
| kenvandine | it literally just calls QStandardPaths::writablePath | 15:06 |
| kalikiana | t1mp: yeah. you'd potentially want a property PageHeader.leadingPanel | 15:07 |
| Elleo | kenvandine: I'd suggest double checking that, the hub's event filter looks like it swallows QEvent::ApplicationDeactivate | 15:07 |
| kenvandine | yeah | 15:07 |
| Elleo | kenvandine: which from the bug report sounds like is the underlying issue | 15:07 |
| kenvandine | didrocks, are you sure it works without a ContentStore but using the content-hub? | 15:07 |
| didrocks | I'm sure, I did test that explicitely | 15:07 |
| kenvandine | return QObject::eventFilter(obj, event); | 15:07 |
| kenvandine | i'm thinking on deactive it should return that | 15:07 |
| didrocks | (and spent some extensive time to find the exact component failing it) | 15:08 |
| kalikiana | t1mp: which might be a component that uses list item layouts rather than just actions | 15:08 |
| kenvandine | didrocks, all very puzzling | 15:08 |
| kenvandine | it's like the simplest component we have :) | 15:08 |
| didrocks | I guess reading from the discussion here :p | 15:08 |
| kenvandine | with no logic | 15:08 |
| Elleo | kenvandine: yeah, that's what it does for all other events, was there some explicit reason for swallowing the deactivate signal though? | 15:08 |
| t1mp | kalikiana: I plan to add delegate and overflowDelegate properties to the ActionBar | 15:08 |
| kenvandine | Elleo, i don't think so | 15:08 |
| didrocks | but it's really easily reproduceable, like less than a minute to setup the example | 15:08 |
| didrocks | and seb128 confirmed :) | 15:09 |
| t1mp | kalikiana: that would solve custom panels, except if there need to be subtitles grouping the actions in the panel | 15:09 |
| kenvandine | Elleo, but it does check for that explicitly | 15:09 |
| * kenvandine wonders why | 15:09 | |
| kenvandine | didrocks, yeah, thanks to seb128's debugging we found it's not getting this signal | 15:10 |
| kenvandine | that was super helpful | 15:10 |
| t1mp | kalikiana: so, page.header.leadingActionBar.overflowDelegate can then be used to change the looks of the leading panel | 15:10 |
| kenvandine | but now i'm thinking any hub client should fail to save state... | 15:10 |
| kenvandine | this has nothing to do with ContentStore | 15:10 |
| kenvandine | anything with a hub instance | 15:10 |
| didrocks | however, they do work in my case (I really just disabled this component) | 15:10 |
| didrocks | like, commenting only that | 15:10 |
| kenvandine | Elleo, i probably shouldn't be returning true there even on activated | 15:11 |
| didrocks | and not the whole ContentHub other's components | 15:11 |
| kenvandine | just HandlerActive and move on | 15:11 |
| kenvandine | didrocks, i'll get a build of the hub with this not swallowing the event | 15:11 |
| didrocks | would be an interesting data point | 15:12 |
| t1mp | kalikiana: for even more custom panels, they don't have to use the PageHeader, but they can use an empty Header where they put their own buttons and panels | 15:12 |
| Elleo | kenvandine: well maybe you should be calling Object::eventFilter on activated as well unless it's deliberately not wanting to do anything from the QObject event handler there? | 15:12 |
| kenvandine | Elleo, do you agree that i should just remove that return true when ApplicationActivate ? | 15:12 |
| t1mp | kalikiana: of course, more custom stuff will require more work for the apps | 15:12 |
| kenvandine | Elleo, so you do agree :) | 15:12 |
| kenvandine | i can just remove that return true | 15:12 |
| Elleo | kenvandine: yeah | 15:13 |
| kenvandine | and remove the deactivate too | 15:13 |
| kalikiana | t1mp: the main drawback would be to mimic the rest of the header, especially the title/subtitle which is getting more complex | 15:15 |
| t1mp | kalikiana: let me add the Title component to the doc :) | 15:15 |
| kalikiana | that wouldn't be very nice if it becomes common | 15:15 |
| kenvandine | https://code.launchpad.net/~ken-vandine/content-hub/dont_swallow_deactivate/+merge/268770 | 15:16 |
| kenvandine | we can test the debs from that | 15:16 |
| kalikiana | t1mp: on a side note, I'm intimidated by that penguin who is staring at me now hile I'm reading your doc | 15:17 |
| Elleo | kenvandine: okay, cool | 15:17 |
| Elleo | kenvandine: might it be worth keeping that warning? | 15:17 |
| t1mp | kalikiana: http://www.lowbyte.com/albums/2006-01-27-GaAquarium/web_PenguinStare_30_5037.sized.jpg | 15:17 |
| kalikiana | haha, that is not helping :-D | 15:18 |
| kalikiana | t1mp: so, even if Title is a component, I'm still not sure how you would place it. as soon as you don't use the ActionBar on the left you're forced to build all of the header | 15:19 |
| zsombi | [16:55:51] <seb128> zsombi, kenvandine, do you know what that is/does | 15:19 |
| zsombi | [16:55:52] <seb128> QObject::connect(&QuickUtils::instance(), &QuickUtils::deactivated, | 15:19 |
| zsombi | [16:55:52] <seb128> this, &StateSaverBackend::initiateStateSaving); | 15:19 |
| zsombi | [16:55:59] <seb128> "QuickUtils::deactivated" | 15:19 |
| zsombi | seb128: kenvandine: initiates state saving when teh app deactivates | 15:19 |
| zsombi | i.e. goes background | 15:19 |
| seb128 | zsombi, so when it's sigkilled nothing is saving state? | 15:19 |
| kalikiana | t1mp: ie since the type is leadingActionBar you need to have a custom component doing anchoring or other means to place all the components | 15:19 |
| t1mp | kalikiana: no, if the left actionbar has no actions it is invisible | 15:20 |
| kenvandine | zsombi, i think the hub client instance was swalling the deactivated signal | 15:20 |
| ogra_ | seb128, the sigkill comes from the kernels OOM killer ... | 15:20 |
| kenvandine | which means it wouldn't work with anything that uses the content-hub | 15:20 |
| ogra_ | you would have to inject the state saving in the kernel somehow for that | 15:20 |
| t1mp | kalikiana: PageHeader will position all its contents | 15:20 |
| seb128 | ogra_, right, but statehandler doesn't have an handler for 9, just for 2 and 15 | 15:20 |
| kenvandine | but didrocks says it does work | 15:20 |
| t1mp | kalikiana: I don't see the problem with that | 15:20 |
| zsombi | kenvandine: ahha.... QuikcUtils::deactivated comes when the application state changes... | 15:20 |
| kalikiana | t1mp: you're saying you would use PageHeader and put a DekkoPanel (made up the name) inside? how then do you know its size and margins? | 15:21 |
| t1mp | kalikiana: it will have two ActionBars, a Title, and a Sections. But the ActionBars and Sections will be invisible when they don't have contents | 15:21 |
| kenvandine | zsombi, i'm not sure my eventFilter is keeping you from seeing the signal though | 15:21 |
| kenvandine | https://code.launchpad.net/~ken-vandine/content-hub/dont_swallow_deactivate/+merge/268770 | 15:21 |
| kenvandine | zsombi, that's my attempt to fix it | 15:21 |
| kenvandine | but really, if that was eating it, it would eat it for all content-hub use | 15:21 |
| kenvandine | not just ContentStore | 15:21 |
| t1mp | kalikiana: right. If you want a completely custom panel like Dekko, then you have to use the empty Header and do all the layouting yourself. | 15:21 |
| t1mp | kalikiana: hold on, there is a way around that | 15:22 |
| kenvandine | seb128, the state should have been saved before it was killed | 15:22 |
| ogra_ | seb128, though i think we can assume that a foreground app doesnt get killed ... which means the state saver kicked in already when you de-focused it | 15:22 |
| zsombi | kenvandine: ahha, here you go: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/src/Ubuntu/Components/plugin/quickutils.cpp#L47 | 15:22 |
| kalikiana | t1mp: that is what I mean. and note I only want to replace the leading action bar in this example, nothing else. but I see no way to only replace that.. | 15:22 |
| t1mp | kalikiana: page.header.leadingActionBar.delegate: DekkoButton { onClicked: popups.open("DekkoPanel.qml") } | 15:23 |
| seb128 | ogra_, right, expect when you try on a desktop with xkill ;-) | 15:23 |
| ogra_ | desktops ... pfft :P | 15:23 |
| seb128 | ogra_, same on a phone in windows mode I guess | 15:23 |
| ogra_ | yeah, but there we turn off the lifecycle, dont we ? | 15:23 |
| kalikiana | t1mp: hmmm I didn't think of that. so that would allow you to have a special button as well as a panel easily. I like it | 15:24 |
| zsombi | ogra_: when an app goes background, it saves the states, yes | 15:24 |
| zsombi | I mean StateSaver does it | 15:24 |
| ogra_ | right | 15:24 |
| t1mp | kalikiana: ActionBar.delegate property still needs to be added, but we'll probably need that anyway | 15:25 |
| seb128 | kenvandine, didrocks, zsombi, similar problem if you add a ContentPeer isntead of a ContentStore | 15:25 |
| seb128 | so not specific to ContentStore | 15:26 |
| t1mp | kalikiana: I think I will need about 10 MRs to get all the new features in ;) | 15:26 |
| zsombi | seb128: so the event is consumed there too? (accepted) | 15:26 |
| Elleo | seb128: that's good, makes much more sense then :) | 15:26 |
| seb128 | yes | 15:26 |
| zsombi | :) | 15:26 |
| Elleo | zsombi: it's consumed by the main hub object, so anything that creates a hub object should cause this | 15:26 |
| zsombi | obviously | 15:26 |
| zsombi | t1mp: then go ahead with | 15:27 |
| zsombi | t1mp: are you trying to do similar layouting as for the ListItemLayout? | 15:27 |
| kenvandine | seb128, that makes sense then | 15:28 |
| kalikiana | t1mp: I can already picture a certain someone going "is it ready" yet every week? ;-) | 15:28 |
| zsombi | kalikiana: evry designer will :D | 15:29 |
| zsombi | +e | 15:29 |
| kalikiana | t1mp: maybe the delegate isn't even that urgent, at least for now, as long as showing the custom overflow can be done by trigger from an action | 15:29 |
| kenvandine | seb128, didrocks: i just confirmed statesaving doesn't seem to be working in messaging-app anymore | 15:32 |
| t1mp | zsombi: I was trying, but after discussing with kalikiana above we thought it is simpler to have a Header without contents, and a PageHeader that includes the standard layout for the header | 15:32 |
| t1mp | kalikiana: you need the delegate, because the popover needs a reference to the button that it should be pointing to | 15:33 |
| seb128 | kenvandine, let's see what it does once your fix is built ;-) | 15:33 |
| t1mp | kalikiana: it cannot point to the Action | 15:33 |
| t1mp | kalikiana: adding the delegate is a small addition for the ActionBar | 15:33 |
| t1mp | zsombi: see https://docs.google.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# | 15:34 |
| kalikiana | t1mp: oh. I was sort of assuming an overflow that would cover the buttons anyway. but actually I can think of a ways where the design would require it depending on how it's shown | 15:34 |
| kalikiana | so that would indeed be needed | 15:34 |
| kenvandine | seb128, nevermind... the messaging-app statesaver support never landed | 15:35 |
| kenvandine | so that explains why that's not saving :) | 15:35 |
| seb128 | k, shame :-/ | 15:35 |
| seb128 | but yeah, the content hub issue only blocks saving when the app is swapped out | 15:36 |
| seb128 | the unix signal handler still work | 15:36 |
| t1mp | kalikiana: what do you mean with an overflow that would cover the buttons? | 15:36 |
| seb128 | which is what closing from the switcher or oom does | 15:36 |
| t1mp | kalikiana: ah, right.. | 15:36 |
| t1mp | kalikiana: got it. If the popup does not have a pointer pointing at the button then you don't need the delegate | 15:36 |
| kenvandine | seb128, right, but it should get the deactivate before that | 15:37 |
| seb128 | right | 15:37 |
| * t1mp gotta go. Feel free to comment on the API doc. | 15:38 | |
| kalikiana | t1mp: at least the current dekko opens it below the sections. but it could be they only do that because there's no otherway | 15:38 |
| t1mp | kalikiana: most of the stuff in dekko is custom, so I guess it is intended like that | 15:41 |
| kalikiana | t1mp: I'm not sure the header is. but anyway, a delegate would be good to have | 15:41 |
| * t1mp off now. Have a nice weekend :) | 15:46 | |
| t1mp | I guess I'll read comments on the API doc in the weekend ;) | 15:46 |
| nik90 | ahayzen, kenvandine: It seems the ghost shadow related to content-hub stuff is fixed in https://trello.com/c/qikMnVBM/2215-215-ubuntu-landing-017-qtmir-qtmir-gles-mzanetti and approved by QA :) | 16:21 |
| kenvandine | nik90, yup | 16:21 |
| ahayzen | \o/ | 16:21 |
| balloons | popey, can all those reboot branches be merged if they pass jenkins? | 17:07 |
| balloons | there's like 4 of them. IF you want / need them merged before the switch, I can manually do it. If you can wait, it'll just happen | 17:08 |
| popey | balloons: they'll need review. | 17:08 |
| balloons | ok, so I'll let them be | 17:08 |
| ahoneybun | rpadovani: ping | 17:46 |
| anna__ | hello there, I am having trouble with Linitan on all my Ubuntu pbuilders up and including to Vivid | 17:54 |
| anna__ | It says: Skipping dist/deb_dist/nuitka_0.5.14~pre9+ds-1_amd64.changes: Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) | 17:54 |
| anna__ | It seems though as the package libtimedate-perl is installed | 17:54 |
| anna__ | And it was working, sometimes for years, Quantal e.g. also stopped working | 17:55 |
| anna__ | with the same error, was there an update across the board that broke lintian through some missing dependency... help appreciated. I am nuitka upstream btw | 17:56 |
| rpadovani | ahoneybun, o/ | 17:58 |
| ahoneybun | not sure if this link will work: https://docs.google.com/document/d/12oQYdl5mFpaJZ4NxRT0D1fZbN2EkwtoIClx5cBZImFY/edit | 17:58 |
| ahoneybun | I'm about half way done | 17:58 |
| rpadovani | ahoneybun, you can't edit the original doc? Anyway, no, it says I don't have the permission... thanks for the help meanwhile :-) | 17:59 |
| ahoneybun | I see it | 17:59 |
| ahoneybun | I'm writing it side by side | 18:00 |
| ahoneybun | rpadovani: you may enter :) | 18:00 |
| rpadovani | ahoneybun, thanks so much :-) | 18:00 |
| ahoneybun | yep | 18:01 |
| ahoneybun | your english grammar is getting better | 18:01 |
| ahoneybun | your just confused with past, present and future | 18:01 |
| rpadovani | I live in a different spacetime, maybe? :-) | 18:02 |
| ahoneybun | timezone more likely lol | 18:03 |
| rpadovani | aha | 18:04 |
| nik90 | ahayzen: hey, do you mind testing my branch one last time, I am seeing some strange which I swear were working few hours back ;) | 18:05 |
| nik90 | ahayzen: once I get your everythign works fine signal, I will merge it | 18:06 |
| * nik90 grabs dinner quicky | 18:06 | |
| === javiercrowsoft1 is now known as javiercrowsoft | ||
| ahoneybun | rpadovani: I'll finish it at some point today lol | 18:53 |
| ahoneybun | if not tomorrow as a I have a long trip | 18:53 |
| rpadovani | ahoneybun, take your time, thanks :-) | 19:07 |
| ahayzen | nik90, i think its been merged already :-) but i can still double check things | 19:13 |
| nik90 | ahayzen: yeah I just noticed it now..sry. I am reflashing my phone clean to see if everything is okay. | 19:13 |
| nik90 | ahayzen: for some reason, I couldnt set a custom sound as the alarm sound. And I kept hitting the bug you had yesterday where you couldn't save an alarm. | 19:14 |
| ahayzen | interesting | 19:14 |
| ahayzen | anything in the logs ? | 19:14 |
| nik90 | ahayzen: although I did notice that indicator-sound just mysteriously died, and the logs showed line103 repeatedly as an error. | 19:14 |
| nik90 | I will investigate more | 19:14 |
| ahayzen | maybe pulse/mh dies or something? | 19:15 |
| nik90 | yes could be | 19:15 |
| nik90 | but that doesn't explain why I couldn | 19:15 |
| nik90 | I couldn't set a custom alarm sound though | 19:15 |
| nik90 | anyway I will start testing once the flashing is complete | 19:15 |
| nik90 | ahayzen: just noticed that we changed the default alarm tone which only lands in OTA-6. I am preparing a branch right now to be backwards compatible. | 20:59 |
| ahayzen | nik90, is that why it freezes ? | 21:00 |
| nik90 | ahayzen: I doubt it..since it was freezing previously for the alarm label and not the alarm sound name. | 21:00 |
| ahayzen | ah | 21:01 |
| nik90 | ahayzen: I am kind of cursing at QML FolderListModel at the moment...it introduces a race condition which causes another sound bug. I am fixing that as well. | 21:02 |
| ahayzen | ugh :-/ | 21:02 |
| nik90 | they don't have any property to indicate that the folderlistmodel has fully loaded | 21:02 |
| ahayzen | hah, more suggestions for them :-) | 21:02 |
| nik90 | so the onCompleted() signal is practically useless here and I have to rely on the count property to check if it is more than 0. | 21:03 |
| ahayzen | haha | 21:03 |
| nik90 | Do you guys use a Timer{} anywhere in the music app to wait for the music list to be fully loaded? | 21:03 |
| ahayzen | no but we do for other racy reasons :-) | 21:04 |
| nik90 | that's what I am doing at the moment. Waiting for 500ms atm before I do such checks. | 21:04 |
| nik90 | Although I want to see how low I can take that number | 21:04 |
| ahayzen | as our models are now ms2 models so they are loaded directly from that | 21:04 |
| nik90 | ah ok | 21:04 |
| ahayzen | nik90, we have this hacky timer :-) http://bazaar.launchpad.net/~music-app-dev/music-app/refactor/view/head:/app/ui/Playlists.qml#L64 | 21:05 |
| nik90 | ah ok.. | 21:05 |
| ahayzen | basically if you on a page that is created in a delegate and then that delegate is deleted (due to you reloading the model) it causes the page to freeze, so we have to delay reloads of the model until you've popped back to that page | 21:06 |
| vthompson | Does anyone know if it's possible to have an app change orientation with the screen, but when the screen is in landscape, have the app sidestage? I can't seem to get such a thing working. | 21:14 |
| === salem_ is now known as _salem | ||
| kivi | vthompson, good question | 21:18 |
| vthompson | nik90, I don't think allowing the app to both rotate and go into sidestage mode is supported. | 21:26 |
| vthompson | Looks like the unity8 guys talked about allowing sidestage->landscape mainstage transitions... not sure what the end decision was | 21:35 |
| vthompson | sorry, sidestage -> portrait mainstage | 21:35 |
| nik90 | vthompson: ah ok | 21:37 |
| nik90 | We can check with mzanetti on Monday to know about the end decision. | 21:38 |
| nik90 | vthompson: does the desktop file still support X-Canonical-SideStage key? That's what I remember seeing in the old clock app desktop file | 21:38 |
| nik90 | or is that overridden by the new portrait key we now include | 21:38 |
| vthompson | nik90, I was using X-Ubuntu-StageHint=SideStage | 21:39 |
| vthompson | It seems that the StageHint overrides the orientation | 21:40 |
| nik90 | yes that's the one..(i was trying to remember from memory) | 21:40 |
| nik90 | oh :/ | 21:40 |
| popey | vthompson: i think the whole sidestage stuff has taken a back seat until we have a tablet on the .. table | 22:09 |
| vthompson | popey, while I enjoy your pun. I do have a tablet on my table ;) | 22:13 |
| popey | :) | 22:14 |
| * popey ensleepens | 22:15 | |
| popey | Bon weekend all... | 22:15 |
| ahayzen | o/ | 22:15 |
| nik90 | o/ | 22:15 |
| === _salem is now known as salem_ | ||
| vthompson | o/ | 22:21 |
| === salem_ is now known as _salem | ||
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
