[07:07] <mzanetti> o/
[07:07] <mzanetti> MacSlow: did you solve your issue yesterday?
[07:08] <MacSlow> mzanetti, yes
[07:08] <mzanetti> ok. good
[07:08] <MacSlow> mzanetti, got it sorted out
[07:14] <veebers> mzanetti,  MacSlow: morning :-) Hey I'm running those Notification autopilot tests on the VM (20 times in a row) and I'm not getting any failures :-\
[07:14] <veebers> (although on the latest CI job I fired off today I see that all the tests failed on the devices, I've emailed Omer re: that)
[07:14] <MacSlow> veebers, ok
[07:15] <mzanetti> hi veebers. ok. thanks for the updates
[07:15] <mzanetti> MacSlow: does it work on the device for you?
[07:15] <veebers> mzanetti, mzanetti: just a fyi
[07:15] <mzanetti> veebers: veebers: thanks
[07:15] <mzanetti> :P
[07:16] <MacSlow> mzanetti, no it did not
[07:16] <veebers> mzanetti: it works for me (although I haven't tried with the latest flash)
[07:29] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity8/launcher-fix-displacement/+merge/181433
[07:29] <mzanetti> tsdgeos: I got around one of the issues
[07:41] <tsdgeos> nice
[07:41] <mzanetti> tsdgeos: is Saviq already gone from today?
[07:42] <Saviq> mzanetti, am here
[07:42] <mzanetti> ah ok :)
[07:46] <tsdgeos> mzanetti: i guess a test of this is impossible
[07:46] <mzanetti> tsdgeos: hmm... nothing is impossible...
[07:46] <mzanetti> tsdgeos: not sure how to do it in a way it actually makes sense tho
[07:46] <mzanetti> well, actually...
[07:46] <mzanetti> tsdgeos: I'll give it a shot
[07:47] <mzanetti> I'll come back to you in a bit
[07:47] <tsdgeos> i hate that sentence :D Solving the Traveliing Salesman problem in linear time is impossible
[07:47] <mzanetti> :D
[07:55]  * didrocks is desperatly trying to find in what type aa{ss} is translated to by Qtdbus…
[07:55] <didrocks> tried: QArray<QHash<QString, QString>>, QArray<QMap<QString, QString>>, QList<QHash<QString, QString>>, QList<QMap<QString, QString>>
[07:58] <tvoss_> didrocks, QVector<QMap<QString,QString>> might be the right one
[07:59] <tsdgeos> mzanetti: i'm not sure how to repro/what to see in the bug fixed by https://code.launchpad.net/~mzanetti/unity8/launcher-fix-displacement/+merge/181433
[07:59] <didrocks> tvoss_: doesn't seem so :/ QObject::connect: No such signal com::canonical::SystemImage::UpdateAvailableStatus(bool, bool, int, int, QString, QVector<QMap<QString, QString>>, QString)
[08:00] <mzanetti> tsdgeos: take trunk and start dragging an item slowly downwards
[08:00] <didrocks> (whole signature is 'bbiisaa{ss}s')
[08:00] <Saviq> veebers, hey, I'll try the notifications ap tests here
[08:01] <Saviq> veebers, anything I should be aware of?
[08:01] <tsdgeos> mzanetti: yes? don't see anything obviously wrong
[08:01] <mzanetti> tsdgeos: really?
[08:01] <tsdgeos> didrocks: what does qdbus say?
[08:01] <tsdgeos> mzanetti: maybe i need to drag more slowly or more distance?
[08:02] <mzanetti> tsdgeos: what happens is this:
[08:02] <tsdgeos> ok
[08:02] <tsdgeos> so is the thing that two icons get one under the other?
[08:02] <mzanetti> right
[08:02] <didrocks> tsdgeos: the "No such signal" I pasted above
[08:03] <mzanetti> didrocks: qdbus is a command line tool
[08:03] <tsdgeos> didrocks: i mean qdbus command line
[08:03] <tsdgeos> qdbus /something/foo/bar
[08:03] <tsdgeos> will list the methods
[08:03] <didrocks> using the Object path?
[08:03] <tsdgeos> didrocks: first service and them method
[08:03] <tsdgeos> just start from the beginniing
[08:03] <tsdgeos> i.e.
[08:03] <tsdgeos> qdbus
[08:04] <tsdgeos> then find in the output what you want
[08:04] <mzanetti> (or qdbus --system if on the system bus)
[08:04] <tsdgeos> qdbus whatIWant and continue from there
[08:04] <didrocks> ok, let's see…
[08:04] <tsdgeos> it's not unlike the almost impossible to use gdbus command line :D
[08:04] <didrocks> need first to figure in which package is /usr/lib/x86_64-linux-gnu/qt5/bin/qdbus
[08:04] <didrocks> tsdgeos: ahah ;)
[08:04] <tsdgeos> but easier
[08:04] <tsdgeos> qdbus-qt5: /usr/lib/x86_64-linux-gnu/qt5/bin/qdbus
[08:05] <didrocks> thanks tsdgeos
[08:06] <didrocks> (ok, bash completion is impressive, I must say)
[08:06] <didrocks> but
[08:06] <didrocks> $ qdbus --system com.canonical.SystemImage /Service
[08:06] <didrocks> method QString org.freedesktop.DBus.Introspectable.Introspect()
[08:06] <didrocks> signal void com.canonical.SystemImage.Canceled()
[08:06] <didrocks> Erreur de segmentation (core dumped)
[08:06] <didrocks> not that nice :p
[08:06] <mzanetti> hmpf... I get that quite a lot too, lately
[08:07] <tsdgeos> ah
[08:07] <tsdgeos> i fixed that
[08:07] <mzanetti> didrocks: try --literal
[08:07] <tsdgeos> sorry
[08:07] <tsdgeos> also
[08:07] <tsdgeos> install qt4-qdbus
[08:07] <tsdgeos> and run
[08:07] <tsdgeos> QT_SELECT=qt4  qdbus --system com.canonical.SystemImage /Service
[08:07] <tsdgeos> but if that's happening
[08:07] <didrocks> ok
[08:07] <tsdgeos> it'll probably spit the "raw" dbus thing
[08:07] <didrocks> the package isn't qt4-qdbus, looking for it, one sec
[08:07] <tsdgeos> and not a QVector<things>
[08:08] <tsdgeos> didrocks: qdbus: /usr/lib/x86_64-linux-gnu/qt4/bin/qdbus
[08:08] <didrocks> perfect!
[08:08] <didrocks> indeed, no segfault with the qt4 version
[08:08] <didrocks> signal void com.canonical.SystemImage.UpdateAvailableStatus(bool is_available, bool downloading, int available_version, int update_size, QString last_update_date, QDBusRawType::aa{ss} descriptions, QString error_reason)
[08:08] <didrocks> so, you're right, it's a "Raw" type
[08:09] <didrocks> I think then I can't pass it directly to the QML side, I need to unmangle it first?
[08:10] <tsdgeos> probably, what's aa{ss}? an array of arrays of maps?
[08:11] <tsdgeos> mzanetti: i'm getting lots of
[08:11] <tsdgeos> file:///home/tsdgeos_work/phablet/unity8/Launcher/LauncherPanel.qml:142: Unable to assign [undefined] to int
[08:11] <tsdgeos> file:///home/tsdgeos_work/phablet/unity8/Launcher/LauncherPanel.qml:143: Unable to assign [undefined] to int
[08:12] <didrocks> tsdgeos: that's what is weird, d-feet shows it as just an array of dict (and that's what barry sends apparently).
[08:12] <tsdgeos> mzanetti: i guess unrelated to the patch, maybe you can do a count: model ? model.count : count or something?
[08:12] <didrocks> tsdgeos: I'll see if he's sending the right thing, but for me, it should just be an a{ss} for an array of dict { string: string }
[08:13] <didrocks> tsdgeos: thanks for the qdbus command line trick! really helpful! :)
[08:13] <tsdgeos> no worries
[08:13] <tsdgeos> yeah that extra a looks weird
[08:13] <mzanetti> tsdgeos: hmm... this will go away soon... It tries to read the count and progress emblem's values which so far are only implemented in the mock backend
[08:13] <mzanetti> tsdgeos: I'll create a branch soon that adds them to the real model
[08:13] <tsdgeos> ok
[08:15] <tsdgeos> didrocks: if you need help unboxing stuff have a look at this http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/17 specially the operator<< and operator>> for dbus and qDBusRegisterMetaType
[08:15] <tsdgeos> guess should help
[08:15] <didrocks> tsdgeos: thanks for the example! will definitively have a look after this meeting
[08:24] <Saviq> MacSlow, veebers the notifications tests passed for me locally on maguro
[08:25] <Saviq> mzanetti, have some minutes to test on mako ↑?
[08:25] <mzanetti> can do, yes. Just finishing that test first. shouldn't take long
[08:26] <Saviq> mzanetti, ok, actually I think I found the issue already
[08:26] <Saviq> MacSlow, veebers "Service name already taken."
[08:26] <Saviq> real shell isn't stopped before starting the tests probably
[08:27] <Saviq> need to talk to Omer
[08:28] <Saviq> yup
[08:36] <MacSlow> Saviq, veebers: notify-osd there still running?!
[08:36] <Saviq> MacSlow, no, unity8 is
[08:37] <MacSlow> ah ok
[08:37] <Saviq> MacSlow, "real" shell is restarted for app tests
[08:37] <Saviq> MacSlow, but should be stopped for unity8 ones
[08:37] <MacSlow> makes sense :)
[08:40] <Saviq> MacSlow, switching to Needs Review, then, it feels solid here
[08:41] <Saviq> MacSlow, just started 20 runs in a row, let's see if I get any failures
[08:44] <MacSlow> Saviq, ok *fingers.crossed*
[08:45] <veebers> Saviq: ah nice catch with that. I' emailed Omer earlier, i'll follow that up with what you found
[08:45] <Saviq> veebers, first thing I'm looking for now ;)
[08:45] <Saviq> veebers, have been fighting for a few days in IoM with that
[08:45] <Saviq> veebers, just to notice that the real shell isn't stopped ;)
[08:46] <sil2100> jamesh: hi! Any luck with integration tests for the mediascanner scope?
[08:46] <veebers> Saviq: oh how annoying :-)
[08:47] <Saviq> veebers, yeah, had exactly the same with UTAH
[08:48] <veebers> Saviq, MacSlow: ugh I think I've done it again. Running the tests on the VM 20x in a row with no issues. I forgot to enabled recording (and thus potentially trigger  swapping etc.)
[08:48]  * veebers starts tests again
[08:59] <nic-doffay> Saviq, with a Flickable/ListView is there any QML means to clip the contents if it goes below the height of the view? I can provide a screenshot to illustrate the issue if I'm not being clear.
[08:59] <nic-doffay> mzanetti, ^
[09:00] <nic-doffay> good chance you'll have an idea too
[09:00] <Saviq> clip: true
[09:00] <Saviq> nic-doffay, ↑
[09:00] <nic-doffay> Saviq, what component is that a member of out of interest?
[09:00] <Saviq> nic-doffay, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.clip-prop
[09:00] <nic-doffay> Saviq, ta
[09:00] <Saviq> http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#clip-prop
[09:00] <Saviq> previous url wrong
[09:03] <Cimi> tsdgeos, quick question
[09:03] <Cimi> tsdgeos, adding time-out etc etc to hud reveal, which file/place?
[09:03] <Cimi> (I can check but save me time)
[09:05] <mzanetti> tsdgeos: added a test
[09:05] <tsdgeos> Cimi: so you want to delay the hud "big button" appearing?
[09:05] <tsdgeos> or the hud itslef opening?
[09:05] <Cimi> tsdgeos, no let is stay on screen for longer
[09:06] <tsdgeos> Cimi: BottomBar/*qml
[09:06] <Cimi> tsdgeos, thanks boss
[09:06] <tsdgeos> mzanetti: oka
[09:06] <tsdgeos> Cimi: yw
[09:07] <Cimi> tsdgeos, you also know why we have the ubuntushape outside the hud button? is there a bug opened for that?
[09:07] <tsdgeos> mzanetti: you have a wait!
[09:07] <mzanetti> tsdgeos: oops... that was for me being able to see what happens
[09:07] <mzanetti> I'll remove it
[09:07] <jamesh> sil2100: sorry, was at my team's standup.  I've put together this test for the media scanner scopes: https://code.launchpad.net/~jamesh/unity-scope-mediascanner/test-against-mediascanner/+merge/181482
[09:07] <tsdgeos> Cimi: no idea, something broke at some stage but didn't have time to have a look
[09:07] <tsdgeos> Cimi: and no i think there's no bug open
[09:07] <Cimi> tsdgeos, ok
[09:07] <Cimi> tsdgeos, somewhere in the sdk?
[09:07] <tsdgeos> Cimi: if you fix it while you're there it'd be awesome :-)
[09:08] <Cimi> tsdgeos, I hate it so I'll fix it
[09:08] <tsdgeos> Cimi: i guess, that code has been left unchanged for a while
[09:08] <jamesh> sil2100: it starts up a private copy of the media scanner, and loads up the scopes via the UnityScopeLoader API and makes sure it can provide results from the scanned media directory
[09:08] <tsdgeos> Cimi: otoh we may have been abusing stuff :D
[09:08] <Cimi> rule is: let cimi hate something visually he will fix it
[09:08] <Cimi> Saviq, learn that ^
[09:08] <Saviq> :D
[09:08] <mzanetti> tsdgeos: cleaned up
[09:09] <Cimi> Saviq, btw we should all work on maguro
[09:09] <Cimi> Saviq, performance is so bad compared to mako
[09:09] <Saviq> Cimi, wait for Mir ;)
[09:09] <Cimi> Saviq, hah
[09:10] <tsdgeos> brr
[09:10] <tsdgeos> mzanetti: how did this work?
[09:10] <tsdgeos> 135	- compare(LauncherModel.get(5).iconName, item4Name)
[09:10] <tsdgeos> 136	- compare(LauncherModel.get(5).iconName, item5Name)
[09:10] <Saviq> Cimi, bug #1215047
[09:10] <Cimi> Saviq, I think it's due to screenshots
[09:10] <mzanetti> tsdgeos: it didn't :D
[09:10] <Cimi> Saviq, too
[09:10] <Saviq> Cimi, there is something happening indeed
[09:10] <tsdgeos> mzanetti: oh, so test failed?¿?¿?
[09:10] <Saviq> Cimi, it was better before - we'll get to it
[09:10] <Cimi> Saviq, sometimes I get black screenshots and performance sucks
[09:10] <didrocks> tsdgeos: so, from the spec, it's an array of dict of string: string
[09:10] <mzanetti> tsdgeos: no... well undefined == undefined :D
[09:10] <Saviq> Cimi, bug #1213038
[09:11] <didrocks> tsdgeos: now, I have to find how to unmarshall the QDBusRawType
[09:11] <mzanetti> tsdgeos: seems two wrongs make it right in QML
[09:11] <tsdgeos> mzanetti: lol
[09:11] <Cimi> Saviq, saw on mako it's still fast
[09:11] <Cimi> Saviq, so we definitely need to work on nexus to realise we have bugs :)
[09:11] <Saviq> Cimi, but still there is some regression
[09:11] <Saviq> Cimi, they're all nexus ;)
[09:11] <Cimi> Saviq, yes that's what I am saying
[09:11] <Saviq> Cimi, and I only have maguro ;)
[09:11] <Cimi> lol
[09:11] <Cimi> galaxy
[09:11] <Cimi> maguro
[09:11] <Saviq> Cimi, so I *know*
[09:11] <Cimi> ok
[09:12] <tsdgeos> didrocks: that thing i point you has to unbox a "string string" pair, you "just" do something similar and hope it works :D
[09:12] <didrocks> tsdgeos: I'll hope then ;)
[09:14] <sil2100> jamesh: thanks! The test looks ok and I think it's enough to enable the scope for daily-releasing - later we'll have to ask the unity guys to write a quick AP test that would check in unity if the mediascanner scope works, but due to FF we'll do that after releasing
[09:14] <sil2100> jamesh: btw. I think you'll need a dbus build-depends
[09:14] <sil2100> jamesh: (see jenkins CI on your merge)
[09:14] <jamesh> sil2100: yeah.  I haven't updated the build-depends yet
[09:21] <Mirv> for anyone concerned, 4 months newer compiz just got uploaded to saucy :) https://launchpad.net/ubuntu/saucy/+source/compiz/1:0.9.10+13.10.20130822-0ubuntu1
[09:22] <Saviq> Mirv, oh!
[09:22] <Mirv> thanks to the developers and sil2100 wrapping it up
[09:22] <Saviq> Mirv, nice buglist...
[09:23] <sil2100> ...;)
[09:23] <jamesh> that is some changelog
[09:24] <sil2100> bregma, andyrock: ^
[09:25] <Saviq> Mirv, https://bugs.launchpad.net/unity8/+bug/1207269/comments/2
[09:27] <andyrock> sil2100, Mirv Thanks! :D
[09:27] <andyrock> smspillaz, ^
[09:28] <Mirv> Saviq: great news! and I can actually confirm it being fixed, since I've just upgraded.
[09:30] <Saviq> Mirv, cool
[09:45] <larsu> Wellark: what are the reasons for commit 683 and 684 in the unity-theme-icon-provider merge?
[09:48] <Wellark> larsu: trying to accommodate the gicon provider MR, but we have to drop them as QIcon::fromTheme() can't handle them at the moment
[09:48] <Wellark> larsu: and the /usr/share/pixmaps is going away from that MR
[09:48] <Wellark> it has to be handled directly in QIconLoader
[09:50] <larsu> Wellark: this is supposed to be a provider for icon themes. I don't recommend putting paths in there that are not mentioned in the spec
[09:53] <Wellark> larsu: the spec says the themes can be extended and notify-osd icons do follow the spec. It's just that QIconLoader does not support themes extending to multiple base dirs even though the spec mandates it must be supported.
[09:54] <Wellark> but that said. it's not even technically possible ATM to use QIcon::fromTheme() to load the notify-osd icons
[09:55] <Wellark> larsu: I will update the MR
[09:56] <larsu> Wellark: I don't understand. I thought the spec only allows extension through XDG_DATA_DIRS...
[09:56]  * larsu reads the spec
[09:57] <Wellark> larsu: "or by other means depending on the library/tool"
[09:57] <jamesh> sil2100: build-depends updated, and passed in Jenkins: https://code.launchpad.net/~jamesh/unity-scope-mediascanner/test-against-mediascanner/+merge/181482
[09:58] <larsu> Wellark: depending on the library? I can find "depending on the application" (which is totally different)
[09:59] <Wellark> larsu: well, ok. the library may/must offer means for applications to extend list of directories.
[10:00] <Wellark> which both GIcon and QIcon does provide
[10:00] <larsu> Wellark: right. But to get to the crux: why aren't the notify-osd icons in ubuntu-mono-*?
[10:00] <larsu> or alternatively, why doesn't it install icons into hicolor?
[10:01] <Wellark> larsu: well, I don't know. but what I do know is that QIcon does not handle the base dirs properly
[10:01] <seb128> larsu, Wellark: what notify-osd is doing (e.g /usr/share/notify-osd/icons/hicolor) is common
[10:02] <seb128> larsu, Wellark: is that what you are discussing?
[10:02] <seb128> $ find /usr/share/ -name hicolor
[10:02] <seb128> /usr/share/file-roller/icons/hicolor
[10:02] <seb128> /usr/share/yelp-xsl/icons/hicolor
[10:02] <seb128> /usr/share/banshee/icons/hicolor
[10:02] <seb128> /usr/share/seahorse/icons/hicolor
[10:02] <seb128> etc etc etc
[10:02] <larsu> seb128: ah, and notify-osd then adds that path to the icon search path?
[10:02] <seb128> larsu, yes
[10:03] <larsu> seb128: thanks, that makes my initial suggestions moot. Better would be: instead of hard-coding the notify-osd path, we should provide a way for applications to add a path there
[10:04] <seb128> larsu, main.c in notify-osd does
[10:04] <seb128> 	/* Init some theme/icon stuff */
[10:04] <seb128> 	gtk_icon_theme_append_search_path(gtk_icon_theme_get_default(),
[10:04] <seb128> 	                                  ICONS_DIR);
[10:04] <seb128> with
[10:04] <seb128> #define ICONS_DIR  (DATADIR G_DIR_SEPARATOR_S "notify-osd" G_DIR_SEPARATOR_S "icons")
[10:04] <seb128>  
[10:04] <larsu> Wellark: why can't the "new" notify-osd not do this? ^^
[10:04] <seb128> larsu, that's basically what most softwares do when they install custom icons ... no need to clutter the system theme for icons specifics to your app
[10:04] <larsu> seb128: understood, that makes sense
[10:05] <larsu> Wellark: except it should use the QIcon:: function, of course
[10:05]  * seb128 steps out, glad I could help :-)
[10:05] <larsu> seb128: thank you!
[10:06] <seb128> yw ;-)
[10:06] <Wellark> seb128, larsu: could you guys trigger a rebuild? http://s-jenkins:8080/job/hud-ci/114/rebuild
[10:06] <Wellark> there was some random glitch on i386
[10:07] <Wellark> larsu: isn't it inside the shell?
[10:07] <Wellark> or is it it's own process?
[10:08] <seb128> well, change notify-osd to install the icons into an unity8 subdir then
[10:08] <larsu> Wellark: can't trigger a rebuild. No account.
[10:08] <larsu> Wellark: and what seb128 said ;)
[10:09] <seb128> larsu, Wellark: I did trigger a retry on CI
[10:09] <Wellark> seb128: thanks!
[10:09] <seb128> yw
[10:10] <Wellark> larsu, seb128: well, as I said, the QIcon::fromTheme can't load the notify-osd icons anyway ATM. so notify-osd (QML) has to use it's own loader for now anyway and it can do whatever it wants
[10:10] <Wellark> but the thing to remember is that inside the shell QIcon::fromTheme() and related functions are static
[10:11] <Wellark> so if any of the shell components mess with the paths then that can break the rest of the shell
[10:12] <seb128> well, if it's too difficult, seems like we should just move those icons to the theme
[10:12] <seb128> and be done with it
[10:12] <Wellark> so therefore inside the shell I would use just single icon provider with all the paths set in single location so nobody can mess them up by accident
[10:12] <larsu> Wellark: adding the path to the loader messes with all applications, including the shell
[10:12] <Wellark> larsu: only inside a single process
[10:12] <Wellark> larsu: oh, I misunderstood what you mena
[10:12] <Wellark> *meant
[10:13] <Wellark> yes, as I said what ever paths we add to the unity-theme-icon-provider will be set for all the apps using that loader
[10:13] <Wellark> and therefore we have to be careful what we put there
[10:14] <Wellark> adding notify-osd path would not do any harm (if qicon could actually load them..)
[10:14] <larsu> Wellark: no, we should not put anything there. If the shell needs the notify-osd icons, it should add the path itself
[10:15] <Wellark> well, then we need API for that.
[10:15] <larsu> we have API for that
[10:15] <Wellark> and it's beyound just a "simple" loader
[10:15] <Wellark> from QML side that is
[10:16] <larsu> why do we need api from the qml side?
[10:16] <Wellark> larsu: but as I said, I will remove all that notify-osd stuff now anyway
[10:16] <smspillaz> Mirv: andyrock: oh awesome, cheers
[10:16] <larsu> Wellark: /usr/share/pixmaps as well?
[10:17] <Wellark> larsu: yep. it will be moved to QIcon
[10:17] <larsu> Wellark: okay that's good. We disagree but I get my way in practice :)
[10:17] <Wellark> hopefully
[10:17] <Wellark> larsu: https://codereview.qt-project.org/#dashboard,1001774
[10:18] <Wellark> larsu: I don't feel we have disagreed. sorry if you feel that way
[10:18] <Wellark> O
[10:18] <larsu> Wellark: I'm fine to leave pixmaps in until the qt patch trickles into distro
[10:18] <Wellark> I'm simply trying to have a productive discussion
[10:18] <Wellark> larsu: well, on the current form the pixmaps does not work
[10:19] <larsu> Wellark: oh yeah of course it was productive :)
[10:19] <larsu> Wellark: why? Doesn't it load the icon formats from there?
[10:19] <Wellark> larsu: getting icons from pixmaps needs "QIconLoader::loadIcon: search icons directly from base dirs"
[10:20] <larsu> intereseting
[10:20] <larsu> *interesting
[10:25]  * greyback moving to office, back in 30
[10:28] <Saviq> mzanetti, you can see "Pin to launcher" changing into "Remove from launcher" when you click on the action
[10:29] <larsu> how can I make a qml module depend on another one?
[10:29] <larsu> a module writtin in c++, that is
[10:29] <larsu> *written
[10:30] <mzanetti> Saviq: hmpf... nasty
[10:31] <Saviq> mzanetti, yeah, in this instance I think it'd be better to have just a static list instead of a model
[10:31] <Saviq> mzanetti, that would be assigned to the popover on open
[10:32] <Saviq> mzanetti, so that we get atomic changes
[10:32] <Saviq> mzanetti, also, something fun: http://ubuntuone.com/5XA549ihXvixoIiDHe9vCU
[10:32] <Saviq> mzanetti, mouse cursor is drawn wrong (positioned some GUs down from where it actually is)
[10:34] <mzanetti> Saviq: hmm... it shouldn't be that much :/
[10:35] <Saviq> mzanetti, IIUC it shouldn't move at all until you cross the threshold, right?
[10:35] <mzanetti> no...
[10:35] <Saviq> mzanetti, so something's weird - as I'm able to drag it out of its place without the quicklist disappearing
[10:35] <mzanetti> that's ok
[10:35] <mzanetti> the quicklist only disappears once you drag it more than 1.5 gu's
[10:36] <Saviq> mzanetti, why wouldn't it let me drag the item initially then?
[10:36] <Saviq> mzanetti, some threshold before which no dragging happens?
[10:36] <mzanetti> ?
[10:37] <Saviq> mzanetti, see the video, I started moving the mouse around and the icon didn't move
[10:37] <Saviq> mzanetti, at some point it starts to follow the mouse
[10:38] <Saviq> mzanetti, again, I was doing it *on* the icon - the cursor is recorded wrong for some reason
[10:38] <mzanetti> I don't know why it is off in your video
[10:38] <mzanetti> can't reproduce here
[10:38] <mzanetti> ah ok
[10:39] <mzanetti> well, the mousearea itself has some threshold before it recognizes a drag
[10:39] <mzanetti> seems a big much in your video tho
[10:40] <Saviq> mzanetti, right, might be that
[10:40] <Saviq> mzanetti, anyway, theming approved
[10:40] <Saviq> mzanetti, looking nice :)
[10:40] <mzanetti> cool, thanks. I have a fix for the quicklist changing its text already
[10:40] <mzanetti> Saviq: will just unsed the model before destroying it
[10:40] <Saviq> mzanetti, ah cool
[10:41] <mzanetti> and I think in the end we want a model here. once we have radio buttons and all that stuff in there
[10:41] <Saviq> mzanetti, maybe
[10:41] <mzanetti> but yeah, once clicked it shouldn't change the entries in the fading out animation
[10:41] <tsdgeos> wot?
[10:41] <Saviq> mzanetti, btw, am I crazy to notice such things? :D
[10:41] <tsdgeos> $ ls /hope-you-dont-have-this-file-around-marked-as-write-for-all-system-admin-client
[10:41] <tsdgeos>  /hope-you-dont-have-this-file-around-marked-as-write-for-all-system-admin-client
[10:41] <mzanetti> no
[10:41] <tsdgeos> ?¿
[10:42] <Saviq> tsdgeos, :F
[10:42] <mzanetti> tsdgeos: I'd burn the machine
[10:42] <Saviq> tsdgeos, yeah, call in the exorcist
[10:42] <tsdgeos> ah that was me :D
[10:42] <tsdgeos> https://code.launchpad.net/~aacid/system-image-client/imagewriter_test/+merge/114869
[10:42] <mzanetti> lol
[10:42] <Saviq> hehe
[10:43] <tsdgeos> good guy google
[10:43]  * larsu is afraid nobody read his question
[10:43] <tsdgeos> larsu: what do you mean with depend?
[10:44] <vesar> Saviq, are these instructions still valid: https://unity.ubuntu.com/getinvolved/development/unity8/ ?  if I branch lp:unity/8.0 and look with qlog the latest commit is from early July? So something is wrong here.
[10:44] <Saviq> vesar, no
[10:44] <Saviq> vesar, lp:unity8
[10:44] <Saviq> kgunn, could you update ↑?
[10:44] <larsu> tsdgeos: depend on another qml module. Importing my module should always automatically import the other one
[10:45] <vesar> Saviq, ok cool. thanks.
[10:45] <larsu> tsdgeos: my specific problem is that ubuntu-ui-toolkit provides an image provider that qmenumodel needs
[10:45] <tsdgeos> larsu: i guess you need to do some stuff in your plugin loading code?
[10:46] <kgunn> Saviq: sure...man, how'd we miss that one
[10:46] <larsu> tsdgeos: yeah, that's what I was thinking. But I can't figure out what this stuff is from the documentation...
[10:46] <Saviq> kgunn, yeah, it should be autogenerated :/
[10:47] <tsdgeos> larsu: let me see if i can find something quick
[10:47] <tsdgeos> larsu: bool QQmlEngine::importPlugin(const QString & filePath, const QString & uri, QList<QQmlError> * errors)
[10:47] <tsdgeos> ?
[10:47] <Cimi> Saviq, is it ok to have the launcher shadow always on screen?
[10:47] <Cimi> Saviq, I don't think it's so nice
[10:48] <Cimi> and slows down rendering too
[10:48] <Saviq> Cimi, ok, so you *are* crazy for noticing such things
[10:48] <larsu> tsdgeos: call import in initializeEngine? Sounds easy enough :)  (I was looking for something more declarative)
[10:48] <larsu> tsdgeos: I'll try that, thanks
[10:48] <tsdgeos> larsu: yeah give it a go
[10:48] <Cimi> Saviq, hah, it was annoying me for a bit so far :D
[10:55] <om26er> Saviq, re: https://code.launchpad.net/~macslow/unity8/notification-autopilot-tests-dbus/+merge/177780 I could something to my jenkins jobs, so they will detect if the test_suite is unity8 then stop unity8 first before starting its tests, does that sound reasonable ?
[10:55] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/quicklist-unset-model-before-closing/+merge/181517
[10:55] <Saviq> om26er, yeah, exactly
[10:55] <Saviq> mzanetti, well, that will mean the text disappears
[10:56] <mzanetti> Saviq: yeah, but you can't see it
[10:56] <Saviq> mzanetti, care to layer.enable: opacityBehavior.running
[10:56] <Saviq> mzanetti, *I* can :D
[10:56] <Saviq> mzanetti, I wonder if it'd be soon enough
[10:57] <larsu> tsdgeos: calling it with `engine->importPlugin("Ubuntu.Components", uri, &errors)` gives `(<Unknown File>: The shared library was not found.)`
[10:57] <larsu> importing it from a qml file works
[10:57] <Saviq> larsu, it's a file path
[10:57] <Saviq> larsu, http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#importPlugin
[10:58] <larsu> Saviq: "a plugin named filePath"
[10:58] <Cimi> tsdgeos, btw the bug of the border is due to the ubuntushape borderSource property being deprecated
[10:58] <Saviq> larsu, plugin == file
[10:58] <mzanetti> Saviq: that makes it worse
[10:58] <larsu> Saviq: right, I thought it would resolve the path itself...
[10:58] <Cimi> tsdgeos, I'm wondering why you're using UbuntuShape here and not simply an Image
[10:58] <mzanetti> Saviq: because if the text changes, it means that the layer will be re-rendered. because that happens during fading out, it even causes flickering
[10:59] <larsu> Saviq: do you know of a function that does this without me having to find out the installed paths?
[10:59] <Saviq> larsu, 'fraid not
[10:59] <Saviq> tsdgeos, ↑ ?
[10:59] <larsu> does filePath also include the .so?
[10:59] <Saviq> larsu, yes
[11:00] <Saviq> mzanetti, right, there's no way to make the layer ignore changes - you'd have to use a ShaderEffect :/
[11:00] <tsdgeos> Saviq: larsu: nope sorry
[11:00]  * larsu is really only looking for a function that does what `import` does in qml
[11:00] <Saviq> mzanetti, which IMO should be there on layer.
[11:00] <tsdgeos> Cimi: tbh i don't exactly remember why it was a UbuntuShape
[11:00] <tsdgeos> Cimi: if you can make it look good without it, the better :D
[11:00] <Saviq> mzanetti, like layer.live: false; layer.scheduleUpdate()
[11:00] <larsu> tsdgeos: I guess nobody ever makes their modules depend on anything else?
[11:01] <tsdgeos> larsu: well, it traverses the QStringList QQmlEngine::importPathList() const and loads the module from there
[11:01] <Saviq> larsu, there's a but... isn't the "image://theme/" provider supposed to be handled in the QPA?
[11:01] <larsu> Saviq: QPA?
[11:01] <Saviq> larsu, http://qt-project.org/doc/qt-5.0/qtdoc/qpa.html
[11:02] <Cimi> tsdgeos, property actionButton seems not used here...
[11:02] <larsu> Saviq: I don't know, somebody told me it needs to go into the sdk... (which is where it is MRed to now)
[11:02] <tsdgeos> larsu: yeah tbh i'm not sure loading another module behind my back is a good idea tbh, i'd expect you to either link against it or me to have to manually specifically load it
[11:03] <Saviq> larsu, I think it's fine if the image just fails if the image provider isn't there
[11:03] <larsu> tsdgeos: fair enough. It did smell a bit hacky to me as well
[11:03] <larsu> Saviq: okay. Prefer a warning or just silently fail?
[11:03] <tsdgeos> Cimi: the code went though billions of refactors, stuff may have just rotten
[11:03] <larsu> hm, I guess there's no right place to put a warning, because we don't know the order in which plugins are loaded
[11:04] <Saviq> larsu, you won't know
[11:04] <Saviq> larsu, Qt will issue a warning about image://theme/ failing to load
[11:04] <Cimi> tsdgeos, ok I'll clean up
[11:04] <larsu> Saviq: ya, that'll do
[11:04] <larsu> Saviq, tsdgeos: thanks for your help!
[11:04] <Saviq> larsu, cheers
[11:07] <Saviq> larsu, seems QPA doesn't yet abstract the icon themes
[11:07] <Saviq> larsu, so ignore me and go for the SDK
[11:07] <larsu> Saviq: that's on its way. Thanks for checking
[11:07] <Saviq> mzanetti, LauncherPanel.qml:482: Error: Cannot assign to non-existent property "model"
[11:08] <kgunn> vesar: that wiki should be up to date now
[11:08] <dednick> larsu: ping
[11:08] <Saviq> mzanetti, failed test, too
[11:08] <larsu> dednick: hi, how are you?
[11:08] <Saviq> kgunn, thanks
[11:09] <dednick> larsu: good thanks. have a good holiday?
[11:09] <larsu> dednick: yes, quite relaxing :)
[11:09] <Mirv> Saviq: I'm hitting some qtubuntu compilation problem with Qt 5.1.1 snapshot, see bug #1215374 - qtubuntu-sensors on the other hand built fine
[11:10] <Saviq> mzanetti, or well, you can go layer.effect: ShaderEffect { live: false }
[11:10] <Saviq> mzanetti, and .scheduleUpdate that
[11:11] <Saviq> Mirv, you'll have to talk to loicm about this
[11:11] <vesar> kgunn, looks like there is still one cd ~/unity/unity8 reference. in "Running Unity 8 on devices" section.
[11:11] <mzanetti> Saviq: now it would work
[11:11] <dednick> larsu: ah. good, then i have some exitement to give you. UnityMenuModel doesnt support "out-of-menu" actions. (eg wifi access point strength & replying/callback to text messages)
[11:11] <kgunn> vesar: thanks for the proof....its early for my eyes...
[11:12] <vesar> kgunn, other than that looks good. Thanks!
[11:12] <Saviq> mzanetti, got tricksed by Repeater reparenting I see :)
[11:12] <Saviq> mzanetti, why the change to callerMargin, btw?
[11:12] <larsu> dednick: exciting!
[11:12] <dednick> larsu: i've made myself a solution in qmenumodel, but it required quite a bit of work and I need you to check if it's a viable solution in the first place.
[11:13] <dednick> larsu: lp:~nick-dedekind/qmenumodel/unitymenumodel.UnityMenuAction
[11:13] <larsu> dednick: sure. I guess you added some API to get an arbitrary action?
[11:13] <mzanetti> Saviq: oops. that slipped it
[11:13] <mzanetti> in
[11:13] <dednick> larsu: also have quite a couple of other branches proposed to qmenumodel waiting review.
[11:13] <dednick> larsu: yep, that's pretty much it.
[11:15] <larsu> dednick: ooh, interesting apprach with the observer item. I'll do a full review after lunch
[11:15] <larsu> dednick: (also of your other MRs)
[11:15] <dednick> larsu: cool. thanks :)
[11:17] <Mirv> Saviq: oh, he's on holiday it seems. anyone else who could help there?
[11:17] <Mirv> there's also some cmake path issue, I'm looking at that now
[11:18] <Saviq> Mirv, you could try racarr, but you won't be around when he comes on
[11:18] <Saviq> Mirv, I'll try and get him to have a look at the issue
[11:18] <mzanetti> Saviq: fixed this https://code.launchpad.net/~mzanetti/unity8/theme-quicklist/+merge/181223
[11:18] <Cimi> tsdgeos, indeed works with Image :)
[11:19] <Saviq> mzanetti, ok, so since we need to re-approve
[11:19] <Saviq> mzanetti, the arrow overlaps with the bubble
[11:19] <Saviq> mzanetti, you can see a darker trapezoid
[11:20] <Mirv> Saviq: ok. thanks for the pinging, then.
[11:20] <Saviq> mzanetti, either the asset needs to be tweaked
[11:20] <Saviq> mzanetti, or the style amended
[11:20] <mzanetti> Saviq: looks good here... do you have a screenshot?
[11:21] <Saviq> mzanetti, sec
[11:21] <tsdgeos> Cimi: good stuff
[11:21] <mzanetti> Saviq: ah. can see it now. only when the arrow points upwards
[11:21] <Saviq> mzanetti, yeah, it might be
[11:22] <Saviq> mzanetti, nah, downwards, too
[11:23] <Saviq> mzanetti, http://ubuntuone.com/3Lg4vFcTFSLNdhsVOvPhmH http://ubuntuone.com/5l9v9IdckRt2qYN0dGlLiX
[11:23] <Saviq> mzanetti, but the shadow on the UbuntuShape hides it more
[11:23] <mzanetti> yeah
[11:24] <Saviq> mzanetti, I wonder if it's actually possible to have a single asset for those...
[11:24] <Saviq> mzanetti, since there's a shadow at the bottom
[11:24] <mzanetti> Saviq: the shadow comes from UbuntuShape
[11:24] <Saviq> mzanetti, yeah, that's what I mean
[11:24] <Saviq> mzanetti, that we might need a different asset facing down than up
[11:25] <Saviq> mzanetti, to integrate well enough
[11:25] <mzanetti> the regular Popover suffers from this too
[11:25] <Saviq> mzanetti, yup, probably
[11:25] <mzanetti> you might want to report a bug to the SDK people
[11:25] <Saviq> mzanetti, but then it's opaque
[11:25] <Saviq> mzanetti, so I think that's on purpose
[11:26] <Saviq> mzanetti, it's supposed to "break" the outline of the popover
[11:26] <Saviq> mzanetti, and continue it around the arrow
[11:28] <Saviq> mzanetti, but for our semi-transparent usecase we might need something else
[11:29] <Saviq> mzanetti, the other nitpick - I can see a difference between the arrow and the popover itself fading out
[11:30] <Saviq> they fade out at different "speeds" (maybe easing, or simply just the fact that opacity is applied separately on each)
[11:30] <mzanetti> Saviq: imo all things that need to be fixed inside the popover
[11:31] <Saviq> mzanetti, is popover fading out internally?
[11:31] <mzanetti> Saviq: yes
[11:31] <Saviq> mzanetti, ok
[11:31] <Saviq> mzanetti, for the arrow I think you just need to talk to jounih about the assets
[11:31] <Saviq> mzanetti, show him the issue
[11:32] <Saviq> mzanetti, and see what he can think of doing (simple - just make the arrow not overlay the shape)
[11:32] <Saviq> mzanetti, or if we need something more involved - like having separate assets per-edge
[11:32] <mzanetti> Saviq: in the end the quicklist will use the pointer only on the left edge
[11:33] <Saviq> mzanetti, right
[11:33] <mzanetti> so if we're tweaking unity8, we'd need to make it work for the left edge.
[11:33] <mzanetti> Saviq: but actually timp and me came to the conclusion that there should be only one asset in the popover in greyscale
[11:33] <mzanetti> Saviq: and the coloroverlay effect should paint it the same color as the bubble
[11:34] <mzanetti> we reported a bug for that and added a TODO in the quicklists's style
[11:34] <Saviq> mzanetti, yeah, but that's a problem when it's not fully opaque
[11:34] <Saviq> mzanetti, if the arrow is supposed to "continue" the border of the shape
[11:34] <Saviq> mzanetti, that won't work with semi-transparent bubble or assets
[11:38] <mzanetti> Saviq: talked to jounih. The current bubble + arrow is subject to be rewritten with the upcoming UbuntuShape
[11:39] <mzanetti> Saviq: so this is temporary anyways
[11:39] <mzanetti> Saviq: the new ubuntushape will paint the arrow in code
[11:39] <Saviq> mzanetti, k, all approved alreadhy
[11:39] <Saviq> -h
[11:39] <Saviq> mzanetti, you're taking over unity8-autolanding today ;)
[11:40] <mzanetti> hehe
[11:41] <kgunn> greyback: tsdgeos ...so, kinda assuming you guys are running mir on touch...any weirdness ? e.g. when you touch it?
[11:41] <greyback> kgunn: umm, slightly vague question that :) I've not noticed, let me update everything and see
[11:42] <kgunn> greyback: ok...i'll be less vague...used the pending image yesterday, loaded phablet-team/mir ppa on top
[11:42] <kgunn> ui comes up nice, but when i touch it...screen goes dark, then grey (the new mir background)
[11:42] <kgunn> then ui comes up after some moments...wash, rinse, repeat...
[11:43] <kgunn> and its like the very moment i touch it
[11:44] <greyback> kgunn: yep, that's the bug we ricmm and I were fighting with the last 1.5 days. I  made fix last night, I'm waiting for ricmm to wake to see if he found it ok.
[11:45] <kgunn> greyback: oh, ok...
[12:10] <om26er> Saviq, It now stops unity8 before running its suite, I am not sure how reliable is that going to be given we had an issue in the past when the shell was killed, things went haywire
[12:15] <Saviq> om26er, you shouldn't kill it btw
[12:15] <Saviq> om26er, but initctl stop unity8
[12:15] <Saviq> om26er, it will get respawned otherwise, I think
[12:15] <om26er> Saviq, yeah, by kill I meant the initctl way :)
[12:15] <Saviq> om26er, ok :)
[12:15] <Saviq> om26er, let's see
[12:16] <Saviq> om26er, I started http://s-jenkins:8080/job/unity8-ci/727/ that was failing because of that
[12:17] <om26er> Saviq, ok, lets see
[12:30] <paulliu> Hi, I got "Module 'HudClient' does not contain a module identifier directive - it cannot be protected from external registrations.
[12:30] <paulliu>  Is there some packages I missed?
[12:37] <Saviq> paulliu, that's just a warning
[12:39] <Saviq> paulliu, https://code.launchpad.net/~saviq/unity8/hudclient-module/+merge/181545 to suppress
[12:41] <paulliu> Saviq: ok..
[13:27] <mzanetti> mterry: reviewed this: https://code.launchpad.net/~mterry/unity8/launcher-items/+merge/181061
[13:28] <mterry> mzanetti, thanks.
[13:28] <mterry> mzanetti, OK, I thought recent applications were not persistent
[13:28] <mterry> mzanetti, what are recent applications?
[13:29] <mzanetti> mterry: the last 5 used apps
[13:29] <mzanetti> mterry: not sure about the number yet
[13:29] <mzanetti> mterry: but some sort of "make the user think it's running apps" thing
[13:30] <mterry> mzanetti, and they can be interspersed among the pinned ones?  (order-wise)
[13:30] <mzanetti> mterry: they are always added at the end
[13:30] <mzanetti> mterry: when the user moves them around they will get pinned
[13:31] <mzanetti> mterry: if the user moves a pinned one in between the recent ones, yes, they can be mixed
[13:31] <mterry> mzanetti, ok.  So they could be stored as a separate list maybe
[13:31] <mterry> oh, nope
[13:31] <mzanetti> mterry: but as recent ones disappear over time they will sort themselves again towards the end of the list
[13:31] <mterry> sure
[13:32] <mterry> OK, that will take some tweaking to handle...
[13:32] <mzanetti> mterry: also keep in mind that the QSettings thing in your branch is temporary
[13:32] <Saviq> greyback, standup
[13:32] <Saviq> greyback, notes ;)
[13:32] <mterry> mzanetti, sure.  But the desktop reading tests were testing the backend handling, not the qsettings reading
[13:32] <mterry> I mean, that was involved, but still useful when we swap out parser
[13:32] <mzanetti> mterry: yes, I agree
[13:33] <mterry> mzanetti, QSettings isn't a good parser, I hear?  (Can't handle some kinds of desktop files?)
[13:33] <mzanetti> mterry: QSettings parses ini file format
[13:34] <mzanetti> mterry: .desktop files are not ini files (despite being quite similar)
[13:34] <mterry> mzanetti, list format is different, I believe.  Can't remember other differences
[13:34] <mterry> mzanetti, I was surprised Qt didn't have anything for desktop files
[13:35] <mzanetti> true
[13:35] <mzanetti> well, there are no .dekstop files on non-linux platforms
[13:35] <mzanetti> and on linux qt people usually use the KDE stuff
[13:41] <Saviq> MacSlow, greyback did a new empty doc
[13:41] <mzanetti> will dandrader eventually come back or did he get lost somewhere?
[13:41] <Saviq> mzanetti, he's away until the 27th ;)
[13:41] <greyback> Saviq: no I haven't, not yet anyway
[13:41] <Saviq> greyback, ah
[13:42] <mzanetti> he won't recognize the phone any more when he updates it for the first time
[13:42] <Saviq> mzanetti, so back in September, effectively
[13:42] <Saviq> mzanetti, :)
[13:42] <Saviq> greyback, I'll set the docs up
[13:42] <Saviq> greyback, gimme 5
[13:42] <greyback> Saviq: alright so
[13:43] <mzanetti> mterry: another thing comes into my mind: We need to sync with dconf because we need to be able to lock some default items into the launcher
[13:44] <mzanetti> mterry: nothing really that's changing your merge right now, but just to keep it in mind that this is where it's going
[13:44] <mterry> mzanetti, hmm, k
[13:45] <mzanetti> mterry: or, we just set an additional flag in accountsservice after the initial loading. something like "locked" true/false
[13:45] <mzanetti> that should do too I guess and still seems cleaner than constant syncing
[13:46] <mzanetti> mterry: ah... and if I removed all the apps from my launcher, how can I restore them? :D
[13:46] <mterry> mzanetti, sure.  We'd likely have to do something so fine grained, I think gsettings only lets us lock at key level, not element-of-list-value level
[13:47] <mterry> mzanetti, well, that's a good point too, if you remove all apps, you'll pop up with the default list again
[13:47] <Saviq> greyback|food, MacSlow done, it just has August in, now
[13:48] <mzanetti> mterry: right... need yet another flag that says if the config is just empty or uninitialized
[13:49] <mzanetti> I'll note it down in the mr
[13:51] <MacSlow> Saviq, ok
[14:14] <Saviq> mzanetti, you really took over unity8-autolanding today... shame we get so many failures suddenly :/
[14:15] <mzanetti> lol
[14:15] <mzanetti> does that imply me producing the failures?
[14:15] <mzanetti> ..causing...
[14:16] <mzanetti> Saviq: ^
[14:16] <Saviq> mzanetti, maybe ;)
[14:28] <Saviq> guys, I moved our standup tomorrow half an our back, hope it's fine with everyone
[14:34] <mzanetti> Saviq: not sure I'll make it. Have an appointment at 2
[14:34] <Saviq> mzanetti, k
[14:35] <mzanetti> Saviq: is unity api's by now used for more than the launcher and the notifications?
[14:35] <mzanetti> unity-apis
[14:35] <Saviq> mzanetti, not yet
[14:35] <Saviq> mzanetti, we've been bad about that
[14:36] <Saviq> mzanetti, but once we stabilize more we'll just make it happen
[14:36] <mzanetti> yeah... just realized that mterry introduces an api change in the launcher and probably doesn't even know about unity-apis
[14:39] <mterry> mzanetti, didn't, no
[14:39] <mzanetti> mterry: I'll take care of it and let you do the review
[14:41] <mterry> mzanetti, ok
[14:45] <mzanetti> mterry: https://code.launchpad.net/~mzanetti/unity-api/launcher-add-setUser/+merge/181575
[14:46] <mzanetti> mterry: let me know if you have questions about it
[14:46] <mterry> mzanetti, so what's the deal with unity-api?
[14:47] <mterry> This is for 3rd parties?
[14:47] <mzanetti> mterry: this becomes more interesting when/if the plugins end up in separate repositories
[14:48] <mzanetti> mterry: the problem is that QML has no compile time safety. So the idea is that our QML only uses stuff from unity-api
[14:48] <mzanetti> mterry: and that has tests that a certain plugin implementation indeed offers the same api
[14:49] <fginther> sil2100, do you have any UDS sessions planned?
[14:49] <mzanetti> mterry: so the mocks in unity8 and the real plugins implement the apis in there. so we have tests that check if the api doesn't break
[14:49] <mterry> mzanetti, so when I add new plugins like Powerd, I need to add it to unity-api?
[14:49] <mzanetti> mterry: ideally, yes. if you don't have time right now, we have to do a cleanup round soonish
[14:49] <mterry> huh
[14:50] <mzanetti> Saviq: correct me if I'm wrong^^
[14:53] <mzanetti> mterry: here's a (admittedly poor) diagram of how it works with the launcher: https://docs.google.com/a/canonical.com/drawings/d/1AlMDP0VqadG2s0ZdV2lG-5f2SEgpUXjNrfkCq970fDI/edit
[14:55] <mterry> mzanetti, this is launcher-specific?
[14:55] <mzanetti> mterry: this one yes. but it should work similar for everything
[14:55] <mterry> mzanetti, OK
[14:56] <mzanetti> mterry: I just painted this for my own understanding when Saviq told me first about lp:unity-api
[15:01] <sil2100> fginther: hi! hm, that's hard to say, since I'll be filling in as the client track lead, so I guess I do
[15:02] <sil2100> fginther: but it will be my first time and I still didn't manage to prepare anything, too busy
[15:02] <mterry> Saviq, what do you mean in the demo review about "squeezing" a gradient rather than changing its properties?
[15:04] <Saviq> mterry, I think it'd be more performant if we just drew the gradient once
[15:04] <Saviq> mterry, and just changed its width
[15:05] <fginther> sil2100, ack, I was considering doing something for the packaging checks during upstream merger testing, but I don't have much content
[15:06] <fginther> sil2100, was going to ask if you already had a session to add this to, but it sounds like you don't
[15:08] <fginther> sil2100, let me think about it some more. If we need a session, I can run it.
[15:08] <Saviq> mterry, because now the gradient is recreated (all the pixels recalculated) all the time
[15:08] <Saviq> mterry, and if it'd just change width, that would happen on the GPU
[15:11] <mterry> Saviq, whoops, disconnected.
 Saviq, I'd like that too, but I don't follow about squeezing
 mterry, because now the gradient is recreated (all the pixels recalculated) all the time
