=== rsalveti_ is now known as rsalveti === broder_ is now known as broder === Pici` is now known as Pici === ubot5` is now known as ubot5 === rpadovani|Dota is now known as rpadovani [06:37] I defined a setting for my scope, when I read a string setting in English, it does not have any problem. However, when I read it by Chinese, I always get the default value. what is wrong? [07:27] oh noes [07:31] whats? [07:33] tsdgeos, all the conflicts :| [07:34] yeah :/ [07:34] tsdgeos, will need to have separate branches into rtm now [07:34] boooo [07:35] Saviq: well we don't have that many that have to end up there, no? [07:35] tsdgeos, yeah, it's not *that* bad, just that it's not as nice as it was yesterday ;) [07:35] yeah [07:39] hum [07:39] why is the launcher having white dots on the top-left of its icons now? [07:39] I guess it's wanted and not a bug? [07:39] Saviq, I'm now waiting on reviews for my sync-notification branches for unity8 and unity-notifications... while that's happening I'll check ted's two branches for the indicator-sound. [07:40] Saviq, or would you suggest I'll focus something else in the meantime? [07:40] seb128, yeah, it's a feature... those are the *pinned* apps [07:40] Saviq, I've only pinned apps, it looks weird ;-) [07:40] I though it would be something like that [07:40] MacSlow, no, that's good, let's preempt any issues [07:40] but I couldn't figure out what [07:40] Saviq, sweet [07:41] Saviq, not very elegant if you ask me :/ [07:41] seb128, we know [07:41] seb128, not our call [07:41] what is design thinking?! [07:41] seb128, it's a "we don't care" problem since there are only supposed to be pinned apps on the launcher soon [07:41] seb128, indeed... I wonder who complained about the cutt off edge... I liked that look [07:41] MacSlow, yeah, that was much better [07:41] seb128, but we need a way to pin them from the dash first [07:42] Saviq, k, no worry, I was just checking if that was a bug [07:42] I assumed it would be wanted [07:42] I just couldn't figure out what it means [07:42] Saviq, reminded me so much of the edges you fold into a current page of a book you're reading [07:42] and it's not looking good, but of well [07:42] * seb128 shakes fist at design [07:43] MacSlow, you could probably just delete https://code.launchpad.net/~macslow/unity-settings-daemon/max-volume-notification-warning/+merge/238180 [07:43] Saviq, done [07:43] tx [07:44] tsdgeos, are you out of reviews by any chance? [07:45] as if that could be the case these days :) [07:45] Saviq: i'm merging list_bottom_Edge thing and there's the expanded panel thing, but it seems everyone is doing that one now, so i could do something else if needed [07:45] tsdgeos, please review https://code.launchpad.net/~macslow/unity8/synchronous-notification/+merge/229059 then [07:46] ok [07:46] * Saviq resolves the panel for rtm situation the [07:46] n [08:06] MacSlow: do nothing with VALUE_TINT_HINT in https://code.launchpad.net/~macslow/unity-notifications/synchronous-notification/+merge/234476 ? [08:07] tsdgeos, yes... that branch is meant to make the new frontend feature known to any clients [08:08] tsdgeos, so an app can query the available notification-server capabilities and then decide what to use or not to use. [08:11] davmor2: so, I need a bit more info on the bug you filed [08:11] Wellark: really [08:12] davmor2: ? === shiznix_ is now known as shiznix [08:13] Wellark: what do you need dude? [08:13] davmor2: so, as I commented here https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1380736 [08:13] Ubuntu bug 1380736 in Network Menu "Unlocking sim while dash is not loaded leads to a system lockup" [Undecided,Incomplete] [08:13] I don't understand the "dash is empty" part [08:14] so, I'm suspecting that you actually ran this during the wizard, right? [08:14] when we don't have a full unity8 session running [08:14] and instead of the indicator getting you to the dash [08:14] it should return you to the wizard [08:15] MacSlow: have a few quick comments on https://code.launchpad.net/~macslow/unity8/synchronous-notification/+merge/229059 [08:15] tsdgeos, looking... [08:15] Wellark, dash is a separate process, if you unlock quickly it's not loaded yet (thus, empty) [08:18] Saviq: ok, please take a look at the bug. I think it's something that needs to be handled on unity8 side, as i-network just fires a snap decision [08:19] Wellark, yeah, most probably, just flashing [08:19] Wellark: so you install, you run the wizard, you run the touch guide, the dash is blank at this point and slowly fills up with all the apps if you unlock the first sim while this is the state of play it completely locks up the phone [08:20] Wellark: does that help you? [08:21] Wellark: jibel was also saying that you can get the same effect if you just re-run the wizard but I hadn't tried that [08:22] davmor2, I don't think the wizard is even relevant here, but was under the impression this is a unity8 crash, specifically the media hub related one, not the case for you? [08:23] Saviq: I'm going to do a fresh install shortly I'll let you know [08:23] Saviq: but I don't actually recall getting a crash from it [08:24] Saviq, davmor2: ok. I will let you guys figure it out and Mark the bug as Invalid for i-network [08:24] please, feel free to reopen it if something needs to be done on the i-network side [08:24] Wellark, kk [08:25] Wellark: will do [08:28] tsdgeos, addressed/replied to MP-comments [08:31] MacSlow: why would using the topMargin value not work? [08:32] tsdgeos, no idea [08:32] tsdgeos, but using shapedBack.topMargin makes any notification not appear [08:34] tsdgeos, maybe the conditional operator in the topMargin binding doesn't work for implicitHeight due to some QML-limitations [08:35] MacSlow: shapedBack.anchros.topMargin, no? [08:38] tsdgeos, doh... what a typo! sublime's QML-syntax-highlight/completion seems to be buggy... got it now working... updating branch [08:42] tsdgeos, branch updated is in... rev1106 [08:44] MacSlow: ok [08:45] tsdgeos, if you want to see the new sync. notifications in action, your best option is probably "make -C builddir tryNotifications" [08:48] MacSlow, looks like you brought something into that changeset https://code.launchpad.net/~macslow/unity8/synchronous-notification/+merge/238119 [08:49] MacSlow, prep a rtm-dedicated branch and resubmit please [08:51] Saviq, well the branch fixes... doing a new MP [08:52] MacSlow, I mean that the diff into trunk is 523 lines, into rtm it's 989 lines [08:53] MacSlow, meaning that you must've brought something from trunk (looks like translation changes) [08:53] Saviq, oh... hm [08:54] Saviq, probably a merge to trunk too much [08:54] merge with trunk rather [08:54] MacSlow, yup [09:07] Wellark, do you have an ETA on bug #1333121 ? [09:07] bug 1333121 in unity8 (Ubuntu RTM) "[SIM PIN] Unlock should be shown on boot" [Critical,Triaged] https://launchpad.net/bugs/1333121 [09:07] Saviq: today [09:07] landed by tomorrow EOD [09:08] hopefully today [09:08] Wellark, well, yeah, that's kind-a the deadline [09:08] but, needs quite some testing [09:08] Saviq: well, that's what DL's are for [09:08] right? ;)) [09:09] Wellark, I've a rtm-targeted silo (row 52, rtm silo 6) that I have all the unity8 and related fixes for 16/10 [09:09] Wellark, so let me know please when things should go in there [09:09] so, silos should be up and running by the end of today [09:09] Saviq: ok. [09:09] jeez compiz / unity is crashy in utopic lately [09:09] Saviq: so you want to have one big fat one? :) [09:09] brave man [09:09] Saviq: on unity8 side it's just a oneliner [09:10] or actually just uncommenting a oneliner [09:10] Saviq: I'll keep you posted [09:10] Wellark, it's not so fat, some 10 MPs in total [09:10] :D [09:11] Wellark, that's nothing ;) [09:11] Wellark, in any case, better to have it together, easier testing, less QA time etc. [09:11] "just a regular day at the office" [09:11] Saviq: true. [09:11] Saviq: I wish we could do such landings more [09:12] as you pointed out all of the benefits above :) [09:12] Wellark, *I* do those all the time [09:12] Saviq: <3 [09:12] Saviq: any free positions in your team? ;) [09:12] Wellark, we go up to 10 ACKed branches within a day [09:13] any other approach would just kill us [09:13] Saviq: tell me about it.. :) [09:13] ok. good. [09:13] as I said. I'll keep you posted [09:14] tkx === lool- is now known as lool [09:31] MacSlow, let me know please when you have the rtm-targeted branch [09:31] Saviq, just doing a final check locally [09:32] MacSlow, k [09:33] Saviq: fyi: the test failures in the notification branch only appeared after merging trunk [09:33] mzanetti, mhm [09:33] Saviq: and it seems now in trunk sufaces don't have activeFocus any more [09:33] mzanetti, uh? [09:33] Saviq: not sure if that's an issue, but if something goes wonky, that sounds like a candidate [09:33] Saviq: yeah, it still sets focus to true/false, but not any more activeFocus [09:34] mzanetti, hmm touchOwnership probably [09:34] sounds like we lost a focus scope's focus somewhere [09:35] Saviq: and did you only fix testShellWithOin? [09:35] Saviq, something with the top-margin spacing broke... looking into it [09:35] because testShell seems to have the same positioner issue [09:35] mzanetti, yeah, didn't look at testShell... [09:35] Saviq: will fix it in my branch then... or do you want a separate merge for that? [09:36] mzanetti, fine in yours [09:37] Saviq: will change the test to work with focus for now. but if you merge something that restores the activeFocus stuff, please either revert this test to use activeFocus, or let me know so I'll do it [09:38] mzanetti, please talk to Daniel when he comes on [09:38] kk [09:38] mzanetti, it sounds scary that they don't get activeFocus [09:51] Saviq, hm... that didn't work [09:51] MacSlow, what's going on? [09:52] Saviq, my bzr branch fu seems to be lacking today [09:52] Saviq, the diff just jumped to 2000+ lines [09:52] MacSlow, with bzr there's unfortunately not much you can do other than replaying your changes onto a clean branch [09:53] MacSlow, I'll take care of that [09:54] MacSlow, but yeah, uncommit the revert [09:54] MacSlow, we need a separate branch [09:56] MacSlow, you need to uncommit and push/overwrite [09:57] Saviq, just doing that [09:59] Saviq, done [10:00] Saviq, I'm turning back to Ted's branches now [10:09] MacSlow, can you `bzr push -d lp:~saviq/unity8/sync-notif-notrunk lp:~macslow/unity8/synchronous-notification --no-remember --overwrite` [10:09] MacSlow, I just replayed your commits without the trunk merge, which wasn't necessary [10:09] MacSlow, this way we won't need a separate branch [10:11] Saviq, hm... "bzr: ERROR: Cannot lock LockDir(chroot-91449488:///~saviq/unity8/sync-notif-notrunk/.bzr/branch/lock): Transport operation not possible: readonly transport" [10:11] MacSlow, that should be fine [10:11] MacSlow, actually no, bzr is stupid [10:11] MacSlow, please pull my branch down and push [10:13] Saviq, ok... now it should be in place [10:14] MacSlow, tx [10:14] MacSlow, yup, same diff, now, works! [10:14] Saviq, but still resubmit the proposal? [10:15] MacSlow, no, all is fine now [10:15] MacSlow, https://code.launchpad.net/~macslow/unity8/synchronous-notification [10:15] MacSlow, see the diff size reported is the same [10:16] Saviq, ah ok... I burry myself in the integration testing again [10:19] MacSlow, fwiw all of that is building for rtm in rtm silo 6 now [10:19] Saviq, 6 not 13 ?! [10:20] MacSlow, *rtm* [10:21] MacSlow, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-006 [10:21] mzanetti, you and your merge trunk pfft :P [10:22] ? [10:22] mzanetti, I need a branch of lp:~mzanetti/unity8/fix_snap_decision_test targetting rtm [10:22] targetting rtm [10:22] how come? [10:23] are we now merging to rtm and then syncing back? [10:23] mzanetti, the two diverged now [10:23] or do I need to propose branches against both? [10:23] mzanetti, both [10:23] so I need to different branches then [10:23] k [10:23] mzanetti, the ones that go into both need to go to both [10:23] mzanetti, yes [10:23] dandrader, mzanetti noticed that surfaces don't get activeFocus now [10:23] is that guy up already? [10:23] :) [10:23] dandrader, that expected? [10:24] mzanetti, it's already 7am there, what did you think! [10:24] that he should sleep for another 3 hours [10:25] Saviq, no [10:25] dandrader: just kidding... but yeah, seems activeFocus got lost [10:25] dandrader: it still sets focus to true/false, but not any more activeFocus [10:26] looks like we lost activeFocus somewhere up in the tree then [10:26] Saviq, just flashed krillin with devel-proposed and touchOwnership is not there [10:26] Saviq, did it go just to some rtm image? [10:26] dandrader, no, there might not be an image with it yet [10:26] dandrader, dist-upgrade [10:26] dandrader, it's not going into rtm yet [10:26] hmm [10:27] mzanetti, that's with unity8 trunk you built yourself? [10:28] yes [10:28] dandrader: ^ [10:28] mzanetti, it's possible that touchOwnership broke it as it moved the related code around, if I'm not mistaken [10:28] dandrader: I didn't really investigate, but I noticed with this branch: [10:28] mzanetti, although qmltests and manual should have detected that...... [10:28] lp:~mzanetti/unity8/fix_snap_decision_test [10:29] dandrader: yeah, the test in here did check for app.surface.activeFocus [10:29] dandrader: wasn't working any more after merging [10:29] dandrader, it looks like it doesn't have a user-visible impact [10:29] dandrader: now I changed it to work with focus, passes again [10:29] Saviq, mzanetti, right. the app just won't get key (button) presses anymore [10:30] oh right... forgot about that... well, that's not good then :) [10:30] actually it should not even make the vkb show up for then, iinm [10:31] mzanetti, I'll pull the branch from the rtm silo for now then [10:31] mzanetti, since we're not sure yet what the resolution will be [10:35] Saviq, what branch? [10:36] dandrader, the one mzanetti pointed at [10:38] Saviq: https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test-rtm/+merge/238274 [10:38] Saviq: I'll update both with activeFocus again once dandrader knows what way to go [10:39] mzanetti, k [10:57] MacSlow: why don't i see a volume notification? [10:58] tsdgeos, because the integration branches of indidcator-sound need to be in place and actually make use of the new sync. notification features [10:58] MacSlow: but those are marked as released, no? [10:58] tsdgeos, no [10:59] MacSlow: https://code.launchpad.net/~macslow/indicator-sound/synchronous-notification ? [10:59] tsdgeos, there are two indicator-sound branches from Ted dealing with that... and I'm currently reviewing/testing them [10:59] tsdgeos, that was reverted as it overlooked some desktop/phone difference and caused a bug on the desktop [11:00] MacSlow: well then can you update your MR [11:00] i'm trying to test the thing [11:00] and seeing nothing doesn't make me very confident in approving it [11:02] tsdgeos, your best bet to see something is to use http://bazaar.launchpad.net/~macslow/unity-notifications/synchronous-notification/view/head:/examples/icon-value.py on the phone [11:02] tsdgeos, I'm updating the MP-description [11:02] mhpf === dandrader_ is now known as dandrader [11:06] mzanetti, Saviq, just tested the released unity8 (trunk). surface.activeFocus is working as expected [11:06] tsdgeos, but the remark regarding the icon-value.py script was in the description already [11:07] sure [11:07] but that's cheating ;) [11:07] dandrader: weird... how come that test fails then? [11:07] MacSlow: i want to see the whole thing working [11:07] tsdgeos, no... not really... just forgot to delete the second part part of that sentence :) [11:07] tsdgeos, yeah me too... [11:08] tsdgeos, right now found some bugs in Ted's branches already and suggesting fixes... [11:09] mzanetti, add this http://paste.ubuntu.com/8558558/ to SessionContainer.qml and see for yourself [11:09] mzanetti, probably because the code that sets activeFocus moved to a different qml file, from SessionContainer or ApplicationWindow to SurfaceContainer [11:09] dandrader: no... the test does this: [11:10] Application *app = ApplicationManager.findApplication("foo") [11:10] compare(app.session.surface.activeFocus, true) [11:11] dandrader: so it doesn't use the qml stuff at all, goes the c++ path to find it [11:11] MacSlow: which package provides pynotify? [11:11] tsdgeos, that should be python-notify [11:11] mzanetti, is that failing in trunk? where is that test? [11:12] dandrader: merge this: https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test/+merge/238238 [11:12] dandrader: see line 184 of the diff [11:13] tsdgeos: do you still need the phone-right-edge ppa? [11:13] mzanetti: i guess you can kill it [11:13] ack, thanks [11:13] we'll do any bottom edge work next week in DC i guess [11:14] I'll push some stuff for vesa to test then [11:16] tsdgeos, did you get the icon-value.py to run? [11:17] MacSlow: yeah, i guess i'll have to be happy enough with that for the moemnt? [11:17] tsdgeos, yes... Ted's branches aren't ready for landing yet [11:18] tsdgeos, although I've them working to 75% here already [11:19] ok [11:19] i guess i can code approve and test approve with the example [11:19] and then give a final approve when we have everything ready? [11:20] Saviq: MacSlow: or we prefer to land this on our side asap and then hope for the best? [11:20] tsdgeos, certainly... app-integration should actually not be the responsibility of frontend and backend :) [11:21] ok [11:24] Hi guys. I have a serious issue with an app not starting randomly. App log is empty, tail -f /var/log/{messages,kernel,dmesg,syslog} output seems silent or not related, and unity8 log contains some hints http://paste.ubuntu.com/8558610/ [11:24] Could someone have a look at that? Would very much appreciate. [11:24] Hola [11:27] in the end, seems the app is crashing [11:32] tsdgeos, also, all that stuff's being built in rtm silo 6 [11:33] tsdgeos, so you can test there [11:33] Saviq: including ted's branches and sutff? [11:33] tsdgeos, yup [11:33] oki [11:33] will test it there then [11:33] Saviq, btw... I'm preparing some fix-suggestions for Ted's branches to make the work correctly with the sync. notifications [11:33] Saviq: how do i get the rtm silo 6? [11:33] MacSlow, yup, read that [11:33] Saviq, ah ok [11:34] is it even possible to install in a non rtm phone? [11:34] tsdgeos, flash rtm, `citrain device-upgrade 6 $password` [11:34] that's going to take a while :D [11:34] tsdgeos, no, but just flash your phone rtm, ubuntu-touch/ubuntu-rtm/14.09-proposed [11:34] tsdgeos, you need better internets ;) [11:34] i do [11:35] tsdgeos, what connection do you have? [11:35] MacSlow: a bad one :D [11:36] 10M i think [11:36] tsdgeos, consider yourself lucky... still about 50% faster than mine [11:37] tsdgeos, FWIW ubuntu-device-flash caches things, so once you download an image... unfortunately it does *not* use deltas [11:38] Saviq: i know i know [11:38] mzanetti, could you please rebase your rtm snap decision test on ~unity-team/unity8/rtm-sharedunitymenumodel, there's a conflict :| [11:39] are you just asking me always or are there so many conflicts? [11:39] mzanetti, it's the same one still [11:39] since 3 days I'm basically just rebasing stuff :D [11:39] mzanetti, it'd probably make sense to check if the trunk-targeted branches don't have the same issue [11:39] mzanetti, I'm really just asking the "newest" MP to rebase [11:39] oh no [11:40] mine were there before the kraken [11:40] but anyways, not complaining [11:40] just wondering [11:40] mzanetti, ah well, yeah, the kraken was special [11:40] mzanetti, and you were there at that point, Daniel wasn't I believe [11:44] Saviq: here you go: https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test-rtm/+merge/238282 [11:46] Saviq: regarding the comment about the notification mock. I think we'd need to clean up all the notification mock stuff. its way too hard to do something, also needs a c++ mock model to make SortFilterProxyModel work with it etc [11:46] Saviq: but I didn't want to do that in josh's branch really [11:51] mzanetti, yeah [11:51] k [11:54] Saviq: what provides citrain? [11:54] tsdgeos, phablet-tools-citrain [11:55] ah lol you have to run it on the pc [11:55] not on the phone :D === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch [11:58] Saviq: MacSlow: i tried that silo and still don't have any volume notificaiotn, is that known? [11:58] lunch! [11:58] tsdgeos, yeah, unity8 didn't build there yet [11:58] tsdgeos, yup it is [11:58] fighting... [11:59] Saviq, locally it's looking pretty good though... just to keep the spirits high :) [11:59] kk [12:01] mzanetti, commit message! 5 push-ups! [12:02] ack. just saw it [12:03] resubmitting shouldn't drop it [12:03] Saviq: one sec with the rebuild [12:06] Saviq: pushed the activeFocus stuff. now imo good to go [12:07] Saviq: turned out to be some local failure here :/. I reverted to activeFocus and added a waitForRendering() to get around the failure you had [12:15] mzanetti, ktx === _salem is now known as salem_ === dandrader|afk is now known as dandrader === MacSlow is now known as MacSlow|lunch [12:29] Saviq: something landed that broke the launcher :/ [12:30] Saviq: only on greeter though [12:30] "broke" is a hard word, but it's jumpy when dragging in [12:33] and: https://code.launchpad.net/~mzanetti/unity8/no-more-pinning/+merge/238290 [12:33] I'm checking with design if we need this in rtm [12:36] mzanetti, jumpy would suggest touch ownership again === alan_g|lunch is now known as alan_g [12:55] Saviq: one more: https://code.launchpad.net/~mzanetti/unity8/no-more-pinning/+merge/238292 [12:55] Saviq: vesar said its critical and reported a bug, so I guess this can go into rtm [12:56] uh oh [12:56] no, not like this :D [12:56] * mzanetti fixes [12:57] mzanetti, nope, not like this ;) [13:00] dandrader, there's an image now with touch ownership, revealing launcher over greeter is jumpy, are there two conflicting edge areas maybe? [13:01] Saviq: yeah, we're on it [13:01] Saviq, yes just flashed it and mzanetti already brought it to ma attention [13:01] Saviq: seems the greeter gets the onPressed event too and calls launcher.tease() while you're dragging it [13:02] k glad you're on it [13:03] Saviq: this one should be better now, however, LP fails to diff it still: https://code.launchpad.net/~mzanetti/unity8/no-more-pinning-rtm/+merge/238294 [13:03] * mzanetti is off for an hour [13:07] Saviq, kudos to design to reverting the white dot decision ;)- [13:07] ;-) [13:07] seb128, ]o/ [13:07] seb128, indeed [13:07] :-) [13:08] does anyone there know what could lead qml code to loose its translation domain? [13:08] seb128, loose != lose [13:09] ups [13:09] gallery does that [13:09] Loader { [13:09] ... [13:09] source: APP.pickModeEnabled ? Qt.resolvedUrl("PickerScreen.qml") : Qt.resolvedUrl("MainScreen.qml") [13:09] } [13:09] seb128, but... Connections { target: i18n; onDomainChanged: console.debug("AAAAAH LOST DOMAIN") } [13:09] the second case leads to a non translated UI [13:10] not sure why [13:10] seb128, huh... [13:10] adding that to MainScreen.qml workarounds it [13:10] Component.onCompleted: { [13:10] i18n.domain = "gallery-app"; [13:10] } [13:10] seb128, how does it set the domain in the first place? [13:10] with a ^ snippet [13:10] seb128, yeah, race [13:11] seb128, does it have a main()? [13:11] Saviq, http://bazaar.launchpad.net/~phablet-team/gallery-app/trunk/view/head:/rc/qml/GalleryApplication.qml#L192 [13:11] seb128, also, a Binding { target: i18n; property: "domain"; value: "gallery-app" } could be better [13:12] seb128, but basically what probably happens is that the picker gets loaded before the domain is bound [13:12] seb128, but what it should do is just use libintl.h [13:12] seb128, and set the domain in C++ [13:13] Saviq, it has a http://bazaar.launchpad.net/~phablet-team/gallery-app/trunk/view/head:/src/main.cpp [13:13] let me try if that works [13:14] Saviq, I don't know anything about gallery, just trying to help to get that issue resolved [13:14] seb128, best to probably just set it in C++ [13:14] trying that [13:14] Saviq, thanks [13:15] Saviq, I don't really get what could be racy in the Loader though, because the default UI is translated [13:15] seb128, the default UI is heavier [13:15] but if the source change then the newly pushed on isn't [13:15] seb128, so it loads later, after the domain has been set [13:15] oh [13:15] they both load at start? [13:15] seb128, no, just one does [13:15] seb128, but depending on which one [13:15] well then it doesn't make sense [13:15]