| === chihchun_afk is now known as chihchun | ||
| === john-mca` is now known as john-mcaleely | ||
| JamesTait | Good morning all! Happy Thursday, and happy Battery Day! 😃 | 09:58 |
|---|---|---|
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| kivi | bzoltan, zbenjamin So its been like a year, you gonna merge my patch into qtcreator? | 14:06 |
| kivi | lp:~akiva/qtcreator-plugin-autopilot/added-copyright-license-header | 14:06 |
| ahayzen | timp, Hey, i've reported bug 1547038 (about the tabbar issues) when building the mini-app it only started happening after i had made a the sidebar a Page with the PageHeader as well i think | 14:22 |
| ubot5 | bug 1547038 in ubuntu-ui-toolkit (Ubuntu) "Tabs with PageHeader, a sidebar with PageHeader and multirotation makes the old tab header appear" [Undecided,New] https://launchpad.net/bugs/1547038 | 14:22 |
| ahayzen | timp, i'll see if i can get it any further, but any pointers to even a workaround would be useful, as it would be nice not to have the issue in the MWC demos | 14:22 |
| ahayzen | timp, also note i haven't been able to reproduce on the desktop when using the latest UITK trunk branch | 14:26 |
| === BOHverkill is now known as BOHverkill___ | ||
| timp | ahayzen: ideally, don't use PageStack and Tabs any more. But that probably is a too big change to make now. | 14:54 |
| timp | ahayzen: thanks for reporting the bug | 14:54 |
| ahayzen | timp, what should we use? | 14:54 |
| timp | ahayzen: AdaptivePageLayout | 14:55 |
| timp | ahayzen: why is the sidebar a Page? | 14:55 |
| ahayzen | too many bugs ;-) | 14:55 |
| ahayzen | that gave me the header: thing | 14:55 |
| ahayzen | timp, or should i just be able to use an Item {} with a PageHeader on its own ? somehow | 14:55 |
| timp | yes, you can do that | 14:55 |
| ahayzen | i'll try doing that | 14:56 |
| timp | the Page simply puts the header on top of the other children. So you could have an Item where you add the PageHeader last, or set PageHeader.z | 14:56 |
| ahayzen | timp, also i've managed to style the bg of the PageHeader with StyleHints {backgroundColor: mainView.headerColor} ... can i also theme the leadingaction popover thing ? | 14:57 |
| ahayzen | timp, and that'll do the automatic slide in/out stuff as well? | 14:57 |
| ahayzen | (as you scroll the flickable) | 14:57 |
| ahayzen | i guess you link the PageHeader.flickable ? | 14:57 |
| timp | ahayzen: yes, if you set PageHeader.flickable it will slide in and out | 14:57 |
| timp | ahayzen: we don't have the overflow panel or its delegates exposed via the style now | 15:00 |
| mhall119 | bzoltan: hey, for GSoC could somebody on your team mentor a student working with design team to fix UITK components? | 15:00 |
| ahayzen | timp, ah, shouldn't it match the style of the header background? though | 15:00 |
| timp | ahayzen: the header takes its default colors from the palette, and so does the overflow. So if you provide a custom palette for your app, all the colors should be updated. | 15:01 |
| timp | ahayzen: the new palette stuff is quite recent. I'm not sure if we have a tutorial for that | 15:02 |
| timp | zsombi: ^ do we have a tutorial for how to provide a custom palette for an app? | 15:02 |
| zsombi | timp: we have something in the theming tutorial | 15:02 |
| zsombi | timp: which, lik eeverything else in d-u-c is burried in the void | 15:02 |
| timp | zsombi: maybe it is time for a new blog post about the palette :) | 15:03 |
| timp | zsombi: I plan to work on a new header blogpost next week | 15:03 |
| ahayzen | timp, hmm we have just set the theme | 15:04 |
| zsombi | timp: well, sure... I was about to have one, but first we'd need something in theming, which would choose the palette valueset based on some state of the component | 15:04 |
| ahayzen | styling is something we need to redo :-) | 15:05 |
| zsombi | ahayzen: styling? | 15:05 |
| ahayzen | colours/themes :-) | 15:05 |
| zsombi | ahayzen: waiting for clarification/suggestions :) | 15:06 |
| ahayzen | some are fixed some are referencing at QtObject with values lol | 15:06 |
| ahayzen | we were waiting for the sdk to have proper things :-) | 15:06 |
| zsombi | like? | 15:06 |
| zsombi | ahayzen: could you be less criptic please :) | 15:06 |
| tedg | popey: I got alecu stuck on Don't Crash. ;-) | 15:06 |
| popey | haha | 15:06 |
| ahayzen | zsombi, well just colouring things like buttons, header bars etc currently is done very badly in the music-app | 15:07 |
| ahayzen | something like StyleHints {} and the Theming stuff looks good though | 15:07 |
| zsombi | ahayzen: I see... we're trying to land a pretty big change on that front :) | 15:07 |
| ahayzen | we just haven't updated it yet | 15:07 |
| ahayzen | as we were waiting for your stuff to land :-) | 15:08 |
| ahayzen | timp, i think removing that Page thing, has fixed the issue! | 15:08 |
| zsombi | ahayzen: ok, so you know then about the biiiiig palette update, right? | 15:08 |
| ahayzen | i remember hearing about something | 15:08 |
| timp | ahayzen: great. Can you comment that you have the workaround on the bug report, I'll make it Medium importance then. | 15:08 |
| zsombi | ahayzen: ok, so let me spoil some stuff ;) | 15:09 |
| * ahayzen has been playing about with http://doc.qt.io/qt-5/qtquickcontrolsstyles-index.html as well recently | 15:09 | |
| ahayzen | but that is for a different project | 15:09 |
| ahayzen | timp, awesome thanks, so it seems the second Page confuses things somehow :-) thanks for your advice | 15:09 |
| zsombi | ahayzen: so, palette will have now all together 5 valuesets | 15:09 |
| zsombi | ahayzen: in addition, the palette layering is much more granular than it used to be | 15:10 |
| ahayzen | woooo \o/ | 15:10 |
| ahayzen | zsombi, when is it planned for? | 15:10 |
| ahayzen | UITK1.4 or something? ;-) | 15:10 |
| timp | (drumroll....) | 15:11 |
| timp | ok, if zsombi doesn't answer ;) in UITK 1.3 OTA10 | 15:12 |
| zsombi | ahayzen: like background and base text has sublayers, secondary and tertiary ones, then we have raised, which is in between foreground and overlay, negative, positive notion, activity, etc | 15:12 |
| ahayzen | hehe | 15:12 |
| ahayzen | zsombi, sounds awesome :-) | 15:12 |
| zsombi | ahayzen: timp: I was trying to type... you restless minds... :D | 15:13 |
| ahayzen | timp, one other thing i'm having issues with the PageHeader is, when i hit my search action it doesn't focus the TextField even though i have things like forceActiveFocus() | 15:13 |
| zsombi | ahayzen: then the Palette has normal, selected, inactive, selectedInactive and highlighted value sets | 15:13 |
| ahayzen | zsombi, i look forward to it :-) | 15:13 |
| zsombi | ahayzen: this is one step... we need to add a way for a styled item to get the appropriate palette value for a given state, i.e. normal, selected, inactive, highlighted | 15:14 |
| timp | ahayzen: hmm, that issue sounds vaguely familiar. But I haven't worked on focus.. | 15:15 |
| timp | kalikiana: ^ do you know if we have a bug for that? (TextField in PageHeader does not focus even with forceActiveFocus()) | 15:15 |
| ahayzen | timp, ok :-) if it tap the TextField, then press back and the action again, *then* it works | 15:15 |
| ahayzen | timp, where should the forceActiveFocus() be? i tried putting it in the onVisible and onStateChanged | 15:16 |
| timp | ahayzen: I don't know, that's why I asked kalikiana if he knows more :) | 15:25 |
| ahayzen | :-) | 15:25 |
| kalikiana | timp: ahayzen I'm trying to find the bug report... I hit a problem with that as far as a year back and I know it was tracked... | 15:45 |
| ahayzen | kalikiana, for the PageHeader ? | 15:46 |
| ahayzen | it works with the old style headers | 15:46 |
| kalikiana | timp: ahayzen this was it https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1378231 | 15:46 |
| ubot5 | Launchpad bug 1378231 in ubuntu-ui-toolkit (Ubuntu Vivid) "Wrong focus appearance of TextField as head.contents" [Undecided,New] | 15:46 |
| ahayzen | that is head.contents, that one works :-) (and is what we were using before) | 15:47 |
| ahayzen | but i translated to using the PageHeader and now it doesn't work :-/ | 15:48 |
| kalikiana | ahayzen: so you're doing basically the same, new property? | 15:53 |
| ahayzen | kalikiana, it is basically exactly the same code just bound to Page.header instead of Page.head :-) | 15:54 |
| ahayzen | kalikiana, http://bazaar.launchpad.net/~ahayzen/music-app/convergence-tabs-with-sidebar-01/view/head:/app/components/HeadState/SearchHeadState.qml is our head state | 15:55 |
| kalikiana | ahayzen: what if you do .focus = true instead? have you tried that? | 15:57 |
| ahayzen | kalikiana, i'll try it :-) | 15:57 |
| ahayzen | kalikiana, and should it do it on the onVisible ? or the onStateChanged ? | 15:57 |
| ahayzen | timp, does the PageHeader have the ability to lock? or should i just unset the flickable ? | 15:58 |
| kalikiana | ahayzen: from how I read the code it'd be the same thing | 15:58 |
| ahayzen | yeah :-) that's what i thought | 15:59 |
| ahayzen | i was initially thinking something magical was happing before :-) | 15:59 |
| kalikiana | I'm wondering if some internal visible changes could be happening - considering the bug in the old API was never a bug in the Header, but in TextField, this one on the other hand is a bug in the PageHeader | 16:00 |
| kalikiana | (or that's my opinion so far anyway) | 16:01 |
| timp | ahayzen: yes, unset the flickable | 16:01 |
| ahayzen | timp, thanks :-) | 16:01 |
| ahayzen | kalikiana, ok so i can see the onVisible doesn't happen, and if i do it in the onStateChanged that fires, but nothing happens when it is set to true | 16:02 |
| kalikiana | so the focus however you do it wouldn't happen in the first place | 16:03 |
| ahayzen | kalikiana, i'm doing it on the onStateChanged as well | 16:04 |
| ahayzen | kalikiana, i can see the focus changing to true, but the keyboard is not raised | 16:04 |
| kalikiana | ahayzen: but the state changes in response to focus? how can that happen if visible doesn't trigger a signal? | 16:04 |
| ahayzen | kalikiana, no the state of the page, from 'default' to 'search' to then run the PageHeadState | 16:05 |
| kalikiana | ah, right, visible only affects default | 16:06 |
| kalikiana | Hmmm | 16:07 |
| timp | ahayzen: the PageHeadStates are not very flexible. With the PageHeader, you could accomplish it by having different instances of PageHeader, like this http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/examples/ubuntu-ui-toolkit-gallery/PageHeaders.qml | 16:07 |
| timp | dunno if that would help with the focus issue | 16:08 |
| ahayzen | timp, that's what we have :-) | 16:08 |
| timp | oh, okay :) | 16:08 |
| ahayzen | timp, we have a default page head state, search head state, multiselect etc | 16:08 |
| ahayzen | just when the search head state is 'selected' it runs the focus=true and forceActiveFocus() ... but the textfield doesn't actually focus and cause the keyboard to be raised :-/ | 16:09 |
| timp | ahayzen: is http://bazaar.launchpad.net/~ahayzen/music-app/convergence-tabs-with-sidebar-01/view/head:/app/components/HeadState/SearchHeadState.qml old or what you have now? | 16:09 |
| ahayzen | timp, latest i have in that branch | 16:09 |
| timp | ahayzen: ah, in http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/examples/ubuntu-ui-toolkit-gallery/PageHeaders.qml I don't use a state at all, I just replace the PageHeader. Of course you could do that with a state too. | 16:10 |
| ahayzen | timp, eg they are used here http://bazaar.launchpad.net/~ahayzen/music-app/convergence-tabs-with-sidebar-01/view/head:/app/ui/Albums.qml#L35 | 16:10 |
| === charles_ is now known as charles | ||
| === rickspencer3_ is now known as rickspencer3 | ||
| bzoltan | mhall119: I am sure that it can be arranged, yes | 17:57 |
| mhall119 | thanks bzoltan | 18:58 |
| bzoltan | mhall119: other... about the API control and docs. We have kicked off a project to finally sort out all the issues related to frameworks and APIs. We have a weekly call where we focus on technical issues and progress. One inmportant part of the story is how the API docs get published for the various frameworks and API provides. Do you want to join or delegate somebody to that work? | 19:00 |
| mhall119 | bzoltan: I will do the work needed on the developer.u.c side, what time are those calls? | 19:01 |
| bzoltan | mhall119: 9am for you on Wednesday | 19:02 |
| mhall119 | ok, do you need me every week, or just as the need arises? | 19:02 |
| bzoltan | mhall119: the idea so far is that eac API provider module (UITK, Oxide, Scopes, etc) will produce a [module]-[version].api file what will describe the API. Whenever an API is changing the version number of that API will be automatically bumped. API versions are not package or framework versions.. they are simple incremental labels of the API. Once an image (phone or desktop iso) is created these .api files will be collected and if any of the APIs | 19:06 |
| bzoltan | chnaged then a new framework will be registered. All these fully automatic. Once a framework is created the doc packages of the APIs un that framework will be collected and they should be published on the d.u.c under the freshly created framework category | 19:06 |
| bzoltan | mhall119: does it make sense? | 19:06 |
| mhall119 | I think so, so the .api file would correspond to a change in import version in QML? | 19:16 |
| mhall119 | Ubuntu.Components 1.3, 1.4, etc? | 19:16 |
| mhall119 | and the frameworks would still be 15.04.4, 15.04.4, etc | 19:17 |
| mhall119 | bzoltan: will there be any indication of what framework the existing overlay PPA is working on? | 19:18 |
| mhall119 | I assume we'll have a frozen stable framework label, and a moving target development framework label | 19:19 |
| mhall119 | or are we dropping the moving development frameworks and only creating stable ones? | 19:19 |
| bzoltan | mhall119: In case of QML APIs the .api file will correspond to a change in import _AND_ even on a lower level change. | 19:19 |
| bzoltan | mhall119: So if we add an extra property to a component and keep the 1.3 import version then the uitk-X.api will be bumped... even if the import version stays the same | 19:20 |
| bzoltan | mhall119: and yes, the Overay PPA will have a framework version too what will be the same as the last OTA's fw version as long an API provider does not pump its own API version and so forces the framework to bump too | 19:22 |
| bzoltan | mhall119: So in practice... imagine that we have released the OTA67 with the 15.04.44 framework (these versions should be and will be somehow in sync) ... we open the OTA68 development in the Overlay PPA with the same 15.04.44 framework... because the APIs are still the same. But when a new UITK version land in the Overlay PPA what implements a brand new component then the 15.04.45 fw will be created and that fw will collect the development | 19:24 |
| bzoltan | changes. | 19:24 |
| mhall119 | bzoltan: how can you keep the same import version when you add a new property? | 19:26 |
| mhall119 | what if an app uses that new property on a phone with the original version of the component? | 19:26 |
| bzoltan | mhall119: the same way how we keep it and how Qt keeps it. The import versions are not API versions neither framework versions. | 19:27 |
| mhall119 | bzoltan: ok, one problem with leaving the framework version unchanged after an OTA is that the website will import new API docs every day, but apply them to a supposedly frozen framework version | 19:27 |
| bzoltan | mhall119: that will be not possible... new property -> new uitk.api version -> new fw | 19:28 |
| mhall119 | bzoltan: so how does it work then, if my app calls Component.foo on a phone without that property | 19:28 |
| bzoltan | mhall119: well, that automatic importing is something what we need t work out to make it smart | 19:28 |
| bzoltan | mhall119: It is up to what fw the app is binded to | 19:28 |
| mhall119 | bzoltan: ok, so a new property will force the creation of a new framework, even if Ubuntu.Components stays on 1.3 | 19:29 |
| mhall119 | bzoltan: it sounds like maybe I should disable the automatic nightly imports of API docs, and go back to a manual trigger? | 19:30 |
| mhall119 | or make a dedicated "development" series that gets the nightly import, and then manually clone that when an OTA and framework are released | 19:31 |
| === salem_ is now known as _salem | ||
| bzoltan | mhall119: yes a new property will trigger a new framework | 20:07 |
| bzoltan | mhall119: yes, the development focus could be pulled in as often as we want and the released OTAs should have their own categories | 20:08 |
| mhall119 | bzoltan: ok, I'll switch gears to that then | 20:15 |
| bzoltan | mhall119: super, but let's chat sometimes on that Wednesday call, so we all understand each others plans :) | 20:16 |
| mhall119 | ok | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!