| charlee | hey guys, good morning, does anyone know how to start unity using startx? i have tried to put in `exec unity`, unity started but lot of things were missing, compiz wasn't loading, etc.. | 00:14 |
|---|---|---|
| charlee | also tried `exec gnome-session --session=unity`, couldn't get unity to start | 00:15 |
| charlee | I personally don't want to use any of the display manager, so is there a way to just startx it? thanks | 00:16 |
| tsdgeos | mzanetti: is https://code.launchpad.net/~mzanetti/unity8/update-inputinfo/+merge/273248 something we want in or still a WiP? | 07:10 |
| mzanetti | tsdgeos, still WIP. need to update tests... have them half working here | 07:43 |
| tsdgeos | ok | 07:43 |
| tsdgeos | mzanetti: so no need for the extra carefulness i suggested in the autorepeat MR? | 08:14 |
| tsdgeos | i guess it was a bit too much :D | 08:14 |
| Saviq | mzanetti, you got an arale? can you try bug #1508830 ? | 09:13 |
| ubot5 | bug 1508830 in unity8 (Ubuntu) "Phone hangs by repeatedly refreshing the apps scope and taking screenshots" [Undecided,Confirmed] https://launchpad.net/bugs/1508830 | 09:13 |
| === nudtrobert1 is now known as nudtrobert | ||
| === jzheng is now known as jzheng_afk | ||
| tsdgeos | sigh | 10:08 |
| tsdgeos | something has changed on the SDK | 10:08 |
| tsdgeos | and stuff now doesn't even compile | 10:08 |
| tsdgeos | in the use_sdk_13 bnranch | 10:11 |
| * tsdgeos investigates | 10:12 | |
| tsdgeos | ah new item clashes with one of ours | 10:14 |
| davmor2 | tsdgeos: blame Saviq, it won't fix it but you'll feel much better | 10:14 |
| tsdgeos | Saviq: mzanetti: are you guys doing the audiorole compatibility branch with that loader thing you showed me yesterday or want me to? (since the bug is assigned to me) | 10:35 |
| Saviq | tsdgeos, you might very well do it, basically take the component from https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 | 10:37 |
| tsdgeos | ok, /me does | 10:37 |
| mzanetti | oops... sorry, missed your earlier message Saviq | 10:37 |
| Saviq | nw | 10:37 |
| mzanetti | Saviq, yes, I have, will try, (re arale) | 10:38 |
| Saviq | mzanetti, jibel was able to repro once, there's a chance the "refresh apps scope" is a red herring | 10:38 |
| Saviq | I wasn't able to repro on krillin with, or without apps scope refresh | 10:38 |
| mzanetti | yeah... looks like something goes wonky on dbus | 10:49 |
| mzanetti | media hub dying and the shell trying to reach it for the screenshot sound | 10:50 |
| Saviq | man... DST change this weekend "16 trains will stop for an hour"... | 11:12 |
| ltinkl | lol | 11:13 |
| Saviq | can we please stop this madness | 11:14 |
| ltinkl | I agree but this change is to the right time | 11:15 |
| Saviq | ok then, can we please only do this this one last time? | 11:16 |
| === olli_ is now known as olli | ||
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === maclin1 is now known as maclin | ||
| === dandrader|afk is now known as dandrader | ||
| tsdgeos | mterry: can you review https://code.launchpad.net/~aacid/unity8/scope_settings_keyboard_scroll/+merge/274874 ? | 12:59 |
| mterry | k | 12:59 |
| mterry | tsdgeos, I wanted something like this in one of my apps but was too lazy to do it :) | 13:01 |
| mterry | tsdgeos, SDK should have an option on its UbuntuListView for this | 13:01 |
| tsdgeos | the problem is that it still needs the delegates to request the visibilty | 13:02 |
| tsdgeos | ideally one could watch all children created and inject the request | 13:02 |
| tsdgeos | but i decided not to spend so much time :D | 13:02 |
| mterry | tsdgeos, why this line in setMake...Item()? "d.previousVisibleHeight = d.visibleHeight;" | 13:03 |
| mterry | is it for the initial setting? could do that by "property real previousVisibleHeight: visibleHeight" | 13:03 |
| mterry | tsdgeos, also, mightn't you want to ensure it's visible in that same call without having to wait for visibleHeight to change again? | 13:04 |
| tsdgeos | mterry: this is reusing some of the code we use for the previews | 13:05 |
| tsdgeos | in which the items change height so we need to account for that | 13:05 |
| tsdgeos | hence the complex stuff with height | 13:05 |
| mterry | tsdgeos, ? but in onVisibleHeightChanged you always set previous. So the only time previous will be out of sync will be before the first onVisibleHeightChanged | 13:05 |
| mterry | tsdgeos, in which case you can just start with an initial binding on previous | 13:06 |
| tsdgeos | mterry: yes i set it for the next change | 13:06 |
| tsdgeos | that's what previous is for, no? | 13:06 |
| mterry | tsdgeos, right. I'm saying I don't see the need for the additional set in setMakeSureVisibleItem(). But it doesn't matter. It's not harmful. Just hard to see why it's there | 13:07 |
| tsdgeos | mterry: otherwise the first onvisibleheightchanged has un-initialized value, no? | 13:07 |
| === alan_g|lunch is now known as alan_g | ||
| mterry | tsdgeos, right. And that's why I suggested "property real previousVisibleHeight: visibleHeight" instead of ": 0". Thought it was clearer than an extra previous set | 13:08 |
| mterry | But it doesn't matter | 13:08 |
| tsdgeos | mterry: but then it doesn't work for the next item | 13:08 |
| tsdgeos | since the binding would already be broken | 13:08 |
| mterry | tsdgeos, but previousVisibleHeight doesn't depend on the item. The next item will have it set from a onVisibleHeightChanged call | 13:09 |
| tsdgeos | hmmm, might be | 13:11 |
| tsdgeos | tbh i just moved this code around :D | 13:11 |
| mterry | tsdgeos, I'm seeing that now :) You just kept the set from the previous code | 13:11 |
| mterry | tsdgeos, wouldn't it be better to adjust contentY immediately when setMakeSureVisibleItem() is called, rather than waiting for the next onVisibleHeightChanged? | 13:12 |
| tsdgeos | to which value? | 13:13 |
| mterry | tsdgeos, I mean, force a recalculation, as if onVisibleHeightChanged happened | 13:14 |
| mterry | tsdgeos, but just to do it immediately after receiving a new item | 13:14 |
| tsdgeos | but at that point it won't do anything | 13:14 |
| tsdgeos | since you're already visible | 13:14 |
| tsdgeos | since you gained focus | 13:14 |
| mterry | tsdgeos, how does this component know that? | 13:14 |
| tsdgeos | so the user can see you | 13:14 |
| mterry | tsdgeos, you're saying that all callers make sure to only call it after they are visible? fine | 13:15 |
| mterry | tsdgeos, but as a component API, I'd have expected it to make sure | 13:15 |
| tsdgeos | well it's a component since i didn't want to c&p code :D | 13:16 |
| mterry | Seems less fragile to not rely on callers being smart | 13:16 |
| tsdgeos | it doesn't matter anyway | 13:16 |
| tsdgeos | since it'll work | 13:16 |
| tsdgeos | on the height change | 13:16 |
| tsdgeos | if somehow you can make a thing gain focus without having it in view | 13:16 |
| mterry | tsdgeos, you're talking about the specific narrow situations we use this component in now. But I'm just seeing a component that has an API that says "make me visible" -- no API contract for being focused or in view. | 13:19 |
| mterry | tsdgeos, I'm thinking a future unity8 developer might reasonably use this for a different purpose and expect its API to do what it says | 13:19 |
| tsdgeos | mterry: sure, as said, it'll get visible on first height change by the sdk | 13:19 |
| mterry | tsdgeos, right... | 13:20 |
| tsdgeos | not as you'd see the difference at all | 13:20 |
| mterry | tsdgeos, and I'm saying there's a gap there before that happens :) | 13:20 |
| mterry | this is a theoretical problem, I'm just trying to be defensive against future bugs/misunderstandings | 13:20 |
| tsdgeos | i don't understand what you say | 13:20 |
| tsdgeos | i don't see any theoretical problem | 13:20 |
| tsdgeos | please explain where is the problem | 13:21 |
| mterry | tsdgeos, so let's say in a year, I see this component. I have some code that wants to pull a widget in my list into view. So I call this setMakeSureVisibleItem(). And nothing changes! It's not in view. Only the next time the OSK appears does it finally scroll to my widget | 13:21 |
| tsdgeos | correct | 13:22 |
| mterry | tsdgeos, why would setMakeSureVisibleItem() not make sure my item is visible after the call? :) | 13:22 |
| tsdgeos | because you're using a component called ListViewOSKScroller | 13:22 |
| tsdgeos | you're doing it wrong | 13:22 |
| tsdgeos | it's not what you want | 13:22 |
| tsdgeos | and it should not do that | 13:22 |
| mterry | Oh fair, OSK is in the title... But fine. What if I call this after the OSK is up? | 13:23 |
| tsdgeos | if you want to make an item visible there's other things to use | 13:23 |
| mterry | tsdgeos, but now there's a race between the OSK and this API call. What if I call this after the OSK appears? | 13:24 |
| tsdgeos | i'd still argue you're using it wrong | 13:24 |
| tsdgeos | it's not what the component is for | 13:24 |
| mterry | Says every widget designer :) | 13:24 |
| tsdgeos | this is *not* a widget by the way | 13:24 |
| tsdgeos | it's a helper | 13:25 |
| mterry | I know | 13:25 |
| tsdgeos | if it doesn't do what you want | 13:25 |
| tsdgeos | don't use it | 13:25 |
| mterry | Says every API designer :) | 13:25 |
| tsdgeos | it's not like you're forced to use it | 13:25 |
| tsdgeos | that's silly | 13:25 |
| tsdgeos | you're forced to use a button | 13:25 |
| tsdgeos | so button has to be flexible | 13:25 |
| tsdgeos | you're not forced to use this, so it can do its thing | 13:25 |
| tsdgeos | if it doesn't do what you want, you can still do it | 13:25 |
| tsdgeos | you're not being excluded | 13:26 |
| tsdgeos | so yes, this component doesn't do what you want when the OSK is open | 13:26 |
| tsdgeos | that's what it has been coded to do | 13:26 |
| tsdgeos | it's not a bug, it's a feature | 13:26 |
| mterry | Right... It seems needlessly fragile is all. But sure, I'm not saying there's a bug in the code right now. Just trying to be defensive | 13:26 |
| tsdgeos | it is not needlessly fragile | 13:26 |
| tsdgeos | doing one thing well it's easier than doing more things we don't need to do | 13:27 |
| tsdgeos | introduces more bugs | 13:27 |
| tsdgeos | i need extra code to make a use case we don't need to work | 13:27 |
| tsdgeos | i agree with you that it needs documentation though | 13:27 |
| tsdgeos | we can go back to the version that copies the code ;) | 13:27 |
| mterry | It'd be one line of code after refactoring onVisibleHeightChanged into a function. But sure | 13:28 |
| tsdgeos | mterry: it won't | 13:28 |
| mterry | tsdgeos, I feel like this is a more heated argument than I intended to bring up | 13:28 |
| tsdgeos | i'm sorry for trying to counterargue your arguments | 13:29 |
| tsdgeos | :D | 13:29 |
| mterry | tsdgeos, no that's fine :) | 13:30 |
| mterry | tsdgeos, you say it won't be one line of code? Maybe that's the confusion. What are you envisioning I'm suggesting? | 13:30 |
| mterry | (I was thinking move onVisibleHeightChanged logic into a d.doTheThing() method. And just call d.doTheThing() after setting a new item to watch) | 13:31 |
| mterry | tsdgeos, ^ | 13:31 |
| tsdgeos | you need to at least split the if into two | 13:32 |
| tsdgeos | since you have previousVisibleHeight > visibleHeight that won't work if you don't | 13:32 |
| mterry | tsdgeos, sure... so onVisibleHeightChanged becomes "if (previousHeight > nowHeight) doTheThing(); previous = now;" | 13:33 |
| mterry | tsdgeos, like, this is a super minor point. I didn't mean to start a 30min debate about it :) | 13:34 |
| tsdgeos | i just wanted to not have a discussion about code i just moved around | 13:34 |
| mterry | tsdgeos, it's fine if you don't think it's worth the bother. I just felt I had to explain my side of things and then we got here | 13:34 |
| mterry | tsdgeos, well I think there's a higher standard for standalone components than code that gets used in one place | 13:35 |
| tsdgeos | sounded it was the safest solution not to change code we already have and works | 13:35 |
| cimi | tsdgeos, small bug I noticed in new navigation | 13:35 |
| cimi | tsdgeos, try searching in music scope where there is no departments | 13:35 |
| cimi | tsdgeos, then clear the search | 13:36 |
| cimi | then tap the search again so you see recent searches | 13:36 |
| tsdgeos | mterry: i can move it to Dash/ instead of Components/ if it makes your "standalone compoennts" worry better? | 13:36 |
| cimi | we miss the shadow at the bottom of the box | 13:36 |
| mterry | tsdgeos, no that wouldn't change anything :) But like I said, this is fine as is. I get that it's code you are just moving. (I don't think that means you absolve all responsibility for that code, but I understand reluctance to change it) | 13:38 |
| mterry | tsdgeos, like when you make a bug fix and a reviewer asks you to refactor the component :) | 13:40 |
| mterry | I hate that :) | 13:41 |
| tsdgeos | mterry: so want me to add some documentation to the qml file saying what the component does? | 13:42 |
| mterry | tsdgeos, the answer to that question is always yes, even without a debate as a prompt ;) But I don't think it's required here, if existing usage is documentation enough | 13:43 |
| tsdgeos | well there's no documentation at all | 13:44 |
| mterry | tsdgeos, just noticed another place where this would be useful -- the authentication dialog to sign into U1 from the dash scope, when you need to give a two-factor code. No need to change your branch, but just saying, a useful component | 13:47 |
| tsdgeos | mterry: but that's not in unity8 so can't be used | 13:47 |
| tsdgeos | sure it's an useful component if done better in the SDK | 13:47 |
| tsdgeos | as we started the discussion with :D | 13:47 |
| mterry | tsdgeos, right, that's what I was saying at the start :) | 13:47 |
| cimi | tsdgeos, also, when I am in a department and I search, the text is higher | 13:53 |
| tsdgeos | cimi: what do you mean "the text is higher"? | 13:53 |
| tsdgeos | in the search bar? | 13:53 |
| cimi | tsdgeos, yes | 13:53 |
| cimi | tsdgeos, not vertically aligned | 13:53 |
| tsdgeos | cimi: that already happens today | 13:53 |
| cimi | aw ok ) | 13:54 |
| tsdgeos | i'd say | 13:54 |
| tsdgeos | please double check | 13:54 |
| tsdgeos | afaik gets fixed when moving to sdk 1.3 for some reason | 13:54 |
| cimi | tsdgeos, yeah all text is higher now | 13:54 |
| cimi | seems sdk bug | 13:54 |
| tsdgeos | Mirv: there? | 13:55 |
| cimi | tsdgeos, did you see the other bug of the shadow? | 13:56 |
| tsdgeos | cimi: i am having a look at the 5.5 multimedia thing so don't have the silo installed | 13:56 |
| tsdgeos | i've copied your text and will check later | 13:56 |
| Mirv | tsdgeos: barely but yes | 14:01 |
| Mirv | tsdgeos: FYI I just filed bug #1508945 ie the weather app misbehaves still with 5.5.1 (similar to what it did when I backported certain patches fixing 1470700 to 5.4.1) | 14:02 |
| ubot5 | bug 1508945 in Ubuntu Weather App ""Couldn't load weather data, please try later again!" with Qt 5.5.1" [Undecided,New] https://launchpad.net/bugs/1508945 | 14:02 |
| Mirv | or maybe appaarmor is coming into the way or something. but other apps don't seem to have network issues. | 14:02 |
| tsdgeos | Mirv: cool | 14:03 |
| mterry | tsdgeos, what tool is the //! syntax for? or is that just stylistic? | 14:03 |
| tsdgeos | mterry: it's doxygen | 14:03 |
| mterry | tsdgeos, ah makes sense | 14:03 |
| tsdgeos | i think | 14:03 |
| tsdgeos | or maybe qdoc | 14:03 |
| tsdgeos | one of the two :D | 14:04 |
| tsdgeos | doxygen afair | 14:04 |
| Mirv | tsdgeos: all UITK issues start to be resolved. oh and btw I'm away next week (Saviq too fyi), but it's getting reasonably closer to landing to xenial now | 14:04 |
| tsdgeos | Mirv: :) | 14:04 |
| tsdgeos | Mirv: the new silo has 5.5.1 but still with the audiorole patches, right? | 14:04 |
| Mirv | tsdgeos: yes, still with audio role patches | 14:05 |
| Mirv | tsdgeos: and qtubuntu-camera/media ported to it | 14:05 |
| tsdgeos | ok, i'm having some issues, will double check what i'm doing wrong | 14:05 |
| Mirv | tsdgeos: so Unity 8 would appreciate a patch so that people would not need to hand edit qml files (as guided at https://wiki.ubuntu.com/Touch/QtTesting though) | 14:05 |
| tsdgeos | yeah | 14:05 |
| tsdgeos | on it | 14:05 |
| Mirv | videos, camera work too again as of today. I've been filling some holes of rebuilds needed today after I copied the 5.5.1 there. | 14:06 |
| Mirv | now it's pretty complete aside from qtcreator still building for the desktop. | 14:06 |
| tsdgeos | i'm getting | 14:09 |
| tsdgeos | file:///home/phablet/main.qml:6 "Audio.audioRole" is not available in QtMultimedia 5.5. | 14:09 |
| tsdgeos | wonder what is wrong?¿ | 14:09 |
| * tsdgeos starts all over | 14:10 | |
| Mirv | tsdgeos: the revision: 1; I asked about in the bug report maybe? | 14:10 |
| tsdgeos | mzanetti: Saviq: did you guys actually test https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 ? | 14:11 |
| tsdgeos | with our 5.5 packages? | 14:11 |
| Mirv | porting seemed alright for c++ code but I didn't know what to do on the qml side | 14:11 |
| Saviq | tsdgeos, I di'in, since I disapproved it ;) | 14:11 |
| tsdgeos | Mirv: tbh i'm not totally sure what that revision does | 14:11 |
| tsdgeos | Saviq: k | 14:12 |
| Saviq | tsdgeos, I think you can have multiple implementations of the same method, of different revisions, exported in different versions | 14:13 |
| Saviq | or something like that | 14:13 |
| Saviq | Mirv, ↑ | 14:14 |
| Saviq | mzanetti, can you comment what you found on bug #1508830 please | 14:14 |
| ubot5 | bug 1508830 in unity8 (Ubuntu) "Phone hangs by repeatedly refreshing the apps scope and taking screenshots" [Undecided,Confirmed] https://launchpad.net/bugs/1508830 | 14:14 |
| Saviq | tsdgeos, Mirv, http://doc.qt.io/qt-5/qtqml-cppintegration-definetypes.html#type-revisions-and-versions | 14:15 |
| tsdgeos | does anyone know how to make bluez dist-upgrade not stall forever? | 14:15 |
| Mirv | Saviq: yeah, I just douldn't figure out how to actually use it. and I was on that doc page :) | 14:16 |
| Saviq | Mirv, what you do is have implementations marked by Q_REVISION(), then, as you qmlRegisterType, you supply that for version foo, revision bar should be exported, for version baz, revision blah | 14:17 |
| Saviq | Mirv, this way from a single component you can export multiple versions of an import | 14:17 |
| tsdgeos | Mirv: i'd say we miss part of the patch | 14:17 |
| tsdgeos | let me check | 14:17 |
| Mirv | Saviq: yeah, thre's no qmlRegisterType in the patch (http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Add-audio-role-API-to-QMediaPlayer.patch?h=ubuntu) | 14:17 |
| Mirv | tsdgeos: it's the whole commit at least | 14:17 |
| Saviq | Mirv, it could be that the 5.5 import is marked for revision(1) earlier | 14:18 |
| tsdgeos | or maybe the patch is wrong upstream too | 14:18 |
| Saviq | i.e. qmlRegisterType for 5.5 was already there, with revision 1 | 14:18 |
| Saviq | or well, that | 14:18 |
| Saviq | but then, because it defaults to 0 | 14:18 |
| Mirv | it's possible upstream didn't test the qml part when they merged it to 5.6.. | 14:19 |
| Saviq | if there isn't a 5.5 import registered with revision 1, then audioRole shouldn't be available | 14:19 |
| Saviq | but .qmltypes says otherwise | 14:19 |
| tsdgeos | yeah they have | 14:20 |
| tsdgeos | qmlRegisterType<QDeclarativeAudio, 1>(uri, 5, 6, "Audio"); | 14:20 |
| Saviq | but for 5.6 | 14:20 |
| Saviq | Mirv, what does `qmlplugindump QtMultimedia 5.5` say? | 14:20 |
| tsdgeos | which is the correct version the upstream patch is being added | 14:20 |
| Saviq | so 5.5 exports a 5.6 version | 14:20 |
| Saviq | weird, but not necessarily wrong | 14:21 |
| tsdgeos | no we're doing it ourslves | 14:21 |
| Saviq | just means to use audioRole we actually need to import 5.6 | 14:21 |
| tsdgeos | not upstream, no? | 14:21 |
| tsdgeos | no means our backport is incomplete and we need a | 14:21 |
| Saviq | oh right, *we* backport to 5.5 | 14:21 |
| tsdgeos | qmlRegisterType<QDeclarativeAudio, 1>(uri, 5, 5, "Audio"); | 14:21 |
| tsdgeos | and the mess continues :D | 14:21 |
| Saviq | yay | 14:21 |
| Saviq | tsdgeos, we could leave it as 5.6 | 14:22 |
| tsdgeos | but i'd say that should be good | 14:22 |
| tsdgeos | or that | 14:22 |
| Saviq | tsdgeos, noting that the only feature available there over 5.5 | 14:22 |
| Saviq | is audioRole | 14:22 |
| Saviq | I'd go for that | 14:22 |
| tsdgeos | it's like we partly have 5.6 | 14:22 |
| Saviq | then we don't need to migrate to 5.6 proper | 14:22 |
| Saviq | exactly | 14:22 |
| Saviq | assuming 5.6 is backwards compatible :) | 14:23 |
| tsdgeos | actually we have it already :D | 14:23 |
| tsdgeos | boo me | 14:23 |
| Saviq | yes, we do | 14:23 |
| tsdgeos | so with the import for 5.6 it should work | 14:23 |
| tsdgeos | let's see | 14:23 |
| Mirv | tsdgeos: ok so there's another MP in addition to https://codereview.qt-project.org/#/c/122658/ ? | 14:23 |
| Mirv | and we miss that | 14:24 |
| tsdgeos | file:///home/phablet/main.qml:3 module "QtMultimedia" version 5.6 is not installed | 14:24 |
| Mirv | tsdgeos: I've sed 's/5.5/5.6/ in that ^ when backporting | 14:25 |
| tsdgeos | we still have | 14:26 |
| tsdgeos | // 5.6 types | 14:26 |
| tsdgeos | qmlRegisterRevision<QDeclarativeAudio, 1>(uri, 5, 6); | 14:26 |
| tsdgeos | qmlRegisterType<QDeclarativePlaylist>(uri, 5, 6, "Playlist"); | 14:26 |
| tsdgeos | qmlRegisterType<QDeclarativePlaylistItem>(uri, 5, 6, "PlaylistItem"); | 14:26 |
| tsdgeos | in the code | 14:26 |
| tsdgeos | wait tha error i got was with the wrong qt installed :D | 14:26 |
| tsdgeos | i'm confusing myself now | 14:26 |
| tsdgeos | give me 30 min to regather my thoughts | 14:27 |
| Mirv | tsdgeos: playlist is different backport/patch | 14:27 |
| tsdgeos | i know | 14:27 |
| tsdgeos | still says "audio" in there | 14:27 |
| mzanetti | Saviq, I didn't really find much... took like 30 screenshots and can't reproduce the hanging | 14:28 |
| mzanetti | also tried the scope refreshing... no avail | 14:29 |
| mzanetti | reading jibel's log output suggests media hub is not responding on dbus and we try to play the screenshot camera sound | 14:29 |
| mzanetti | ok, I guess that qualifies... | 14:29 |
| mzanetti | will add this | 14:29 |
| Saviq | mzanetti, ah I thought you actually saw the media issue | 14:30 |
| mzanetti | no, sorry | 14:39 |
| Saviq | no need to be sorry :) | 14:40 |
| mzanetti | new inputinfo api is great | 14:41 |
| mzanetti | could drop all the wrapper stuff etc... also mocking was super easy | 14:41 |
| mzanetti | ljp, ^ | 14:41 |
| Saviq | nice | 14:52 |
| === Cimi_ is now known as cimi | ||
| dandrader | mzanetti, so the "reveal sensitivity" of the edge push to showing the launcher should be configurable. what's the prefered way to expose it? gconf? | 15:07 |
| tsdgeos | Mirv__: https://code.launchpad.net/~aacid/unity8/new_and_old_audio_role/+merge/275365 should be it | 15:08 |
| tsdgeos | need to triple check | 15:08 |
| tsdgeos | but looks good to me | 15:08 |
| tsdgeos | arg it has a stray commit | 15:08 |
| === mariogrip_ is now known as mariogrip | ||
| tsdgeos | better | 15:10 |
| === Mirv__ is now known as Mirv | ||
| === dandrader is now known as dandrader|afk | ||
| mzanetti | tsdgeos, our packages that have the feature backported to 5.5, will they also bump the version to 5.6, even if it's 5.5? | 15:21 |
| tsdgeos | mzanetti: yep | 15:22 |
| mzanetti | ok, that's weird | 15:22 |
| tsdgeos | or at least that's what the current packages have | 15:22 |
| mzanetti | are they backporting *all* 5.6 changes? | 15:22 |
| tsdgeos | don't think so | 15:22 |
| tsdgeos | but if we do use 5.5 | 15:22 |
| mzanetti | why bumping the version then? | 15:22 |
| tsdgeos | then it'll be even more weird | 15:22 |
| tsdgeos | because we'll need revision 2 for 5.6 | 15:22 |
| tsdgeos | and then all is evil | 15:22 |
| mzanetti | not following... | 15:23 |
| tsdgeos | we can say 5.5 supports Audio Revision 1 | 15:24 |
| tsdgeos | or | 15:24 |
| tsdgeos | 5.6 supports Audio Revision 1 | 15:24 |
| tsdgeos | upstream is the second | 15:24 |
| tsdgeos | if we do the first, we're also lying | 15:24 |
| tsdgeos | i actually think it makes more sense to say we've backported parts of 5.6 | 15:25 |
| tsdgeos | and act accordingly as 5.6 will act | 15:25 |
| tsdgeos | so we need to change less things later | 15:25 |
| tsdgeos | it's all "wrong" dependening how you want to think it | 15:26 |
| tsdgeos | we don't support all 5.6 | 15:27 |
| tsdgeos | but 5.5 doesn't have audioRole either | 15:27 |
| tsdgeos | but at least the core is more "correct upstream" if we say 5.6 | 15:27 |
| tsdgeos | in the sense it'll work on other non ubuntu-patched Qts | 15:27 |
| mzanetti | fair enough... | 15:27 |
| mzanetti | well, if other apps check for 5.6 and end up with our patched 5.5 version there's no guarantee it'll work | 15:28 |
| Mirv | tsdgeos: so should I revert the http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/commit/?h=ubuntu&id=8b95cbe6b78041047ac0a993b8986e6e836c719c which is currently in the package? | 15:28 |
| tsdgeos | Mirv: i'd say so since it's misleading | 15:29 |
| Mirv | ok, rebuilding qtmultimedia then | 15:29 |
| tsdgeos | mzanetti: sure not for other code | 15:29 |
| tsdgeos | but for ours it will | 15:29 |
| tsdgeos | at still the lib is called 5.5.1 | 15:29 |
| mzanetti | tsdgeos, in any case, we're just going to drop the audioRole usage in the clock app too | 15:29 |
| tsdgeos | even it partly supports things of 5.6 | 15:30 |
| mzanetti | right... got it... | 15:30 |
| tsdgeos | mzanetti: i agree it's "bad" both ways | 15:30 |
| mzanetti | yeah... | 15:30 |
| mzanetti | well, distro-patching :) | 15:30 |
| tsdgeos | but i'd say that calling 5.6 is the less bad of them | 15:30 |
| Mirv | tsdgeos: ok qtmultimedia building, unity8 building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages | 15:34 |
| Mirv | I really should stop now, bad way to start vacation totally exhausted :) there's tomorrow still. | 15:34 |
| Mirv | see you tomorrow | 15:35 |
| mhall119 | bregma: any new puritine packages I can try out? | 15:36 |
| bregma | mhall119, nope, all the fighing is happening on other fronts right now | 15:36 |
| mhall119 | ok, let me know when there is and I'll give it a try | 15:38 |
| === g4mby is now known as PaulW2U | ||
| tsdgeos | cimi: yes, can repro the shadow thing | 15:39 |
| cimi | tsdgeos, good | 15:39 |
| tsdgeos | cimi: fix pushed | 15:45 |
| tsdgeos | greyback: i added the comment you wanted, https://code.launchpad.net/~aacid/unity8/fix_cropped_image_binding_loop top approve? | 15:46 |
| greyback | done | 15:47 |
| tsdgeos | greyback: tx | 15:50 |
| tsdgeos | larsu: top approve https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788 ? | 15:51 |
| === ssweeny` is now known as ssweeny | ||
| === dpm is now known as dpm-afk | ||
| === dandrader|afk is now known as dandrader | ||
| darklight_ | the link http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ is broken | 16:56 |
| === charles__ is now known as charles | ||
| kgunn | bregma: ^ see the darklight ping, so do we need to remove something there ? | 17:41 |
| bregma | kgunn, it looks like darklight_ has a bookmark to something that no longer exists | 17:42 |
| kgunn | bregma: mmm, will go back to my tinkering | 17:43 |
| === robru|sick is now known as robru | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!