[00:00] currently appindicators are failing to add menu items correctly but removing works [00:00] see bug 1203888 [00:00] bug 1203888 in libappindicator (Ubuntu) "appindicator ignores menu entries after having sent the menu to the indicator" [High,Triaged] https://launchpad.net/bugs/1203888 [00:01] ali1234, I don't remember. Does adding that on those fix it? [00:03] well adding is what is broken, so i suspect removing the check like with remove would fix it... just about to try it === Pici is now known as TalkingMuffin [01:06] well, this is certainly related - changing "child-added" to "something-else" causes the error message to change as expected. but changing it to "insert" to match the GTK3 case causes a segfault [01:45] tedg: so it turns out the fix is to remove all the GTK3 tests from that file - they all apply only to the item insert cb [01:46] and specifically the other two modify the argument list to the cb function - and calling it with the wrong set of arguments obviously caused the segfault === duflu_ is now known as duflu === iahmad is now known as iahmad|afk [08:47] mhr3: can you comment on https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200 that it actually fixes the problem for you? [08:52] tsdgeos, done [08:54] tx [08:56] mzanetti: so no landing of the packages we needed? [08:57] tsdgeos: hmm... seems so :/ [08:58] :( [08:58] keep piling up! :D [08:58] it's almost my full screen height of reviews now :D [09:00] mzanetti: can you quick look at https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414 ? can i top approve? [09:01] tsdgeos: done [09:01] tx [09:02] tsdgeos: a few days ago you asked me about the searchhistorymodel [09:02] yep [09:02] tsdgeos: I see in nic's branch that there is one in Shell.qml [09:02] yep [09:03] which doesn't seem to be used at all [09:03] it's just unused as stands now [09:03] yep [09:03] ok. [09:03] I'll note that down [09:03] and every ScopeView ahs anthoer [09:03] that is also unused as of now [09:03] yeah, now there is one in Dash.qml with makes it shared among all scopes [09:03] just the ones in PageHeader are being used now [09:03] oh, another one? [09:03] yeah, the one in PageHeader is gone now [09:04] ok [09:04] yet another conflict for my tabbar branch :D [09:04] need multi-rebasing :D [09:04] or just wait some decent time for all the stuff to be merged in [09:04] yeah... I guess we should start rebasing stuff and create a chain of prerequisities [09:05] although that has potential to explode too [09:07] yeah [09:08] let's just let it explode organically [09:09] oh man the new notify-osd killer code is annoying [09:09] hmmm [09:09] which actually means it's been released? [09:10] the shell now kills my notify-osd [09:10] and obviously it doesn't come back after killing the shell [09:10] so i get some weird old kde notifications floating around :D [09:10] mzanetti: was notify-osd the only thing we needed? [09:11] MacSlow: ^ [09:12] I think yes [09:12] tsdgeos: well, its 2 of them [09:12] so maybe we can trigger a single branch manually or something to see how it goes? [09:12] mzanetti, tsdgeos: that's what was supposed to happen [09:12] one moment [09:13] MacSlow: i know, it's only annoying as a desktop user :D [09:13] tsdgeos, probably... :) [09:14] tsdgeos, but as I'm on unity (on the desktop) as soon as I quit my unity8-shell the next notification will trigger starting system-wide notify-osd again [09:14] tsdgeos, I assume you're running KDE [09:15] MacSlow: nope at work-work time [09:15] i'm running unity+apps [09:15] most of the apps kdelibs-based [09:15] and notify-osd doesn't restart here unless i manually start it [09:20] mzanetti, ping [09:20] nic-doffay: hey [09:20] tsdgeos, I assume notify-osd doesn't get retriggered because of the KDE-based apps not using libnotify/protocol [09:20] of course :D [09:21] they just use the com.foo.notification bla daemon if it's there [09:21] and i guess it isn't [09:21] tsdgeos, still if it (notify-osd) runs, it's able to consume notifications triggered by KDE-apps?! [09:21] MacSlow: sure [09:22] tsdgeos, but if you see knotify rendered notifications, that means you've some special service-file explicitly triggering that daemon instead of notify-osd? [09:23] tsdgeos, I'm just trying to reproduce it on my desktop here... pulling updates atm [09:23] MacSlow: yeah, kdelibs may lift up it's own daemon for org.freedesktop.Notifications if it doesn't find anything there [09:24] does anyone have a clue how to know which app is serving org.freedesktop.Notifications ? [09:25] anyway not something to spend time on [09:25] tsdgeos, hm... but should not /usr/share/dbus-1/services/org.freedesktop.Notifications.service be controlling what daemon gets started? [09:25] it's a very -dev specific usecase [09:25] MacSlow: no clue :D [09:26] tsdgeos, that's how it works on my system... although I'm not familiar with the KDE-side of this... so no idea how that might inject yet another notification-daemon [09:26] tsdgeos, sorry [09:26] as said [09:27] mzanetti, still wondering how to make the search history persist between unity8 restarts. Any ideas? [09:27] tsdgeos, sure [09:27] no need to spent time on this [09:27] was just saying [09:27] nic-doffay: hmm... let me read the SearchHistoryModel code [09:28] so [09:28] back to test writing land [09:28] nic-doffay: 2 options: either you check out the LocalStorage qml plugin (I've never used it before) or you create a small QML plugin yourself which dumps stuff somewhere on disk [09:28] tsdgeos: any opinion? ^ [09:29] what would you guys go for a test that wants to check we can horizontally swipe the dash if it's scrolling verticallly? ultra scared of "not going to get this to happen at the right time" tbh [09:30] mzanetti: i'd go for the "save it ourselves to disc" [09:30] tsdgeos: can we use 2 fingers? [09:30] +1 on the "our plugin" [09:30] localstorage seems to much database-y for this usecase [09:30] mzanetti: what do you mean 2 fingers? [09:30] nic-doffay: I can help you getting started with the QML plugin if you've never done that before [09:30] tsdgeos: let me test something [09:31] tsdgeos: is that fix already released? [09:31] mzanetti: yep [09:31] https://code.launchpad.net/~aacid/unity8/dash_disable_hswipe_on_vswipe/+merge/190576 [09:31] hmm.. ok. [09:31] just wanted to clear that list of bugs without test you created the other day [09:31] tsdgeos: well, in the launcher tests I flick it up/down [09:31] tsdgeos: if the list is long enough that lasts for 2 secs [09:31] ok [09:31] which really should be enough for trying to swipe horizontally [09:32] i guess i can try to have a long list [09:32] let's go for a qml test then :D [09:32] definitely [09:32] mzanetti, yeah if you don't mind. [09:33] nic-doffay: ok. so. I'd say you dump it into plugins/Unity/ [09:33] nic-doffay: create a class, inheriting QObject called SearchHistoryModel [09:34] hook it up in plugin.cpp just like the others [09:34] and give it a function addQuery(const QString &query) [09:35] then you should be able to just drop Components/SearchHistoryModel.qml and wherever Unity 0.1 is imported it should just use the new cpp SearchHistoryModel instead [09:35] in there you can then easily write/read a file [09:35] mzanetti: wouldn't it be easier to write only the dumper, not a whole model? [09:35] otherwise it'll need to be a QAbstractItemModel and all that, no? [09:36] tsdgeos: yeah... was going to say. instead of QObject, make it QAbstractListModel [09:36] tsdgeos: hmm... you think we should have only a dumper? [09:36] tsdgeos: I guess this well be quite useful in the future, when we might want to filter stuff etc [09:36] mzanetti: i think it'd be easier, i guess it depends if/when we want to sync the file to disk [09:36] also we need something like clear() and whatnot. [09:37] mzanetti: ok, if you see us using more modellike stuff [09:37] I think implementing count() and data() would be easier in the long run than keeping a qml ListModel and some file on disk in sync [09:37] mzanetti: may as well use qstringlistmodel [09:38] right [09:38] if all we want is a list of strings [09:38] nic-doffay: QStringListModel [09:38] though QStringListModel is a bit silly doesn't have an insert [09:38] so don't know :D [09:38] * tsdgeos stops suggesting/unsuggesting things [09:38] yeah, hence the addQuery() which then keeps it api compatible to the existing one [09:39] nic-doffay: is that good enough for a start? [09:42] mzanetti, yeah that's cool. [09:42] cheers [09:44] mzanetti, so inherit from QStringListModel which will replace the current QML class? [09:44] nic-doffay: yep. class SearchHistoryModel: public QStringListModel [09:45] after you added "addQuery()" it should just work automagically to replace the qml one [09:45] mzanetti, great. I wanted the break from QML too tbh! [09:45] cool [10:16] tsdgeos: fyi: notify-osd has been released. but I just realize that we probably need to upgrade the jenkins machines, otherwise the old one is still running [10:16] and I've no clue about the otto jenkins machines [10:16] mzanetti: hmmm [10:16] but once fginther shows up I think we can have that [10:16] ok [10:17] i thought stuff was upgraded on each run? [10:17] or only the stuff we depend on [10:17] and not the base system? [10:17] tsdgeos: I don't think we upgrade the base system every time. would be a huge waste of time [10:18] but a way we work against the current status of system libs :D [10:18] but i can see why we don't do it [10:18] anyway, good that we're one step closer! [10:34] you guys have bugs for me? [10:43] Cimi: https://code.launchpad.net/~aacid/unity8/no_hswipe_if_vswipe_test/+merge/193401 [10:46] tsdgeos, and? [10:46] review? [10:46] :D [10:46] tsdgeos, why this? [10:46] why not? [10:48] anyone knows how to know which "3 people" are affected by a bug when launchpad says "3 people affected by this bug" [10:48] ? [10:50] * tsdgeos likes c++ chained constructors [10:50] hurray for them [10:50] \o/ [10:55] hmmm [10:55] https://bugs.launchpad.net/unity8/+bug/1229652 is not *our* bug, no? [10:55] Ubuntu bug 1229652 in Unity 8 "Home and app scope names are wrong" [High,Triaged] [10:55] we don't have those strings anywhere [10:55] mhr3: ? ↑↑ ? [10:59] tsdgeos, right [10:59] mhr3: which projects do i reassign this to [10:59] ? [10:59] already done [10:59] tx [11:00] Cimi: if you're totally bored, can you try to reproduce the crash mentioned in https://bugs.launchpad.net/unity8/+bug/1240408 ? [11:00] Ubuntu bug 1240408 in Unity 8 "unity8 crashed with SIGSEGV in QCoreApplication::postEvent()" [High,Triaged] === _salem is now known as salem_ [11:08] tsdgeos, nt that bored :D [11:14] Cimi: ok, we ave around 155 bugs [11:15] i'm sure you can find something, no? [11:15] tsdgeos, not much on unassigned ones [11:15] tsdgeos, I picked up a dozen already, fixed all [11:15] tsdgeos, we need more bugs :) [11:16] http://goo.gl/VDU0V4 [11:17] Cimi: that's the unassigned ones? [11:17] y [11:17] I'm looking if there's something for me === iahmad_ is now known as iahmad [11:18] might do this https://bugs.launchpad.net/unity8/+bug/1236280 [11:18] Ubuntu bug 1236280 in Unity 8 "[right edge] Dash should appear in the right edge interaction as just another app" [High,Confirmed] [11:19] but probably requires a snapshot of the dash as a normal app? [11:19] greyback: ↑↑↑ [11:21] Cimi: yes it would. That can be done, but I believe I designed unity-mir to not make that easy [11:23] preserving the scroll position is complicated also [11:23] because I put that when you left swipe [11:23] it switches to app scope [11:23] so if the user starts a left swipe, cancels [11:23] does a right swipe [11:23] the dash will lose the original position [11:25] Cimi: yeah. that bug will require lots of changes everywhere [11:26] Cimi: since I'll be refactoring much of that window management code - and the right-edge switch-application animation will be changed, I don't think now is the good time to take that one on [11:26] greyback, unless we store contentX of dashContentList and contentY of the dashContentList.currentItem [11:27] greyback, basically when dash is no longer in focus, we save those [11:28] greyback, when we go back to the dash, we reapply those [11:29] Cimi: hold on. You'd be taking a snapshot of the shell's surface and adding it to the list of application surfaces to switch through [11:29] greyback, yes [11:29] Cimi: I don't see why you're changing contentX [11:29] greyback, but as said, when you left swipe to reveal the dash [11:30] greyback, we have to switch to app lens, contentY = 0 [11:30] greyback, by design [11:30] greyback, so if the user is using camera [11:30] greyback, starts swiping left [11:31] greyback, (note that now the dash should be on the app lens) [11:31] greyback, then changes his mind and remains on the camera app [11:31] then after a while he right swipe and choose the dash [11:31] greyback, the dash will be on the app lens because the previous left swipe changed that [11:33] greyback, problem is, left swipe is an animation thus when the finger is a little bit after the launcher you should already start seeing the app lens appearing [11:34] greyback, relevant code here https://code.launchpad.net/~cimi/unity8/fix-1231996/+merge/192372 [11:34] and bug https://bugs.launchpad.net/unity8/+bug/1231996 [11:34] Ubuntu bug 1231996 in Unity 8 "[SHELL] apps scope is not in place when performing long edge swipe from left" [High,In progress] [11:35] only way I can see having both scenarios working at the same time is storing the position (contentX and Y) of the dash when you take its snapshot [11:36] Cimi: (aside: for the first MR, that commit message is not clear. It just says steps to repro a problem, not saying what the problem actually is, nor giving the solution the MR performs) [11:37] greyback, no it says id [11:37] *it [11:37] greyback, it switches to app scope when dash swipe *is taking place* [11:37] Cimi: ah I get it, sorry [11:38] np [11:39] Cimi: so, snapshots of shell surface are tricky. You know that when an application is on screen, the shell surface is always on top of it, but defines a big transparent rectangle that allows the application to be visible [11:40] yeah got that [11:40] so yeah it's difficult [11:40] Cimi: so the only time we can grab snapshot of whole dash, is when dash fully on screen. [11:40] greyback, we should take the snapshot only when the shell is in focus [11:41] greyback, snapshots of dash are taken only when no app is above it [11:41] Cimi: yep. Taking your problem case, and assuming snapshot of shell Home lens taken and available [11:41] if you switch to an app, no more snapshots are taken [11:41] Cimi: in camera app, start a left swipe. You see Dash change to Apps lens. Then cancel that left swipe, to return to camera. [11:42] Cimi: in that case, dash is on apps lens. But our snapshot is of home lens. [11:42] greyback, yes [11:42] and there's no way to grab snapshot of apps lens reliably in that case [11:42] greyback, so if we stored contentX and Y [11:42] greyback, when we right swipe we simply restore contentX and Y [11:43] it doesn't matter. User expects to return to apps lens. We cannot show them the home lens snapshot [11:43] greyback, ok then, no problem exist [11:43] greyback, problem is the snapshot [11:43] I see this issue now [11:43] greyback, we have hard time taking the screeenshot [11:43] Cimi: yep. the snapshot thing is a hack, and this exposes it's faults [11:43] its [11:44] I thought we wanted to go back to home lens [11:44] so the work to use live surfaces, not screenshots, should fix this. But we're not there yet [11:46] greyback: hey [11:46] mzanetti: yo [11:46] greyback: veebers would need this to be landed asap: https://code.launchpad.net/~gerboland/unity-mir/crash-fix-on-IFA-removal/+merge/192352 [11:46] greyback: it looks ok to me, but I don't feel confident enough with the surrounding code to just approve it [11:47] tsdgeos could you have a look, you know that code better [11:47] mzanetti: ^^ [11:48] sure [11:48] thanks [11:51] greyback: why aren't you deleting the inputareas anymore? [11:51] mzanetti, auto landing dance today? [11:51] how many dancers will fall on the floor? :) [11:51] tsdgeos: I never was. The InputAreas are owned by the QML engine, I let it delete [11:51] Cimi: stuff is released. when fginther shows up we can hopefully upgrade the jenkins machines and are good to go [11:52] greyback: oh right, it's commted... [11:52] Cimi: can you reproduce this? https://bugs.launchpad.net/unity8/+bug/1240408 [11:52] Ubuntu bug 1240408 in Unity 8 "unity8 crashed with SIGSEGV in QCoreApplication::postEvent()" [High,Triaged] [11:52] mzanetti, phone is dead now [11:52] mzanetti, will try after it charges [11:53] ok [11:54] greyback: code looks good, want me tro try it actually fixes the crash or has someone actually done that already? [11:54] mzanetti: ↑ ? [11:54] Cimi: there is an issue with the UbuntuShape in the launcher. if you look very closely, the image size doesn't match with the shape's size. I haven't had the time to dig deeper why. if you want you can have a look at that too [11:54] tsdgeos: I haven't [11:54] mzanetti, I know that [11:54] mzanetti, designers are in oakland [11:54] tsdgeos: the bug report gives step by step instructions. Woudl do no harm to check [11:54] tsdgeos: sorry, the bug description [11:55] Cimi: not sure why designers would be needed there [11:55] greyback: i know, i checked it crashes [11:55] mzanetti, fix the asset? [11:55] greyback: was asking if someone had checked it did not crash with the patch [11:55] greyback: since noone has, i will [11:55] Cimi: there's no asset [11:55] mzanetti, but I'll assign myself [11:55] mzanetti, ok [11:55] mzanetti, there was [11:55] Cimi: there is a branch which removes the white glow [11:55] use that one [11:55] tsdgeos: well I did, but I'm the author :) [11:56] greyback: sure [11:56] mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795 ? [11:56] Ubuntu bug 1223795 in Unity 8 "[Ubuntu shape] Inner highlight glow is not correctly rendered in Launcher icons" [High,Triaged] [11:56] Cimi: https://code.launchpad.net/~mzanetti/unity8/launcher-small-tweaks/+merge/191380 [11:56] Cimi: this one drops the highlight glow as jouni didn't want it at all [11:56] Cimi: still the shape doesn't really fit with the icon. no clue why yet [11:56] mzanetti, ok it's a new bug [11:57] mzanetti, will look into it [11:57] Cimi: btw.. feel free to review/approve that branch too [11:58] mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795 [11:58] Ubuntu bug 1223795 in Unity 8 "[Ubuntu shape] Inner highlight glow is not correctly rendered in Launcher icons" [High,Triaged] [11:59] #fail [11:59] Cimi: yeah... I'm afraid the UbuntuShape doesn't do it correctly. [11:59] mzanetti, https://bugs.launchpad.net/unity8/+bug/1246688 [11:59] Ubuntu bug 1246688 in Unity 8 "[Launcher] Icons don't fill the UbuntuShape" [Low,Triaged] [12:00] yeah... I guess it's sort of the same as the other [12:11] greyback: mzanetti: approved [12:11] tsdgeos: thanks [12:11] veebers: ^ [12:11] thanks! [12:25] tsdgeos: ok, so built 5.2 in chroot, and all unity8 dependencies. It starts, but crashes here: http://pastebin.ubuntu.com/6335431/ [12:26] just find it hard to believe launcherbackend doing something funny, that only 5.2 shows [12:28] greyback: it's not a crash [12:28] it's an assert [12:28] QDBusArgument: read from a write-only object [12:28] sorry, yes [12:28] oh, probably fails as dbus not working inside the chroot [12:29] hmmm [12:30] greyback: i'd say something like that yeah [12:30] QVariant variant = m_accounts->getUserProperty(m_user, "com.canonical.unity.AccountsService", "launcher-items"); [12:30] probably ends up with a "null" variant [12:30] that with variant.value() [12:30] returns a "null" QDBusArgument [12:30] and then we try to read from it [12:30] agreed [12:30] and qt is unhappy [12:31] still it's weird that is crashing instead of just saying "null" [12:31] maybe crashes because you're on debug mode? [12:33] no idea === salem_ is now known as _salem [12:33] mzanetti, Unable to assign SearchHistoryModel to QQuickListModel from QML. [12:34] ever seen this? I can't find any info on it. [12:34] huh? [12:34] ah right === _salem is now known as salem_ [12:34] * mzanetti confused QQuickListModel with the launchers QuickListModel [12:34] nic-doffay: you forgot to qmlRegisterType it [12:35] mzanetti, I def did. [12:35] did forget it or you did register it? [12:35] mzanetti, here's the line I added: qmlRegisterType(uri, 0, 1, "SearchHistoryModel"); [12:35] that does look ok [12:36] nic-doffay: ah sure. unfortunately QStringListModel isn't a QQuickListModel [12:36] mzanetti, where does QQuickListModel come into play though? [12:37] nic-doffay: I assume you didn't delete Components/SearchListModel.qml. And wherever you import Components before importing Unity it'll pick that one up which is in fact a QQuickListModel [12:38] mzanetti, I deleted it. [12:38] gah qt docs URLs changed /again/ [12:39] nic-doffay: still not working? [12:39] mzanetti, well I deleted it from the start. [12:39] nic-doffay: I'd need to see code then [12:39] mzanetti, let me go with a fresh build quickly [12:48] greyback: yep [12:48] #ifdef QT_DEBUG [12:48] qFatal("QDBusArgument: read from a write-only object"); [12:48] #else [12:48] qWarning("QDBusArgument: read from a write-only object"); [12:48] #endif [12:48] tsdgeos: aha [12:49] greyback: that's pretty common in qt [12:49] the debug mode is more crashy [12:49] so you fix your crap [12:49] tsdgeos: anyway, I'm just using the fake modules for now. [12:49] wouldn't it b easier to just use qWarning and when wanted export QT_FATAL_WARNINGS=1 ? [12:49] tsdgeos: the good news: unity8 kinda works [12:49] tsdgeos: the bad news: lots of things are broken [12:49] like? [12:49] and I'm getting scenegraph renderer crashes [12:50] not good [12:50] tsdgeos: I swipe the greeter away, it disappears immediately, I see "QTransform::translate with NaN called" errors [12:50] hopefully a math problem on our end [12:51] yep [12:52] the indicators Tabs thing crashes when I click on it, giving the SG renderer error [12:52] nothing at all shows in Dash [12:52] possibly due to that math bug again [12:53] greyback: so the thing is, when do we want to tackle those? [12:53] you do it now? or? who and when? [12:53] tsdgeos: well I think the sooner Qt bugs are reported, the better [12:53] we should do before 5.2 is officially out in case it's a qt bug it can try to get fixed before .0 [12:53] and that said [12:53] it's lunch time [12:53] :D [12:53] especially if it's in renderer [12:53] right [12:53] also JS engine [12:54] lots of changes, we need to make sure we find the bugs that effect us now [12:55] mzanetti, here's the code. I assumed I'd gotten rid of everything qml related by just deleting the file... lp:~nicolas-doffay/+junk/search-history-model [12:56] mzanetti, ping [12:56] fginther: hi [12:56] fginther: so. seems the packages have landed [12:57] mzanetti, good, sounds like you needed some jenkins updates: [12:57] ? [12:57] fginther: but as it's notify-osd I think we'd need to upgrade the otto machines because it won't be pulled in [12:57] just with our tests [12:58] fginther: notify-osd 0.9.35+14.04.20131030.1-0ubuntu1 is the required one === MacSlow is now known as MacSlow|lunch [13:00] mzanetti, the most recent tests are using 0.9.35+13.10.20130917.1-0ubuntu1. I should be able to get it the test runner to pull in the updated package. [13:01] fginther: I had the de.archive.ubuntu.com mirror today, that didn't show it either. I switched to the main mirror and it appeared [13:02] mzanetti, I'm running a test here: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/240/console - it found the right version [13:02] nic-doffay: Dash/ScopeView.qml [13:02] nic-doffay: property ListModel searchHistory [13:03] mzanetti, If it works, I'll just need to update the cu2d-config to update the parent -ci/-autolanding jobs [13:03] nic-doffay: make it a property QtObject searchHistory [13:03] fginther: cool. seems we're getting close :) [13:04] mzanetti, ah cool nice one [13:04] nic-doffay: FYI: "ListModel" in QML is actually the "QQuickListModel" [13:04]