=== salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [07:34] Morning all [08:12] 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] Which package I need to install? [08:28] how do I list available click chroots from command line? [08:28] is it supposed to be done just via schroot -l ? [08:29] with sudo, yes [08:29] http://paste.ubuntu.com/12139782/ [08:34] thank you, right. it's a bit confusing there's click chroot create / destroy but no list [08:48] anyone seen dpm recently? trying to get a hold of him :) [08:49] 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] bug 1485222 in ubuntu-ui-toolkit (Ubuntu) "Using ContentStore disables silently any StateSaver capability" [Undecided,New] https://launchpad.net/bugs/1485222 [08:50] didrocks: well, I wrote the code... [08:51] 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] didrocks: I am surprised that it only appeared now... [08:51] zsombi: I can't tell you if that worked on vivid though, I didn't use the ContentStore back then [08:52] 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] didrocks: but as said, unless it is getting priority for OTA, I cannot do much [08:53] do we have a process for that, is that pinging Pat basically? [08:54] so, it does mean that any bug opened and not getting management priority for the sdk are never going to be fixed? [08:54] didrocks: also, but i also means that the bug is critical, meaning it blocks core apps from being released etc [08:54] didrocks: dude, noone said that, it's just not righ tnow [08:55] karni: he's on vacation this week and next, can I help? [08:56] 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:57] 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:58] karni: i haven't seen such an app [08:59] popey: okay, no prob :) cheers [09:00] 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] on this new machine I don't have the ecryptfs anymore, but I guess the mounts part is still somehow broken [10:16] zsombi: I cannot override Item's visible, so we need another property for Header.visible [10:17] I had "opened" for the toolbar before, but it doesn't seem like the perfect property name [10:23] for now I'll go with readonly property opened, and functions open() and close() [10:23] hmm [10:23] or readonly property hidden, and functions show() and hide() [10:36] t1mp: exposed? [10:37] 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] so there is a header but you don't see it [10:37] t1mp: that's opposite of visible, so not good [10:37] unless you scroll or call show() [10:38] zsombi: yeah, kind of the opposite.. maybe not 100% the opposite [10:38] zsombi: you are visible but you can still hide ;) [10:38] t1mp: uhm.. yoiu can be visible but hidden? [10:39] t1mp: well, visible and not exposed... almost the same [10:39] t1mp: flippedIn [10:41] zsombi: I could use visible: header.y + header.height > 0 [10:41] zsombi: but I cannot make that property readonly [10:41] t1mp: you cannot even override, it's final, ain't it? [10:41] yes [10:41] so developers can say visible = false and the header disappears, without the animation [10:42] t1mp: so you can only override it in cpp [10:42] even if I can override, it is probably confusing to do so [10:42] because the visible acts different from the visible of other Items then [10:43] t1mp: not really, because you'll document the property in the component, and will be RO [10:46] I wonder whether you ever want to set Item's visible on Header [10:46] so if the Header is part of a Page that is made not visible, qt changes the Header.visible to false as well [10:48] zsombi: header.visible would basically mean header.y + header.height > 0 [10:48] I'm thinking if there are cases where you want to use header.visible instead of header.height [10:49] t1mp: so you don't want to go for cpp [10:50] 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] t1mp: the problem with overriding visible is that you won't be able to keep the prev visible with the new one... [10:50] t1mp: but hidden is not really a good name [10:51] hmm [10:51] zsombi: this seems to work fine actually --- visible: header.y + header.height > 0 [10:52] zsombi: so I can access the visible property if I need it [10:52] and I use show() and hide() to animate the header in and out [10:52] I'm not sure if the binding breaks when Header.parent.visible is set to false and then true again [10:52] t1mp: so idf someone changes visible, you'll get the header in/out? [10:53] zsombi: no, it is just the Item.visible, so no animation [10:53] they must use show() and hide() [10:53] t1mp: what binding? on the property not, as the paret change is controlled under the hood [10:54] zsombi: if item.parent.visible is set to false, item.visible also becomes false [10:54] t1mp: the problem is that if parent is hidden, and the header visible evaluates to true, teh Header will be shown/rendered [10:54] t1mp: yes, it does, but that happens under the hood not thru setVisible() calls [10:54] zsombi: hiding the parent will override the header.visible [10:55] t1mp: check the source code, you'll see no setVisible() on child items when you set the poroperty [10:55] t1mp: so child item bindings on visible won't get broken [10:55] zsombi: ok, so then using Item.visible in Header would work fine as long as apps don't set Header.visible [10:55] yep [10:55] t1mp: but [10:56] with visible you could change the shown/hidden animations without calling show() hide() [10:56] t1mp: is there a use case when you need funcs to show/hide? [10:57] zsombi: let's call Item.visible ivis and Header.visible hvis for now [10:57] zsombi: you mean if I really need the function instead of setting hvis? [10:58] t1mp: yes [10:58] no, but using the functions and treating hvis as readonly avoid some issues with the binding [10:58] t1mp: what issues? [10:58] because setting hvis must show/hide the header, and scrolling a flickable may change the value of hvis again [10:59] t1mp: and? [10:59] t1mp: aaah, I remember now [10:59] t1mp: when Header is hidden intentionally, scrolling should not bring it back [11:00] zsombi: depends on header.locked [11:00] internally I need the show() and hide() functions for sure [11:00] t1mp: I'd rather use property than functions :( [11:00] when you are scrolling and release the flickable when the header is half-shown, [11:01] I need to call show() or hide() depending on the position of the header [11:01] setting hvis won't help, because its value might not even change [11:01] hvis would be true if only part of the header is visible [11:01] but show() always opens the header completely. And hide() hides it completely [11:01] ivis always must be true except if the header is completely hidden [11:02] t1mp: yes, I remembered it [11:03] we also have header.enabled == false when the header is not fully opened [11:04] hmm [11:04] 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] ok let's not mix the visibility with enabled [11:04] t1mp: and even that is controlled under the hood by parent being disabled :) [11:05] Header.active? [11:06] header.active = false would animate the header out [11:06] not super obvious [11:06] Header.on [11:07] t1mp: kalikiana: oppinnion pls> should we have multiple ActionContexts active the same time or not [11:07] dialogs have open() and close() functions [11:08] zsombi: yes [11:08] I didn't check how you are doing ActionContexts, but could a Page have an ActionContext? [11:08] 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] then if you have multiple pages open (AdaptivePageLayout), you want all of those ActionContexts active [11:09] t1mp: yes, that's the way it is now [11:09] zsombi: yeah you could have one ActionContexts that contains the actions of all the pages, but that will get complicated [11:09] t1mp: yes, it will [11:09] when we had the unity action contexts, there was a global ActionContexts in the MainView, and local ActionContexts from the Pages [11:09] the global one was always active, and the local ones depending on the active page [11:09] t1mp: anyways, Actions get registered into the closest ActionContext found in th ehierarchy [11:09] t1mp: we have 3 now :) [11:09] 3? [11:10] a global one and two pages? [11:10] t1mp: we have sharedContext as well, which is always inactive [11:10] t1mp: global, shared and local ones [11:10] zsombi: I think the ActionContext will be easiest to use if multiple can be active at the same time [11:10] t1mp: so all Action items you declare in MainView not under an ActionManager for instance will end up in sharedContext [11:11] t1mp: we have the Dialog problem [11:11] why is sharedContext not active? [11:11] so in the Dialog you want only the Dialog's ActionContext active.. [11:11] t1mp: because the actions in that context can be triggered only if they are used in active contexts [11:11] t1mp: let's get back to shared a bit [11:12] t1mp: so, you don't want an action in shared pool to get triggered no matter if those are used or not [11:13] ahh, all actions are automatically added to a Context? [11:13] t1mp: at least that's how I thought.... [11:13] t1mp: we can get rid of the shared pool [11:13] t1mp: each action keeps track of the contexts it was added [11:14] I was thinking you have to put them in an ActionContext explicitly [11:14] hmm [11:14] instead of the sharedContext you could have the action by default in no context? [11:14] t1mp: no, otherwise we'd have a pile of apps not working at all when we introduce this [11:14] right [11:14] t1mp: so I have to find a context for them [11:14] but [11:15] if I don't put the action anywhere, that may actually work [11:15] * zsombi thinks why it introduced shared context [11:15] t1mp: basically having no context or being in shared is the same [11:15] yeah [11:15] t1mp: but a bit simplier codewise [11:16] maybe there was a sharedContext for listing them all in HUD [11:16] I haven't seen the code, but probably I would prefer no context over a disabled sharedContext that is not used [11:16] t1mp: fair enough!!! [11:16] * zsombi noted [11:17] t1mp: so, if an action is not registered in any context, it cannot be triggered [11:17] t1mp: trigger() wont emit the signal [11:18] neither shortcuts, hotkeys are going to work [11:18] t1mp: but the action is still enabled [11:18] t1mp: now, the wiestion is whether should it be enabled at all.... [11:18] question [11:19] t1mp: and there I am too, handling enabled under the hood... [11:19] t1mp: so I need oppinion on that [11:22] 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:23] kalikiana: you can have 2 pages active [11:23] or even more [11:23] zsombi: see my calculation :-) [11:23] kalikiana: yes [11:23] kalikiana: all active [11:23] kalikiana: then comes the Dialog [11:23] t1mp: ^ [11:23] kalikiana: t1mp: I have the "overlay" property for that [11:23] zsombi: the Dialog will disable all contexts, though [11:24] there cannot be more than one overlay active at a time [11:24] kalikiana: yes, that's what overlay is doing [11:24] zsombi: so "overlay" is looked up in the hierarchy of parents? [11:25] 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:27] zsombi: looking at the branch I don't see how a Dialog with multiple context would work at all [11:28] kalikiana: right now I'm not looking up in the hierarchy, but that may make sense... [11:28] kalikiana: yes, the Dialog's overlay basically disables all its child contexts too... so this needs more love [11:29] kalikiana: perhaps a lookup in the hierarchy would be needed each time the action is activated [11:30] 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:31] 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:33] zsombi: might make sense to figure out at the same time as what happens to Action's declared with no explicit ActionContext [11:33] kalikiana: see above discussion with t1mp [11:34] kalikiana: so far it works the way that Action detects the actionContext property and if found, registers itself in that context [11:35] 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] zsombi: so if I declare an Action will it be in the context of the page, or dialog respectively? [11:36] 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] kalikiana: if declared in MainView, it will be "orphan" [11:36] kalikiana: those are the shareable actions [11:37] kalikiana: so if added to Header actions, Header will have to register those to the context [11:37] zsombi: okay, so the immediate problem is that you may have declared actions globally for re-use and they will stop working [11:37] kalikiana: I was thinking to somehow add this logic somewhere so we can apply it without any pain [11:38] zsombi: hmmm Header should work as if they are in the Page probably [11:38] kalikiana: if an action si declared as global (ActionMaanger.actions are those) those will never stop working [11:39] zsombi: you just said they will stop working if declared outside of a Page [11:39] 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] kalikiana: there are 3 types of actions: global, shared and local ones [11:39] kalikiana: globals are registered in ActionManger's global context [11:39] kalikiana: that is always active, thus it is active no matter of where are used [11:40] kalikiana: the shared ones are declared in MainView or other common place, outside of any ActionManager [11:40] kalikiana: local actions are declared in place if use [11:40] kalikiana: like Button { action: Action {...} } [11:41] 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] kalikiana: well, not [11:42] kalikiana: if we follow the principle that an action is only active if in an active context, then not [11:42] kalikiana: shared (orphan) actions are not in any context [11:42] kalikiana: so then shared actions must be registered [11:43] kalikiana: they become active when they are in an active context [11:44] zsombi: yet they work just fine right now [11:44] zsombi: the "overlay" disables previous action contexts? [11:44] kalikiana: because they trigger no matter if they are active or not [11:44] zsombi: you could also have an ActionContext.exclusive property [11:45] zsombi: yes. and changing that will break them silently [11:45] 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] zsombi, kalikiana: I'm doing some header work, and it more and more looks like we should move Header inside the Page [11:46] I think we can even do that in 1.3 without breaking APIs [11:46] 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:48] kalikiana: if we put ActionContexts in 1.2 toolkit, than they'll work [11:50] zsombi: I don't understand that sentence [11:50] can you phrase it differently? [11:50] [14:41:26] 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:51] kalikiana: shared actions are used somewhere [11:51] kalikiana: we have to update the components so they all register actions [11:51] kalikiana: we can do that for 1.2 apps as well, actually we have to [11:52] zsombi: so the actions see where they are declared and then add themselves to a context? [11:52] t1mp: yes, they do [11:52] zsombi: that can give problems if you use references to the actions somewhere else, right? [11:52] t1mp: but like Header.actions can have shared actions [11:52] yes [11:53] t1mp: unless Header declares a context inside and add the actions to that context [11:53] 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] t1mp: like I did with Sections [11:53] zsombi: you defined shared actions as those that are neither in Page, Dialog nor MainView.actionManager [11:53] zsombi: how would we know where those are declared? [11:53] I think in these cases the ActionBar or Sections needs to add the actions to a context [11:53] kalikiana: you dont' know that [11:54] zsombi, kalikiana: let's go to the hangout already, easier talking :) [11:54] kalikiana: you have to add the action to the closest context [11:54] yeah, let's use the hangout === _salem is now known as salem_ [12:18] zsombi: Hi, You were right! Bug 1486008 turned out to be a device specific issue affecting only Nexus 4. [12:18] 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] mzanetti: ^ [12:18] nik90: thx [12:19] I seriously thought I was going paranoid about it :P [12:20] zsombi: he is off today [12:20] * tsdgeos goes for late lunch [12:21] nik90: LOL [12:39] zsombi, i don't see how creating a ContentStore object could alter the APP_ID [12:39] it's a simple object with a couple properties [12:39] it actually does nothing [12:40] kenvandine: then I hav eno idea what can be the problem... [12:41] zsombi, yeah, it makes no sense [12:43] kenvandine, zsombi, should be easy to reproduce and poke a bit no? [12:46] cuc::Store{QStandardPaths::writableLocation(QStandardPaths::PicturesLocation) [12:46] that's all that happens in creating a store [12:46] zsombi, any chance use QStandardPaths messes something up? [12:47] actually for the app scope it does this [12:47] new cuc::Store{QStandardPaths::writableLocation(QStandardPaths::DataLocation) [12:47] kenvandine: not that I know of... [12:47] writableLocation does need the appId to create the path [12:48] but that's all internal in qt [12:48] that's literally all that's done in creating the scope [12:48] kenvandine: none of the standard paths need the app name, the QSettings does need that [12:48] whoops, store [12:48] kenvandine: and we use that to store the properties [12:48] it does [12:48] that creates a path like ~/.local/share/appId/ [12:48] not creates, uses [12:49] oh you're right... how does it get the appid in there [12:49] never mind... it doesn't [12:49] ~/.local/share [12:49] it's rather simple [12:50] so if that's causing the appId to get changed, it QStandardPaths doing it [12:50] which i doubt [12:50] get a simple example and print the value before/after? [12:51] I can do that if you want [12:51] zsombi, how did you figure out the appId changed? [12:51] i figured someone had done that [12:51] kenvandine: StateSaver not restoring the state can only happen if the state file is not found; state file nam euses app name [12:52] lets try to debug it with didrocks example [12:52] i've never used the StateSaver before myself [12:53] kenvandine: so if the ContentStore is missing, the states are restored, otherwise not, my first guess was the app name [12:53] i know messaging-app uses it, i would have thought this would have broken an app like that [12:53] right [12:53] do they use a ContentStore? [12:53] maybe not... [12:53] they use ContentHub [12:54] they do use ContentHub [12:54] zsombi: yeah, but you don't have to use the ContentStore necessarily5~ [12:54] and contentHub itself is fine [12:54] 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] $ grep -r ContentSt * | wc -l [12:54] 0 [12:55] in messaging app [12:55] instantiating a ContentStore is just the call to QStandardPaths::writableLocation [12:55] so it would have to be that [12:55] easy to swap those [12:55] I can have a try if you want [12:56] we could just add a ContentStore to an app that we know uses StateSaver [12:56] seb128, if you have time :) [12:56] kenvandine, well, adding the ContentStore to an app that uses StateSaver isn't going to tell much, is it? [12:56] it's going to tell you that it stops working [12:57] then you are back at saying that it only call QStandardPaths::writableLocation [12:57] no? [12:57] i guess [12:57] that call is done in libcontent-hub0 [12:58] zsombi, kalikiana: Should we have a Title { property string text; property string subText" } property maybe? [12:58] so removing that would require a rebuild [12:58] header contents will be easy then: Header { ActionBar { }; Title { }; ActionBar { }; Sections { } } [13:03] t1mp: not a bad idea [13:03] t1mp: it's just thi doesn't tell how the blocks will be laid out [13:09] zsombi, is the statesaver a part of the process? where does it store the info? [13:09] or is that a service? [13:10] seb128: it is part of it, yes, and stores under XDG_RUNTIME_DIR [13:10] seb128: uses QSettings [13:10] seb128: a piece of code from StateSaver http://pastebin.ubuntu.com/12140892/ [13:11] seb128: we are not using APP_ID though, we quesry the app name from QGuiApplication [13:11] right [13:43] 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:44] 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:46] zsombi: basically it will be Header { Row { Column { ActionBar{}; Title{}; ActionBar{}; }; Sections } } [13:46] errr [13:46] I mixed up the Row and Column [13:48] we should have some default HeaderLayout [13:49] putting the components is not so hard, but you also have to get all the margins etc right [13:55] zsombi, kenvandine, do you know what that is/does [13:55] QObject::connect(&QuickUtils::instance(), &QuickUtils::deactivated, [13:55] this, &StateSaverBackend::initiateStateSaving); [13:55] "QuickUtils::deactivated" [14:11] 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] that callback triggers on SIGKILL though [14:11] QObject::connect(&QuickUtils::instance(), &QuickUtils::deactivated, [14:11] this, &StateSaverBackend::initiateStateSaving); [14:11] but doesn't once ContentStore is used [14:11] unsure how what that deactivated is and if it's normal to rely on it/why it stops triggering with content-hub [14:11] but it's not an env/dir issue [14:12] weird [14:12] i'm not familiar with QuickUtils [14:12] me neither [14:12] but so the proper handlers work with ContentStore [14:12] so something must be disconnecting that? [14:12] I guess [14:14] 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] or would this be only exposed if you manually use ActionBar? [14:15] 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] 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:16] 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] 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] kalikiana: I'd say the default header in a Page would be header: Header { HeaderLayout { title: page.title } } } [14:17] kalikiana: it is getting a bit messy to put it here [14:17] kalikiana: I'll try to work it out in the API doc https://docs.google.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# [14:17] seb128: nothing I'm aware of, but I'm no sdk expert [14:17] seb128, we do switch focus back to the requesting app, which would background the source app [14:18] but it sounds like it's not listening for that anymore [14:18] kenvandine, well, doing the object instanciation shouldn't lead to anything like that though [14:18] getting disconnected from that signal [14:18] nope [14:18] but [14:18] it wouldn't save the state until it gets that deactivated signal [14:19] t1mp: oh, I need to look at that one. sorry, even in just 2 days off my inbox gets so full :-/ [14:19] so when it goes back to the background it should still get that [14:19] kalikiana: it is still very much work in progress [14:25] kalikiana: the HeaderLayoutStyle is tricky [14:25] kalikiana: so the HeaderLayout will have ActionBar, Title, Sections [14:25] kalikiana: all of their properties are defined in ActionBarStyle, TitleStyle (TODO), SectionsStyle [14:26] should I somehow link to those from the HeaderLayoutStyle? [14:26] zsombi: ^ [14:26] faenil: how are you doing that with the ListItem layouts? [14:26] * faenil reads backlog [14:26] faenil: or are you not using other styled components inside the ListItem layouts? [14:27] nope, not styled [14:27] 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] faenil: ok.. maybe HeaderLayout is not the correct name then [14:27] it is not just the layout, but the full contents [14:28] HeaderContentsPreset maybe.. :s [14:28] mmm, don't know :/ [14:28] good, I see more people are looking at the document [14:29] 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:30] oh. After I ask for comments everybody closed the document.. ;) [14:31] 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:32] but like that you'll have to set for example the actions like this: header.layout.trailingActionBar.actions: [ action1, action2 ] [14:32] well I can add some more aliases so that header.trailingActions would work, but only in the default Header of the Page [14:33] custom headers will need Page.header: Header { // all the contents } [14:42] kalikiana: instead of the HeaderLayout we could also have a subclass of Header that has the contents [14:48] 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] +1 [14:49] kalikiana: what do you mean? [14:49] kalikiana: I have the Sections and ActionBar components [14:49] kalikiana: those can now be used by themselves. And I like to re-use them in the Header [14:50] kalikiana: so if I put them in one component, to expose its properties, that component will need to have all the aliases [14:50] kalikiana: but, right. I don't like having so many aliases either... [14:50] t1mp: I mean that almost all of the alias seem to point tat the layout [14:50] at which point you could just use that [14:51] kalikiana: but the layout has the subcomponents, [14:51] kalikiana: so you have to say header.layout.leadingActionBar.actions: [] to set the leading actions [14:51] that's clear, but ugly I think [14:52] if there was a DefaultHeader that includes the subcomponents, instead of the HeaderLayout, it would be a bit shorter [14:52] but still header.leadingActionBar.actions [14:53] maybe it is not *that* bad ;) [14:53] t1mp: API-wise you're basicalling exposing a fake Header subclass through aliases [14:53] yeah, right [14:53] ah, so you meant to have the DefaultHeader which inherits from Header [14:53] yes, maybe that's good [14:54]