[15:11] <Saviq>  mterry, and if it'd just change width, that would happen on the GPU
[15:12] <Saviq> mterry, I think a Rectangle { gradient: Gradient { } } would be good enough
[15:12] <mterry> Saviq, OK.  Maybe that change can coincide with a move to rectangle
[15:12] <mterry> yeah
[15:12] <Saviq> mterry, with a layer.enabled: true
[15:12] <Saviq> but maybe not required even
[15:12] <mterry> why the layer?
[15:13] <Saviq> mterry, well actually the layer wouldn't help either
[15:13] <Saviq> mterry, 'cause if we resize a Rectangle with a Gradient, it will recalculate the gradient, too
[15:14] <Saviq> mterry, and then... the LinearGradient might actually happen on the GPU directly...
[15:14] <Saviq> mterry, so the only thing would be to make sure we only draw the gradient once
[15:14] <Saviq> mterry, and stretch it on the GPU
[15:14] <Saviq> mterry, would be to use a ShaderEffect { live: false } and resize that
[15:14] <Saviq> mterry, but that's probably overkill
[15:15] <Saviq> mterry, dunno, now that I'm thinking about this again, maybe a LinearGradient is better, assuming it's doing its thing in a shader ;)
[15:15] <Saviq> mterry, as a Rectangle will do the gradient on the CPU probably
[15:16] <mterry> Saviq, I'm not sure of the rules that affect that.  If any relevant properties of a gradient are changed directly, it redraws the gradient?
[15:16] <Saviq> mterry, yeah, that's for sure
[15:17] <Saviq> mterry, 'cause the interpolation changes
[15:17] <Saviq> mterry, with a 5-pixel wide gradient you only have 5 points
[15:17] <Saviq> mterry, if you change it to a 25-pixel wide one, it needs to recalculate what to draw in each pixel
[15:17] <mterry> Saviq, right.   I'll look into a ShaderEffect
[15:18] <Saviq> mterry, yeah, that's the only approach I can think of that will really just take a gradient and resize the whole texture on the GPU
[15:19] <mterry> Saviq, it'd be nice to be able to more declaratively control whether redraws happen
[15:19] <mterry> without guessing at implementation
[15:19] <Saviq> mterry, indeed
[15:21] <Saviq> mzanetti, humm... do we really want setUser in the "public" launcher api...
[15:21] <mzanetti> Saviq: we need to set it from QML
[15:21] <mterry> Saviq, I wondered about that.  How public is unity-api?  Who is intended audience?
[15:22] <Saviq> mterry, anyone who wants to implement a backend for the Unity shell
[15:22] <mzanetti> well, someone could import it and call it
[15:22] <mzanetti> but then, accountsservice should still only deliver any items in it if the user has permissions, no?
[15:23] <mzanetti> Saviq: unless we provide some other means of selecting the user in the greeter and the launcherbackend listens on that
[15:23] <mterry> mzanetti, right, it will only give out launcher items for root, lightdm, and the user themselves
[15:23] <mterry> that is, root & lightdm can get anybody's
[15:23] <mterry> users only can get their own
[15:24] <Saviq> mzanetti, mterry, could the lightdm launcher backend talk to lightdm to see which user is being authenticated?
[15:24] <Saviq> mzanetti, mterry so that the greeter will say "authenticate(username)"
[15:24] <mterry> Saviq, yes, but what's a "lightdm launcher backend"?  The greeter version of the launcher backend?
[15:24] <Saviq> mterry, yes, sorry, I'm mixing lightdm and greeter all the time
[15:25] <mterry> Saviq, it would need access to the lightdm connection, so it would be mixing plugins a bit
[15:25]  * mzanetti thinks current approach is cleaner
[15:25] <mzanetti> and unless I miss simething, I don't see any issues in regard to security either...
[15:26] <Saviq> mzanetti, I'm just worried setUser would be confusing in there
[15:26] <mzanetti> it just tells the launcher model from which user it should display the launcher entries :)
[15:26] <Saviq> mzanetti, yeah, which is no-op in the "real" launcher backend
[15:27] <mzanetti> Saviq: there will be only one
[15:27] <Saviq> mzanetti, well, there's one for the shell, and one for the greeter, no?
[15:27] <mterry> Saviq, if you implement a new launcher backend, you'll need to be able to provide launchers for an arbitrary user, since that's what the greeter wants
[15:27] <mterry> Saviq, they will use the same plugin
[15:27] <mterry> Saviq, since accountsservice lets them share the data store
[15:27] <mzanetti> Saviq: wouldn't it be ok to just use the same and setUser() to the one that is being logged in on startup of unity?
[15:28] <Saviq> mzanetti, mterry ah, so a single backend... talking to accountsservice as well as dconf...
[15:28] <mzanetti> Saviq: just loading defaults from dconf, then continuing with accountsservice
[15:28] <Saviq> mzanetti, mterry, I assume you can't spoof setUser to show you launcher items from another user's accountservice?
[15:29] <mterry> Saviq, that's what I had envisioned.  Since AS and gsettings need to be in sync, the same plugin would need to be able to talk to both to sync them anyway
[15:29] <Saviq> mzanetti, dconf needs to be used still, accountsservice just needs to be a cached version I think
[15:29] <mterry> Saviq, that's controlled by AccountsService & policykit
[15:29] <mterry> Saviq, I tested that I couldn't.  Only root and lightdm can see everyone's
[15:29] <Saviq> mterry, right, I just thought the greeter one would be simpler - just read from AS
[15:30] <Saviq> mterry, but then it needs dconf as well for the defaults
[15:30] <mterry> Saviq, could do.  Depends how complicated the gsettings stuff is
[15:30] <Saviq> if user never stored into AS
[15:30] <mterry> Saviq, true
[15:30] <mterry> Saviq, you envision we'll need to store data in gsettings too?
[15:30] <mzanetti> Saviq: that's what I thought too at first, but then I came to the conclusion that we only should load defaults from dconf and then import that to accountsservice in case that's uninitialized
[15:30] <mzanetti> Saviq: we can also keep track of an "lockToLauncher" flag or the like
[15:30] <Saviq> mterry, yeah, I was always thinking of AS as a secondary cache
[15:31] <mzanetti> mterry: Saviq: the greeter weekly sync starts now. would be a good place to discuss once we're through with design stuff
[15:33] <Saviq> mzanetti, mterry I gtg, can we talk tomorrow?
[15:35] <mzanetti> Saviq: sure
[15:56] <dednick> tedg: ping
[16:00] <tedg> dednick, Howdy
[16:02] <dednick> tedg: howdy. indicator-network. we need a "Other Networks..." menu to be able to connect to a hidden network.
[16:02] <tedg> dednick, Yes, that's going to be in the settings.
[16:03] <dednick> tedg: in indicator as well
[16:03] <tedg> dednick, No: https://wiki.ubuntu.com/Networking?action=AttachFile&do=get&target=phone-network-menu.png
[16:03] <dednick> tedg: https://wiki.ubuntu.com/Networking#Indicators_and_menus
[16:04] <dednick> oh, wait... thats pc
[16:04] <tedg> dednick, That's on the PC version
[16:04] <tedg> Yeah
[16:04] <dednick> awesome.
[16:07] <dednick> tedg: fyi, there seems to be some shit going on with indicator-messages
[16:09] <tedg> dednick, I know :-(
[16:09] <tedg> dednick, #ubuntu-touch
[16:09] <tedg> Sorry, #ubuntu-desktop for that.
[16:11] <dednick> tedg: hm. that hidden network seems to be in the phone delivery doc indicators section. I'll need to check on that.
[16:11] <dednick> kgunn: ping
[16:11] <kgunn> dednick: whats up?
[16:12] <dednick> kgunn: hi. just wanted to check with you about that 'hidden network' delivery. Is that in the indicator, or network settings?
[16:13] <kgunn> dednick: for parity's sake...on desktop it'd be in the panel
[16:13] <kgunn> dednick: for phone that;s a fair question
[16:13] <dednick> kgunn: ok, designs seem to show only in settings for phone. I'll check with mpt
[16:14] <kgunn> dednick: supposing no spec direction ?
[16:14] <kgunn> dednick: yeah....that'd be what i was going to suggest
[16:14] <dednick> kgunn: thanks
[16:36] <om26er_> the messaging menu seems to have broken on touch :/
[17:42] <dednick> mzanetti: ping
[17:42] <mzanetti> dednick: pong
[17:43] <dednick> mzanetti: hey. you had some trouble with findChild before right? Dont suppose you know why it segfaults if you search for something that doesnt exist?
[17:43] <mzanetti> uh... does it?
[17:43] <mzanetti> dednick: are you sure its findChild segfaulting and not the line afterwards where you try to use the nullptr?
[17:44] <mzanetti> mouseClick for example sefgraults on null
[17:45] <dednick> mzanetti: hm. possible
[17:49] <dednick> mzanetti: no, it's randomly segfaulting.  really weird. might have something to do with tabs
[17:50] <mzanetti> dednick: are you doing the findChild while the tabs are switching(animating) ?
[17:50] <dednick> mzanetti: :/ possibly
[17:50] <mzanetti> dednick: try a wait(4000) before. if it stops segfaulting, find something that is triggered when the animation finishes and wait for that with tryCompare
[17:52] <dednick> mzanetti: nope. still happening.
[17:52] <mzanetti> hmm.. now I'd need to test it myself to be of any use
[17:52] <mzanetti> branch?
[17:55] <dednick> mzanetti: lp:~nick-dedekind/+junk/indicator.visibility
[17:56] <dednick> mzanetti: testIndicators
[18:02] <dednick> omg. how hard is it to run a test manually!
[18:04] <mzanetti> dednick: ?
[18:05] <dednick> trying to run with gdb. my command line has become about 3 lines long
[18:05] <mzanetti> hehe
[18:05] <mzanetti> yeah.. we have import paths like crazy
[18:06] <mhr3_> talking about manually running tests
[18:06] <mhr3_> how does one do that?
[18:07] <mhr3_> i always just run everything cause i don't know how to filter it :P
[18:07] <mzanetti> mhr3_: qmltestrunner -input testFile.qml -import /path/to/plugins/
[18:07] <dednick> LD_LIBRARY_PATH=../../../builddir/tests/mocks/LightDM/single QML2_IMPORT_PATH=../../../builddir/tests/utils/modules:../../../builddir/tests/mocks/:../../../builddir/plugins qmltestrunner -input tst_Indicators.qml
[18:08] <mhr3_> ouch :P
[18:08] <mzanetti> dednick: it might be easier to patch our cmakesystem to support "make debgTestFooBar"
[18:08] <dednick> mhr3_: you can go into builddir and makeTestName (eg make testIndicators)
[18:08] <mhr3_> oh?
[18:09] <mhr3_> that does sound simple
[18:09] <mzanetti> mhr3_: even better: try "make tryTestName"
[18:09] <dednick> mhr3_: or tryTestName, if you just want to run
[18:09] <mzanetti> dednick: we really should have make debugTestName :)
[18:09] <dednick> yeah
[18:09] <dednick> the -input doesnt go well with gdb...
[18:11] <dednick> eh. doesnt look like you can gdb qmltestrunner...
[18:11] <mhr3_> dednick, you can, you just need to run the actual platform-specific version
[18:12] <mhr3_> stumbled upon that as well some time ago
[18:12] <mhr3_> dednick, /usr/lib/x86_64-linux-gnu/qt5/bin/qmltestrunner
[18:14] <dednick> mhr3_: or:  gdb --args qtchooser -run-tool=qmltestrunner -input tst_Indicators.qml
[18:14] <mhr3_> right
[18:14] <dednick> apparently :)
[18:15] <dednick> sigh.... well that was for naught. one of the most useless stacs ever.
[18:15] <mzanetti> dednick: I added some debug output to findChild, doesn't crash any more
[18:15] <dednick> lol
[18:16] <dednick> typical
[18:16] <mhr3_> qml really like to do this shit, add console.log() and suddenly the behavior is completely different...
[18:18] <dednick> mzanetti: http://pastebin.ubuntu.com/6014955/
[18:18] <dednick> odd
[18:19] <mhr3_> isn't it clear? :P
[18:19] <mzanetti> dednick: it might help a little if you install qmlscene's debug symbols (if they are packed up by now). But don't expect too much from that either
[18:19] <mhr3_> apparently you're passing invalid string to js
[18:20] <dednick> mzanetti: dont suppose you know what package theyre in?
[18:20] <Saviq> mhr3_, would answer you in #dx, but you're not there - on purpose?
[18:21] <mhr3_> Saviq, xchat doesn't like me switching wifi to wire to usb
[18:21] <mzanetti> dednick: last time I checked they weren't packaged up...
[18:21] <dednick> bugger that
[18:21] <mhr3_> Saviq, i pushed it with carousels for music and video in home
[18:21] <Saviq> mzanetti, they should be in ddebs
[18:22] <Saviq> https://wiki.ubuntu.com/DebuggingProgramCrash
[18:22] <mhr3_> Saviq, but if you want i can make them dynamic
[18:22] <dednick> var childs = new Array(0);  .. really?
[18:22] <dednick> childs?
[18:22] <dednick> sigh
[18:23] <mhr3_> i thought the 0 is what you don't like
[18:23] <dednick> lol
[18:24] <mhr3_> and now i wonder if that's an empty array or array with a single {0} element... thanks
[18:24] <Saviq> mhr3_, we have different categories for surface and search, right? so we can have different definitions for them - so we can make them dynamic in surfacing
[18:24] <mhr3_> Saviq, ehm, no
[18:24] <mzanetti> dednick: I'm not entirely sure why it crashes, but I have a fix for you... will take me a minute or 2 to prepare the branch
[18:25] <dednick> wow. i really dont understand that findChild func.
[18:25] <mzanetti> dednick: hehe
[18:25] <Saviq> mhr3_, we shouldn't have carousel for search at all - just for surfacing - as carousel with a low number of items is bad, and it's even worse to switch between renderers when searching
[18:26] <mzanetti> its a breath-first search on a tree
[18:26] <dednick> not supprised it crashes :D
[18:26] <mzanetti> but its fast :D
[18:26] <Saviq> mhr3_, when the number of items changes a lot
[18:27] <mzanetti> dednick: while I'm fixing it: http://en.wikipedia.org/wiki/Breadth-first_search
[18:27] <dednick> mzanetti: hm. interesting.
[18:28] <dednick> thats pretty cool
[18:29] <mhr3_> Saviq, why do you assume that surfacing will always have enough items?
[18:29] <Saviq> mhr3_, I don't - hence dynamic
[18:29] <Saviq> mhr3_, but for surfacing there are no count changes so much
[18:29] <mhr3_> ok, dynamic it is
[18:32] <Saviq> bejeezuz what's with the tests today :/
[18:37] <mzanetti> dednick: merge this for now: lp:~mzanetti/unity8/findInvisibleChild
[18:37] <mzanetti> should fix our issue
[18:40] <mzanetti> dednick: and once we're sure jenkins is happy with it, https://code.launchpad.net/~mzanetti/unity8/findInvisibleChild/+merge/181631
[18:40] <dednick> mzanetti: ahh. thanks
[18:40] <dednick> tricky stuff
[18:41] <mzanetti> dednick: I'm pretty sure there is one test at least that requires findInvisibleChild... but I've run the test suite here and nothing failed...
[18:41] <mzanetti> jenkins tests might reveal something tho
[18:56] <mzanetti> Saviq: oops... we landed the unity-api setUser() which got released and now unity8 doesn't build any more.
[19:05] <mzanetti> mterry: https://code.launchpad.net/~mzanetti/unity8/launcher-add-setUser/+merge/181639
[19:06] <mterry> mzanetti, thanks
[19:06] <mzanetti> mterry: hah! already the first example why we need unity-apis
[19:06] <mzanetti> mterry: in your launcher-item branch the mocks and tests already miss the setUser
[19:13] <mterry> mzanetti, miss them?
[19:13] <mterry> mzanetti, oh, I forgot to add the function to the mocks?
[19:13] <mterry>  /.\
[19:13] <mzanetti> mterry: right... which now would fail in jenkins...
[19:13] <mterry> mzanetti, that is useful
[19:13] <mzanetti> so this is exactly the reason for unity-api
[19:14] <mzanetti> to avoid different branches etc getting out of sync
[19:56] <dednick> mzanetti: your branch failed in CI. no idea why...
[19:57] <mzanetti> dednick: this one needs to land to fix ci: https://code.launchpad.net/~mzanetti/unity8/launcher-add-setUser/+merge/181639
[19:59] <dednick> mzanetti: ah.
[21:36] <cyphermox> hey
[21:36] <cyphermox> https://launchpadlibrarian.net/148186341/buildlog_ubuntu-saucy-amd64.unity-mir_0.1%2B13.10.20130822.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[21:37] <cyphermox> ^ seems like unity-mir fails to build on amd64 and i386 for issues in the mirserver API
[21:38] <cyphermox> robru: ^ fyi, I expect this is still going to fail tonight for your daily release run
[21:38] <robru> ah
[21:38] <robru> cyphermox, should we file a bug then?
[21:39] <cyphermox> yeah, I guess
[21:39] <cyphermox> or at least notify as per escalation procedure
[21:39] <cyphermox> kgunn: ^^
[21:40] <kgunn> racarr: any ideas ^
[21:40] <kgunn> robert_ancell: ^
[21:41] <robert_ancell> kgunn, looking
[21:41] <robert_ancell> ua_ui_mirserver_init - what library is that?
[21:41] <robert_ancell> I don't think we have any symbols like that
[21:42] <kgunn> robert_ancell: might be greyback mir-unity layer ?
[21:42] <robert_ancell> kgunn, yes, it's in lp:unity-mir src/unity-mir/qmirserver.cpp
[21:43] <robert_ancell> so looks like some internal linking problem in unity-mir
[21:43] <kgunn> robert_ancell: i was just about to look to see if something landed....but i didn't think anything hit within last 2 days
[21:43] <kgunn> e.g. we changed and broke gerry
[21:44] <kgunn> oh wait
[21:44] <kgunn> cyphermox: so it broke only for amd64/i386 ?
[21:44] <kgunn> robert_ancell: ^
[21:44] <cyphermox> apparently so
[21:44] <cyphermox> let me make sure
[21:45] <kgunn> cyphermox: cause unity-mir is only relevant on arm atm
[21:45] <kgunn> (not that that makes it totally ok)
[21:45] <kgunn> (but less freak out)
[21:45] <robert_ancell> kgunn, it's not our symbol , so I don't think it's an API/ABI change on our side
[21:45] <robert_ancell> I'll try building locally here
[21:45] <kgunn> robert_ancell: i can tell you arm from trunk builds fo sho
[21:46] <kgunn> i just did it like 2 hours ago
[21:46] <kgunn> ...and that's me
[21:46] <cyphermox> kgunn: it failed everywhere
[21:46] <kgunn> cyphermox: eeewww, ok
[21:46] <cyphermox> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3440062/+listing-archive-extra
[21:48] <kgunn> robert_ancell: wrt building i meant mir...not unity-mir
[21:48] <robert_ancell> ah
[21:59] <kgunn> racarr: you back ?
[22:01] <racarr> kgunn: Just got back
[22:01] <kgunn> racarr: no worries...
[22:01] <kgunn> racarr: just wanted to poke you....i just branched unity-mir
[22:02] <kgunn> to build and its looking for ubuntu-platform-api...
[22:02] <kgunn> but...is that really something like libplatform-hardware-api1-dev
[22:02] <kgunn> ?
[22:02] <kgunn> or...what the heck is that
[22:02] <racarr> no  its
[22:03] <racarr> libplatform-api
[22:03] <racarr> I dont remember how the packaging as done for how the -mirsever variant
[22:03] <racarr> i think its just that
[22:03] <racarr> kgunn: Well if you re building from source
[22:03] <robert_ancell> kgunn, it builds locally here
[22:03] <racarr> it's lp:platform-api and you build with cmake -DENABLE_MIRSERVER_IMPLEMENTATION=true
[22:10] <kgunn> robert_ancell: "it" being unity-mir ?
[22:10] <robert_ancell> kgunn, yes
[22:12] <mterry> mzanetti, is Q_FOREACH preferable to C++'s "for (auto x: list)" ?
[22:13] <mzanetti> mterry: hmm... depends. Q_FOREACH has some gimmics when working with stuff like QMap or QHash
[22:13] <kgunn> robert_ancell: ok...i think it might be one for gerry...or ricmm might know
[22:13] <mterry> hmm
[22:13] <mzanetti> for everything else I'd say it doesn't really make a difference
[22:33] <mzanetti> veebers: hey
[22:33] <veebers> mzanetti: hey, what's the haps?
[22:33] <mzanetti> veebers: http://s-jenkins:8080/job/generic-mediumtests-runner-mako/155/console
[22:33]  * veebers looks
[22:33] <mzanetti> veebers: happens since a couple of hours
[22:34] <mzanetti> looks a bit like infrastructure troubles
[22:34] <veebers> mzanetti: yeah, looks like the wget fails :-\
[22:35] <veebers> mzanetti: I'm reading some backlog; see if it's a known/in progress issue. Otherwise I'll ask around and get it sorte
[22:35] <veebers> d
[22:35] <mzanetti> thanks
[22:35] <mzanetti> I'm off to bed
[22:36] <mzanetti> o/
[22:36] <veebers> mzanetti: hehe fair enough, cya o/