| tsdgeos | Saviq: ping | 08:45 |
|---|---|---|
| Saviq | tsdgeos, hey | 09:11 |
| tsdgeos | Saviq: do you think https://bugs.launchpad.net/dekko/+bug/1543744 may be a duplicate of the other "apps don't start on the launcher" bugs? | 09:12 |
| ubot5` | Launchpad bug 1543744 in unity8 (Ubuntu) "Dekko does not start when pushing unity launcher" [Undecided,New] | 09:12 |
| tsdgeos | Saviq: is there a way to know by checkin the logs? | 09:12 |
| Saviq | tsdgeos, yeah, likely | 09:21 |
| tsdgeos | Saviq: i guess we should duplicate it and mention it'll be fixed soon that he should reopen it if he can still reproduce | 09:21 |
| tsdgeos | what's the bug # to duplicate to? | 09:21 |
| Saviq | tsdgeos, yup | 09:21 |
| Saviq | sc | 09:22 |
| Saviq | bug #1541388 | 09:22 |
| ubot5` | bug 1541388 in Canonical System Image "Icons in launcher sometimes refuse to launch application" [Critical,Fix committed] https://launchpad.net/bugs/1541388 | 09:22 |
| tsdgeos | Saviq: this will be in 9.5 or 10? | 09:24 |
| Saviq | tsdgeos, 9.5 | 09:24 |
| === davidcalle_ is now known as davidcalle | ||
| === vrruiz_ is now known as rvr | ||
| tsdgeos | Saviq: i fixed https://code.launchpad.net/~aacid/unity8/dash_resizing_fixes/+merge/285453 | 10:16 |
| tsdgeos | good catch! | 10:16 |
| Saviq | tsdgeos, tx, test covers it? | 10:18 |
| Saviq | ah yeah | 10:19 |
| Saviq | just read | 10:19 |
| om26er | olx | 10:26 |
| om26er | woops, wrong window. | 10:27 |
| * greyback not feeling so good, taking the morning off. | 10:53 | |
| cimi | greyback, get better gerry! | 11:03 |
| tsdgeos | mzanetti: cimi: https://code.launchpad.net/~aacid/unity8/emblemInPreviews/+merge/286038 | 11:19 |
| mzanetti | cimi, can you please ^ | 11:19 |
| cimi | mzanetti, tsdgeos of course guys | 11:20 |
| mzanetti | dandrader, hey, do you have an idea what's going on with this? | 11:20 |
| mzanetti | I have added "property int buhuu: Screen.orientation" | 11:20 |
| cimi | tsdgeos, do I need to do it now? | 11:21 |
| cimi | tsdgeos, or after I finish the social cards? | 11:21 |
| mzanetti | and I have a timer which prints this every second: "print("4444 Screen.orientation is", Screen.orientation, "physicalOrientation is", physicalOrientation, "buhuu", buhuu)" | 11:21 |
| tsdgeos | cimi: i think mzanetti wants it asap since people are "complaining" about it in the scopes showdown contest, am i right? | 11:21 |
| mzanetti | dandrader, and the output is: "4444 Screen.orientation is 0 physicalOrientation is 2 buhuu 2" | 11:21 |
| mzanetti | how on earch can buhuu be 2 while Screen.orientation still 0? | 11:22 |
| mzanetti | (same goes for physicalOrientation) | 11:22 |
| dandrader | hmm | 11:23 |
| dandrader | mzanetti, it can happens if QScreen.orientation() changes but the code forgets to emit a QScreen.orientationChanged() signal to cause bindings to update/re-run | 11:26 |
| mzanetti | dandrader, but I have a timer which polls the variable every second | 11:26 |
| dandrader | mzanetti, but that variable is fed by a binding | 11:26 |
| dandrader | mzanetti, and the binding won't re-run unless one of its components tell it that it has changed | 11:27 |
| mzanetti | dandrader, well, weird thing is, buhuu has actually the correct value, while Screen.orientation hasn't | 11:27 |
| mzanetti | dandrader, so buhu *does* update, Screen.orientation does not, stays always at 0 | 11:27 |
| mzanetti | which is the part that confuses me... | 11:27 |
| dandrader | mzanetti, but does "correct value" means "latest value"? | 11:28 |
| mzanetti | yes | 11:28 |
| mzanetti | dandrader, http://paste.ubuntu.com/15073462/ | 11:28 |
| mzanetti | dandrader, whenever it says "physical orientation changed" I rotate it | 11:29 |
| mzanetti | dandrader, so, that is fine, except that Screen.orientation still gives me 0 when I poll it | 11:29 |
| mzanetti | dandrader, the reason why I'm looking into it, is that once an external screen is plugged/unplugged, it stops updating altogether | 11:29 |
| mzanetti | dandrader, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1545286 | 11:30 |
| ubot5` | Launchpad bug 1545286 in unity8 (Ubuntu) "[regression] ubuntu-pd instability" [Critical,Triaged] | 11:30 |
| dandrader | mzanetti, and "property int physicalOrientation: Screen.orientation", right? | 11:30 |
| mzanetti | dandrader, yes, I even changed it to "readonly" to make sure the binding is not broken by something... same issue still | 11:31 |
| dandrader | mzanetti, so physicalOrientation and buhuu always match? | 11:31 |
| mzanetti | yes, at least that | 11:31 |
| dandrader | mzanetti, good :) | 11:31 |
| cimi | tsdgeos, mzanetti I was trying to find info on how exactly to pass properties or bindings inside a Loader. Sometimes we have Loader { sourceComponent: Item { property var prop: root.rootProperty } } , sometimes we do onLoaded: prop = root.rootProperty, sometimes onLoaded: prop = Qt.binding(function() { return root.rootProperty }) - what's the rule of thumb for this? | 11:32 |
| mzanetti | dandrader, I could imagine Screen::orientationChanged() having a param, and the binding evaluates that param, but then it is not saved internally | 11:32 |
| mzanetti | searching for the Screen code atm | 11:32 |
| cimi | I know that the latter works all the time :) but in which cases the first two are correct alternatives? | 11:32 |
| dandrader | cimi, see the bindings in applicationsDisplayLoader, in Shell.qml | 11:32 |
| tsdgeos | cimi: i'd say first is better, third is the same but kind of weird, second is not a binding so if root.rootProperty changes it won't get updated | 11:33 |
| cimi | tsdgeos, ok why we use third so many times? | 11:34 |
| cimi | tsdgeos, I know second is not a binding, that just pass the property | 11:34 |
| dandrader | mzanetti, you could also have cpp code monitoring QScreen to see if it differs from its QML counterpart | 11:34 |
| mzanetti | right | 11:35 |
| mzanetti | where is QScreen? | 11:35 |
| cimi | tsdgeos, because we have source and not sourceComponent? | 11:35 |
| mzanetti | ah, gui | 11:35 |
| cimi | just trying to find a rule of thumb, no doc at all on the web | 11:36 |
| cimi | tsdgeos, in CardGrid we have Connections where I wanted to connect to signal action(actionId) coming from social attributes in the Card, however I was adding the signal to the generated qml from JS file only when socialAttributes were present... so the Connections in CardGrid complain that the signal is not there. Having the signal always in the QML generated code is the only option to avoid the warnings? | 12:30 |
| tsdgeos | cimi: there's ignoreUnknownSignals | 12:33 |
| tsdgeos | i don't know which is better tbh | 12:33 |
| cimi | tsdgeos, up to you/us :) | 12:34 |
| cimi | tsdgeos, we can always have the signal there in all generated code, or we use this bool | 12:34 |
| tsdgeos | cimi: i'd say let's have the signal | 12:35 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === bpierre_ is now known as bpierre | ||
| dandrader | @unity "sudo apt-get update" from the phone working for you guys? I'm getting a bunch of "404 Not found"... | 14:27 |
| mzanetti | dandrader, seems to work for me | 14:28 |
| dandrader | mzanetti, ah... must be because I forgot to set my device to writable :-D | 14:29 |
| === dandrader is now known as dandrader|lunch | ||
| tsdgeos | cimi: when you say "we want just small cards to have 4 columns" you mean "2 columns"? | 15:07 |
| cimi | tsdgeos, we actually changed a bit | 15:07 |
| cimi | tsdgeos, we only have 1 row | 15:08 |
| cimi | tsdgeos, for small cards 2 social icons, medium 3, large 4 | 15:08 |
| cimi | tsdgeos, I implemented that, I'm working on editing the mocks to see if I can show social attributes in tryGenericScopeView and test that the signal is chaining down | 15:09 |
| tsdgeos | cimi: so you still need to push that, right? | 15:10 |
| cimi | tsdgeos, yeah | 15:10 |
| tsdgeos | ok, will wait for review then | 15:10 |
| tsdgeos | Saviq: ok, changed https://code.launchpad.net/~aacid/unity8/preview_audio_playlist/+merge/284624 | 15:30 |
| === dandrader|lunch is now known as dandrader | ||
| Saviq | tsdgeos, tx | 15:37 |
| cimi | pstolowski, czesc, we didn't add yet the social attributes roles to unity shell scopes? | 15:43 |
| pstolowski | cimi, hey, let me take a look | 15:49 |
| Saviq | cimi, we might as well start typing in PL to you now? ;) | 15:52 |
| pstolowski | cimi, right. we didn't | 15:54 |
| cimi | pstolowski, planning to add it soon? would be nice to have a test scope too | 16:00 |
| cimi | pstolowski, I was editing the mocks to support the social cards, I realised we didnt land those indeed | 16:01 |
| pstolowski | cimi, wasn't aware of it, so i guess will have to add them ;) | 16:11 |
| jhodapp | tsdgeos, silo 21 is rebuilding now with a fix that should take care of the issue you saw...note that I'm still testing it myself though but you're welcome to try it when it's done building | 16:26 |
| tsdgeos | jhodapp: okidoki | 16:26 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOD | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!