[07:55] <mzanetti> lol... [Bug 1106951] Re: While playing SUpertuxkart, screen resolution low when notify osd appear
[08:04] <Saviq> interesting :)
[08:09] <Hours> unity design is too crowded！！
[08:09] <hyperair> what's crowded?
[08:09] <hyperair> the mailing list?
[08:10] <Hours> the bar
[08:10] <hyperair> which bar?
[08:10] <Hours> unity bar
[08:11] <Hours> icon too big， too crowed!
[08:12] <hyperair> there's a top bar
[08:12] <hyperair> there's also a side bar
[08:12] <hyperair> which bar?
[08:12] <Hours> side bar
[08:12] <seb128> you can set the icons size you want
[08:12] <hyperair> (max is still 48 though)
[08:12] <hyperair> er min
[08:14] <didrocks> thomi: veebers: hey, any ETA to have the QA stack finally passing its tests?
[08:14] <didrocks> failing since Thursday
[08:15] <veebers> didrocks: Not at this stage, (I'm running the tests now). I believe fginther will look at it in his morning.
[08:15] <veebers> didrocks: So hopefully not to far away at all
[08:15] <didrocks> veebers: can we revert the code otherwise?
[08:15] <veebers> I'll touch base with fginther in the morning and carry on if it's an issue.
[08:15] <Saviq> mzanetti, have you a branch with the launcher perspective?
[08:15] <didrocks> veebers: if a code regress the tests, it should be taken out if can't be fixed promptly :)
[08:15] <veebers> didrocks: did a specific commit break it?
[08:16] <didrocks> veebers: no idea, would have been easier if it was looked at on the first day it broke
[08:16] <veebers> didrocks: understood
[08:16] <mzanetti> Saviq: lp:~mzanetti/unity/8-launcher-new-folding/
[08:17] <mzanetti> Saviq: just pushed some bits  - pull again
[08:19] <Hours> side bar icon space too small
[08:19] <Saviq> mzanetti, fancy ;)
[08:20] <mzanetti> Saviq: it is :)
[08:20] <mzanetti> Saviq: so would you agree with the taken approach?
[08:23] <mzanetti> can it be that duckduckgo.com cannot handle the traffic ever since the world knows what google does with their search results?
[08:25] <Saviq> mzanetti, I'd probably go for the shader approach (I'd consider it less of a hack ;)), but I don't have anything against the Rotations if they don't cause performance issues
[08:25] <mzanetti> Saviq: they seem fine... its pretty fast on the GN
[08:26] <mzanetti> Saviq: I had serious troubles when using the BrightnessContrast on the GN. hence the own shader for opacity+brighness
[08:26] <mzanetti> but the rotations don't seem an issue at all
[08:26] <Saviq> mzanetti, it's probably a given that it's slower than a shader
[08:26] <Saviq> mzanetti, and it'd be a simple one, too
[08:27] <Saviq> mzanetti, hence - *I* would probably go for that, but it's fine as is
[08:27] <Saviq> we can always get to it if we find it problematic
[08:27] <mzanetti> Saviq: yep. agreed
[08:28] <Saviq> mzanetti, visually there's some things slightly weird in the transitions, but it might actually be per-design, would have to look closely (and then it's not my job to see that ;))
[08:30] <Saviq> mzanetti, but it's looking great (didn't even know you were working on the whole "disappear completely" behaviour)
[08:30] <mzanetti> Saviq: yeah, I have a feeling what you mean with the weirdness and I fear it is per design
[08:30] <Saviq> mzanetti, is the ubuntu icon a new design?
[08:31] <mzanetti> Saviq: yep
[08:31] <Saviq> mzanetti, and I assume the fact that it's upside-down (again) is temporary?
[08:31] <mzanetti> Saviq: ah right... thats just setting "inverted: true"
[08:31] <Saviq> yup
[08:32] <mzanetti> Saviq: I tend to set that to fals while coding to reduce the level of operations in my mind
[08:32] <Saviq> :)
[08:32] <mzanetti> besides it keeps it tested
[08:32] <Saviq> yup, sure
[08:36] <sil2100> didrocks: I'll re-run unity test, since there seemed to be some problems with unity on otto during the last run
[08:39] <didrocks> sil2100: ok :)
[09:11] <seb128> Trevinho, hey, not sure what changed but unity matches the wrong .desktop for nautilus for me in saucy ... do you see that too?
[09:20] <Saviq> nic-doffay, and please paste some code / error logs
[09:22] <nic-doffay> I've recently gotten the UbuntuTV branch which imports QtQuick 1.0 almost everywhere working off the shell/sidebar dir. I've replaced all the imports with QtQuick 2.0 but some reason on run it's still looking for QtQuick 1.0
[09:22] <nic-doffay> Saviq, pretty simple error: ubuntutv/shell/sidebar/SidebarView.qml:1 module "QtQuick" version 1.0 is not installed
[09:23] <Saviq> nic-doffay, are you sure you have the right import in SidebarView.qml?
[09:23] <Saviq> nic-doffay, it says, that on line 1 of SidebarView.qml you have a QtQuick 1.0 import...
[09:24] <mzanetti> Saviq: tsdgeos is not in today, right?
[09:24] <Saviq> mzanetti, yup
[09:25] <Saviq> mzanetti, and MacSlow and mterry
[09:25] <mzanetti> just wanted to ask him if he has an idea for snapping a flickable, given his work on LVWPH
[09:26] <Saviq> mzanetti, I don't think we need snapping in LVWPH, but yeah, he might have good insight after that work
[09:29] <nic-doffay> Saviq, yeah I replaced them all.
[09:29] <Saviq> nic-doffay, can you commit and push somewhere?
[09:31] <Saviq> vesar, you're on saucy still?
[09:31] <Saviq> s/saucy/raring/
[09:31] <Saviq> vesar, I'm afraid we require saucy now
[09:31] <vesar> Saviq, that's it then:)
[09:32] <Saviq> vesar, but you should be able to run on device fin
[09:32] <Saviq> fine
[09:32] <Saviq> from raring (with a saucy-flashed device)
[09:32] <vesar> Saviq, ok I'll try that. But I think it's better for me to update anyway.
[09:33] <Saviq> vesar, yeah, probably
[09:33] <vesar> Saviq, are there any guides how to upgrade ?
[09:33] <vesar> Saviq, I'm used to use SW updater but it doesn't suggest any saucy for me.
[09:33] <Saviq> vesar, sec
[09:34] <Saviq> vesar, `update-manager -d` from a terminal
[09:34] <Saviq> vesar, or from alt+f2
[09:34]  * Saviq forgot about alt+f2 for some time now... ctrl+alt+t is my alt+f2 now...
[09:37] <vesar> Saviq, and that should give me option to upgrade to saucy? Currently it asks me to restart my computer to install the updates. I guess I do that now to get forward from that point.
[09:37] <Saviq> vesar, yeah, I think you need that first
[09:39] <nic-doffay> Saviq, made some headway. Getting a lot of errors from the QML scene though.
[09:39] <nic-doffay> Assuming this hasn't been maintained for a while.
[09:40] <Saviq> nic-doffay, of course it has not
[09:40] <Saviq> nic-doffay, it's been left alone for almost a year now
[09:40] <Saviq> nic-doffay, it's never been ported to QtQuick 2.0 either
[09:40] <nic-doffay> Saviq, https://pastebin.canonical.com/93264/
[09:41] <Saviq> nic-doffay, that's not really a maintenance problem, but the fact that it's using a custom units system
[09:41] <Saviq> nic-doffay, you need to replace it with the Ubuntu.Components approach
[09:42] <Saviq> nic-doffay, so wherever you see "Units.tvPx()" - that needs to be "converted" into using units.gu()
[09:42] <nic-doffay> Saviq, can I just get rid of fontUtils.js
[09:42] <Saviq> nic-doffay, probably
[09:43] <vesar> Saviq, ok upgrade started. Thanks!
[09:43] <Saviq> nic-doffay, and units.js, too
[09:43] <Saviq> vesar, good luck! :)
[09:44]  * Saviq just `adb shell`-ed straight into Ubuntu - yay for the flipped image :D
[09:46]  * greyback moving to office, bbiab
[09:50] <katie> mzanetti, hello :)
[09:50] <mzanetti> hi katie :)
[09:51] <nic-doffay> Saviq, what's the current state of the ubuntutv out of interesT?
[09:52] <Saviq> nic-doffay, it's lying in a corner, sobbing softly
[09:52] <nic-doffay> Saviq, and the future?
[09:52] <nic-doffay> Will it still be sad and lonely?
[09:52] <Saviq> nic-doffay, based on what we're doing now
[09:52] <Saviq> nic-doffay, the old project was based off of unity-2d
[09:52] <Saviq> nic-doffay, we're in a whole new world now
[09:56] <nic-doffay> Saviq, the plans are to develop the tv though, right?
[09:56] <nic-doffay> Somewhere along the line...
[09:56] <nic-doffay> Not just use some components for Unity.
[09:56] <Saviq> nic-doffay, tv marked proved difficult
[09:57] <Saviq> nic-doffay, so for now the only thing we're planning for, AFAIK, is being able to connect your device to a TV via HDMI
[09:57] <Saviq> nic-doffay, and get the Ubuntu TV experience
[09:58] <nic-doffay> Saviq, k
[10:14] <sil2100> didrocks: unity tests failed running because of extra python-secretstorage being installed - couldn't trace what pulls in this dep, but should I re-run tests with 'check with whole PPA'?
[10:15] <didrocks> sil2100: hum, I would prefer we understand what's pulling it
[10:15] <didrocks> sil2100: especially as it's in universe
[10:15] <didrocks> sil2100: that's not anything that is in the QA stack?
[10:16] <sil2100> didrocks: during this unity run only libunity, unity-lens-files and unity were being built, and none of those had this dep - I'll check QA and more inside
[10:16] <didrocks> sil2100: otherwise, we'll make the iso uninstallable
[10:17] <seb128> didrocks, sil2100:
[10:17] <seb128>  o python-secretstorage: python-secretstorage python-secretstorage-doc
[10:17] <seb128>    MIR: #1188935 (Fix Committed)
[10:17] <seb128>    [Reverse-Depends: Rescued from python-secretstorage]
[10:17] <seb128>    [Reverse-Recommends: python-keyring (MAIN)]
[10:17] <seb128> bug #1188935
[10:18] <didrocks> seb128: that doesn't explain why we have a new component pulling it
[10:18] <seb128> didrocks, well, it's pulled in by python-keyring
[10:18] <sil2100> Recommends? Let me see rdeps of python-keyring
[10:18] <didrocks> seb128: right, we don't touch that
[10:18] <nic-doffay> Saviq, what should u2d.tr be replaced with?
[10:19] <nic-doffay> eg text: u2d.tr("Movie info")
[10:19] <didrocks> sil2100: oh, we do install python-keyring with the list of packages
[10:19] <sil2100> didrocks: ok, I see it
[10:19] <didrocks> sil2100: I think this was a transient state
[10:19] <sil2100> didrocks: unity-scope-launchpad depends on that...
[10:19] <didrocks> sil2100: we should maybe clean this list of this stack from all the stuff that are installed by default now, isn't it?
[10:19] <sil2100> didrocks: since unity-scope-launchpad depends on python-launchpadlib and this depends on python-keyring
[10:20] <Saviq> nic-doffay, i18n.tr
[10:20] <Saviq> nic-doffay, again, from Ubuntu.Components
[10:21] <mzanetti> Saviq: need you help
[10:21] <mzanetti> Saviq: using a ListView instead of Flickable + Repeater + Column would solve all my snapping problems (and some more)
[10:21] <Saviq> mzanetti, thought "need you help" was supposed to be a question ;)
[10:21] <Saviq> mzanetti, yup
[10:22] <mzanetti> your... sorry
[10:22] <Saviq> ;)
[10:22] <nic-doffay> Saviq, I'm removing all references to Unity2d, too.
[10:22] <Saviq> nic-doffay, yup
[10:22] <mzanetti> Saviq: in any ways a ListView would be better... with one exception:
[10:22] <mzanetti> Saviq: "In order to improve painting performance, items outside the visible area are not painted"
[10:22] <nic-doffay> Saviq, there's also a lot of "Effects" imports going on. What should that be replaced with?
[10:22] <mzanetti> Saviq: that makes them disappear too early :/
[10:23] <Saviq> mzanetti, cacheBuffer and negative margins
[10:23] <Saviq> mzanetti, see what Carousel did
[10:23] <Saviq> s/did/does
[10:23] <Saviq> and actually cacheBuffer is probably not needed with the margin
[10:23] <mzanetti> Saviq: tried that... negative margins are a bitch
[10:24] <mzanetti> but sure... I'll check teh carousel
[10:24] <Saviq> mzanetti, that's the only way, I'm afraid
[10:24] <Saviq> mzanetti, both Carousel and gallery-app use that approach
[10:24] <mzanetti> ah ok... I'm sure I can make it happen for the launcher too then
[10:24] <mzanetti> thanks!
[10:25] <Saviq> mzanetti, talk with gusch, btw - he knows all about that
[10:25] <mzanetti> ack
[10:29] <nic-doffay> Saviq,  managed to get rid of most of the errors. Not sure what to do about these however: https://pastebin.canonical.com/93267/
[10:29] <Saviq> nic-doffay, are you trying to run the whole thing?
[10:30] <Saviq> nic-doffay, or did you replace stuff in VideoSidebar?
[10:30] <Saviq> nic-doffay, player you don't need
[10:30] <nic-doffay> Just the VideoSidebar Saviq
[10:30] <nic-doffay> Can I remove all references to player?
[10:30] <Saviq> nic-doffay, not necessarily remove - if there's data coming from there (like .nfo)
[10:30] <Saviq> nic-doffay, you need to replace it with some static data
[10:31] <Saviq> nic-doffay, not sure about the other two, you need to dig deeper what those mean
[10:31] <sil2100> didrocks: besides that 'clean up' that we might need, I think using the 'use whole PPA' might be a good idea for now, until python-secretstorage gets into main
[10:32] <didrocks> sil2100: ok, fine with me
[10:50] <nic-doffay> Saviq, did QtQuick 1.0 have any variable called visibleArea?
[10:51] <Saviq> nic-doffay, 2.0 still does http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-flickable.html#visibleArea.heightRatio-prop
[10:52] <Saviq> nic-doffay, the error says "you're trying to get .visibleArea of [undefined]", not "there's no .visibleArea on [some_defined_object]"
[10:53] <nic-doffay> Saviq, any idea what should be assigned to SidebarView.qml container var?
[10:54] <Saviq> nic-doffay, you should load the VideoPreview.qml in Sidebar.qml
[10:54] <Saviq> nic-doffay, or just put it in a Flickable
[10:54] <Saviq> nic-doffay, and set container to that Flickable
[10:58] <Saviq> nic-doffay, btw, https://lists.launchpad.net/ubuntu-phone/msg02497.html
[10:59] <nic-doffay> Saviq, at the moment I'm trying to run off VideoSidebar.
[10:59] <Saviq> nic-doffay, that's not enough
[10:59] <nic-doffay> Saviq, right, VideoPreview it is then.
[10:59] <Saviq> nic-doffay, a SidebarView needs to be in a Flickable
[10:59] <Saviq> nic-doffay, no
[10:59] <Saviq> nic-doffay, just use Sidebar.qml
[11:00] <nic-doffay> Saviq, got it.
[11:00] <Saviq> nic-doffay, and make Loader load VideoSidebar.qml
[11:00] <Saviq> nic-doffay, but your biggest task on all this is to make sure design is consistent
[11:00] <Saviq> nic-doffay, i.e. go to the designers and show them the ValueSelector in the SDK
[11:00] <Saviq> nic-doffay, and the email https://lists.launchpad.net/ubuntu-phone/msg02497.html
[11:01] <Saviq> nic-doffay, and ask what should actually happen
[11:01] <Saviq> nic-doffay, because it really feels like this should be the default behaviour in the SDK
[11:13] <Saviq> guys, would be good to get https://code.launchpad.net/~saviq/unity/8.flipped-support/+merge/171061 in
[11:13] <Saviq> so that when they flip the switch^Wimage, we're ready
[11:17] <nic-doffay> Saviq, getting what appears to get the last strange issue.
[11:17] <nic-doffay> https://pastebin.canonical.com/93268/
[11:17] <nic-doffay> Saviq, spacing is defined in SidebarView
[11:18] <Saviq> nic-doffay, what did you replace Units.tvPx(33) with?
[11:19] <nic-doffay> units.gu
[11:19] <nic-doffay> Saviq, ^
[11:19] <Saviq> nic-doffay, did you import Ubuntu.Components?
[11:20] <nic-doffay> Saviq, yeah
[11:20] <Saviq> nic-doffay, and is the value in SidebarView.qml correct? what does onSpacingChanged: console.debug(spacing) say?
[11:21] <nic-doffay> Saviq, it's correct.
[11:21] <sil2100> didrocks, jibel: btw. guys, did something change in the way our otto autopilot environment is prepared?
[11:21] <Saviq> nic-doffay, can you push the code somewhere?
[11:21] <didrocks> sil2100: not that I know of, we just removed a bug where I forced the dist-upgrade
[11:21] <nic-doffay> Saviq, yeah one sec.
[11:23] <sil2100> didrocks: hm, would you mind if I altered the usr/local/bin/run-autopilot.sh script to add the ubuntu user to the 'autopilot' group before running the scripts? Or is there some better way of doing that besides modifying the target-override/ script?
[11:25] <sil2100> didrocks: since python-autopilot gives access to /dev/uinput to the autopilot group, and from what I saw in the 'snapshot', we're not adding ubuntu to i
[11:25] <sil2100> *it
[11:25] <sil2100> So we get a permission denied on /dev/uinput access it seems
[11:25] <didrocks> sil2100: the ubuntu user isn't logged in when installing the packages, shouldn't that add the user to the group?
[11:26] <sil2100> didrocks: no, the /etc/groups file says this group is empty
[11:26] <sil2100> *group
[11:26] <sil2100> autopilot:x:124:
[11:26] <didrocks> sil2100: the autopilot package adds the current user only, I guess?
[11:26] <sil2100> didrocks: not sure, probably
[11:27] <nic-doffay> Saviq, lp:~nicolas-doffay/ubuntutv/Sidebar
[11:27] <sil2100> No other choice of doing it more properly I guess
[11:28] <didrocks> sil2100: I would say, in the autopilot branch, add the ubuntu user manually as part of the setup script
[11:28] <didrocks> (the otto-setup.conf)
[11:29] <sil2100> In lp:otto/autopilot ?
[11:29] <sil2100> In hooks/setup ?
[11:40] <sil2100> didrocks: assuming hooks/setup !
[11:40] <didrocks> sil2100: no, in the autopilot test suite
[11:40] <didrocks> sil2100: lp:~otto-dev/otto/testsuite_autopilot-unity
[11:41] <didrocks> so yeah lp:otto/autopilot
[11:41] <didrocks> ah crap, otto-setup.conf is in otto
[11:41] <sil2100> ;)
[11:42] <didrocks> but we don't want to be autopilot specific
[11:42] <didrocks> hum…
[11:42] <sil2100> Yes, since I didn't see that in otto/autopilot
[11:42] <didrocks> so you can start here an upstream job
[11:42] <didrocks> upstart*
[11:42]  * didrocks thinks…
[11:43] <didrocks> yeah, should be the best way
[11:43] <didrocks> so an upstart job
[11:43] <didrocks> starting before lightdm
[11:43] <didrocks> (look at the otto-setup.conf for the condition)
[11:43] <didrocks> just adding the ubuntu user to the right group
[11:44] <sil2100> So in target-override an upstart job
[11:44] <sil2100> ACK!
[11:44] <sil2100> Thanks
[11:44] <didrocks> sil2100: yw, thanks for fixing it! :)
[11:50] <Saviq> Cimi, here, btw
[11:50] <Saviq> Cimi, 30° is what worked well with the launcher (it was even less initially)
[11:51] <Saviq> Cimi, we just need to find some sane values
[11:51] <Saviq> Cimi, that simply requires testing
[12:22] <Saviq> nic-doffay, I pushed something to lp:~saviq/+junk/tv-sidebar
[12:22] <Saviq> nic-doffay, you should be able to go from there
[12:22] <nic-doffay> Saviq, cool will check it out.
[12:23] <Saviq> nic-doffay, main things: it was 0x0 (you haven't specified width / height anywhere)
[12:23] <Saviq> nic-doffay, use qmlscene shell/test.qml
[12:23] <Saviq> nic-doffay, and : units.gu(470) means something like 5000px
[12:23] <Saviq> nic-doffay, I doubt you have this wide a display :P
[12:23] <nic-doffay> Saviq, this is what I was concerned about.
[12:24] <nic-doffay> Are the old units the same as the new ones?
[12:24] <Saviq> nic-doffay, not at all
[12:24] <Saviq> nic-doffay, tvPx was "pixel on a tv"
[12:24] <Saviq> nic-doffay, so it's closer to units.dp
[12:24] <Saviq> nic-doffay, but it shouldn't be used, so it's all very much to be re-done
[12:24] <nic-doffay> Saviq, I'll replace the units.gu with dp then.
[12:24] <Saviq> nic-doffay, already done in the branch I've sent
[12:24] <nic-doffay> Saviq, right from the ground up then :P
[12:25] <Saviq> nic-doffay, it only works with a keyboard, btw
[12:25] <Saviq> nic-doffay, not necessarily from the ground up, but a lot of it, yeah
[12:25] <Saviq> it's year-old code, what do you expect :P
[12:35] <dandrader> dednick, if I understood it correctly, tapping on the panel shouldn't do anything anymore, right?
[13:06] <mzanetti> Saviq: do you know who will trigger the SIM pin lockscreen?
[13:07] <mzanetti> will that stuff be integrated into lightdm too or will we directly listen to ofono signals for that?
[13:07] <Saviq> mzanetti, might be both
[13:07] <Saviq> mzanetti, i.e. if started in a user session (only one user, not encrypted)
[13:07] <Saviq> mzanetti, we'd handle that in-house
[13:07] <Saviq> mzanetti, similar to wifi password
[13:08] <Saviq> mzanetti, but if you started into a greeter, would have to happen there, I think
[13:08] <Saviq> mzanetti, as it's lightdm that will own ofono when locked
[13:09] <Saviq> mzanetti, but I haven't seen any designs around it (unless the lockscreen you've implemented is supposed to serve both?)
[13:09] <mzanetti> Saviq: yep. its both
[13:09] <Saviq> mzanetti, would feel weird if you've logged in with a passphrase
[13:10] <Saviq> mzanetti, just to be locked out again until you put the PIN in
[13:10] <Saviq> mzanetti, so I think it has to be separate
[13:10] <mzanetti> Saviq: ?
[13:10] <Saviq> mzanetti, I mean that you need to be able to log in to your phone
[13:10] <Saviq> mzanetti, without unlocking the SIM
[13:10] <mzanetti> Saviq: yeah
[13:10] <Saviq> mzanetti, so we need to support both usecases
[13:10] <Saviq> s/both/all of them/
[13:10] <mzanetti> Saviq: ah.. I understand... yes... in that case it would show up twice
[13:11] <mzanetti> once telling you to enter you passkey, the other time telling you to enter you PIN
[13:11] <mzanetti> in the PIN case the back button would turn into a cancel button
[13:11] <Saviq> mzanetti, you can't unlock SIM with a passphrase (unless the PIN was stored in encrypted password storage that would unlock after you've logged in)
[13:11] <mzanetti> Saviq: talking about the PIN one
[13:12] <Saviq> mzanetti, yeah, but then... what if you want a 6 digit PIN for the phone
[13:12] <Saviq> mzanetti, I think the PIN unlock needs to be treated exactly as the passphrase one
[13:12] <mzanetti> Saviq: I know. that was my first question for design
[13:13] <mzanetti> Saviq: they said for now we're going gor 4 digits
[13:13] <mzanetti> because a "OK" button did not fit into the design :D
[13:13] <Saviq> mzanetti, and SIM unlock needs to happen separately (even if transparently)
[13:13] <Saviq> lol
[13:14] <mzanetti> Saviq: anyways, that's not my biggest concerns right now
[13:14] <Saviq> mzanetti, and then if you don't have PIN saved in your password storage, a notification (or a system dialog) should be used
[13:14] <Saviq> mzanetti, so that you can dismiss it and use the phone without unlocking PIN
[13:14] <mzanetti> Saviq: not following
[13:15] <mzanetti> Saviq: why would the SIM pin dialog need to be a notification?
[13:15] <nic-doffay> Saviq, where in the SDK is this sidebar stuff currently? You mentioned the SDK stuff should mirror the TV branch and vice versa.
[13:16] <Saviq> nic-doffay, there's no *sidebar* in the SDK
[13:16] <Saviq> nic-doffay, there's just widgets similar to what's there in the sidebar
[13:16] <Saviq> nic-doffay, the ListItems
[13:16] <Saviq> nic-doffay, and the ValueSelector in particular
[13:16] <Saviq> nic-doffay, which serves the same purpose
[13:16] <Saviq> nic-doffay, but has different behaviour
[13:16] <Saviq> nic-doffay, which should be resolved in either way (should be consistent)
[13:17] <nic-doffay> Saviq, right. Just to confirm then, the current task is to get the tv branch sidebar up to speed with the design doc you linked?
[13:17] <Saviq> nic-doffay, no, not at all
[13:17] <Saviq> nic-doffay, we need a similar behaviour
[13:17] <Saviq> nic-doffay, that was implemented for ubuntutv
[13:17] <Saviq> nic-doffay, so it's an example
[13:18] <Saviq> nic-doffay, or a starting point
[13:18] <dednick> dandrader: tapping shouldn't specificlly do anything, but the press should hint.
[13:18] <nic-doffay> Saviq, I see so I should be working off the SDK branch then?
[13:18] <Saviq> nic-doffay, we need the behaviour spec'ed in the design doc
[13:18] <Saviq> nic-doffay, ATM it's only defined to be used in the dash / shell
[13:19] <Saviq> nic-doffay, but that behaviour is inconsistent with the SDK
[13:19] <Saviq> nic-doffay, so you need to go talk to the designers
[13:19] <Saviq> nic-doffay, and find out why it's inconsistent, and whether we can make it consistent
[13:20] <Saviq> nic-doffay, if we can - then it's work in the SDK
[13:20] <Saviq> nic-doffay, if we can't - then it's work internal to unity8
[13:22] <nic-doffay> Saviq, gotcha
[13:23] <dednick> dandrader: also, tapping to close the indicators should do a "reverse" hint.
[13:23] <dednick> ie. hint to close
[13:24] <dednick> s/tapping/pressing
[13:26] <dandrader> dednick, yes, I've done that in my branch already
[13:26] <nic-doffay> Saviq, where's the best use case of the ListItem and the ValueSelector in unity8 currently?
[13:26] <didrocks> interesting, cmake's libexec is usr/libexec
[13:29] <Saviq> nic-doffay, there isn't any atm, I think - it's supposed to be used for dash filters
[13:31] <mzanetti> Saviq: next meeting your calendar alarm failed ;)
[13:32] <mzanetti> nic-doffay: dednick: standup
[13:33] <kenvandine> sil2100, thanks for the build fixes in libsignon-glib
[13:33] <kenvandine> sil2100, it's really a bug in check, so this works around it nicely
[13:33] <kenvandine> but i am going to go ahead and fix it in check
[13:34] <Saviq> mzanetti, aarhg
[13:34] <mzanetti> paulliu: http://bazaar.launchpad.net/~unity-team/unity-api/trunk/view/head:/test/qmltest/modules/TestUtil/Verifier.qml
[13:35] <fginther> Trevinho, ping
[13:35] <Trevinho> fginther: pong
[13:35] <sil2100> kenvandine: np, yes, it's a bug, since the toolchain got a bit different now
[13:36] <kenvandine> not really "different"
[13:36] <kenvandine> check is broken :)
[13:36] <mzanetti> Cimi: standup?
[13:36] <fginther> Trevinho, I created a bug report for the bamf matching issue I mentioned late last week: https://bugs.launchpad.net/bamf/+bug/1193502
[13:36] <kenvandine> they call pthread-config during configure to determine the libs to add to check.pc
[13:36] <kenvandine> which we don't seem to have
[13:36] <kenvandine> so it inserts an empty string where -lpthread should be
[13:37] <Trevinho> fginther: setting NoDisplay wasn't enough?
[13:37] <fginther> Trevinho, nope
[13:37] <Trevinho> fginther: I also see another problem around, but i have to check...
[13:37] <Trevinho> hm
[13:37] <fginther> Trevinho, if you need me to do some more debugging, please let me know
[13:38] <sil2100> kenvandine: btw.!
[13:38] <sil2100> kenvandine: did you see: https://code.launchpad.net/~sil2100/gnome-control-center-signon/bump_timeout/+merge/171066 ?
[13:38] <fginther> Trevinho, thanks for taking a look
[13:38] <kenvandine> not yet :)
[13:38] <sil2100> kenvandine: me and seb128 decided to workaround the armhf unit test failure by increasing the timeout ;)
[13:38] <kenvandine> sil2100, i'll look
[13:38] <sil2100> Thanks!
[13:39] <kenvandine> sil2100, does that work?
[13:39] <kenvandine> sil2100, i've bumped the timeout in the past for the same reason
[13:39] <seb128> Trevinho, hey
[13:39] <kenvandine> from 90 to 180 :)
[13:39] <seb128> kenvandine, good morning, had a good w.e ?
[13:39] <kenvandine> those timeouts are so annoying
[13:39] <kenvandine> seb128, exhausting, ready to relax at work :)
[13:39] <kenvandine> seb128, and you?
[13:40] <kenvandine> sil2100, bug 1194126
[13:40] <kenvandine> in case you find anything else failing to build for the same reason
[13:40] <kenvandine> i'll fix it this morning though
[13:41] <seb128> kenvandine, quite good thanks (we had some music festivals, they organize that every year for the summer's day)
[13:41] <kenvandine> great!
[13:41] <sil2100> Oh, mardy approved
[13:41] <seb128> kenvandine, I newed gsettings-qt this morning btw ;-)
[13:42] <kenvandine> thx!
[13:42] <tedg> Saviq, Can you give me permission to edit that SVG doc you asked me to comment on?  :-)
[13:42] <Saviq> tedg, trying
[13:42] <kenvandine> i guess we don't have any packages that provide pthread-config... annoying
[13:42] <kenvandine> i wonder what upstream that should come from
[13:47] <Saviq> tedg, donr
[13:47] <Saviq> done
[13:47] <sil2100> kenvandine: thanks!
[13:47] <tedg> mhr3, Is it insane to think that I could push the application startup event into ZG using a command line dbus command?  Should I write a little util using the lib?
[13:47] <tedg> Saviq, Great, thanks!
[13:49] <mhr3> tedg, constructing an event isn't exactly a command-line friendly thing to do
[13:49] <kgunn> hey guys...meant to ask, is it me? :) or is ./run(on desktop) broken atm ?
[13:50] <kgunn> its looking for unity.notifications
[13:50] <tedg> mhr3, Yeah, sure.  Just trying to decide what'll be the least work long term.  In theory, it shouldn't change much, no?
[13:50] <kgunn> maybe i'm not passing in the right flag ?
[13:50] <mzanetti> paulliu: does that help you?
[13:51] <tedg> mhr3, It's one event... seems like a whole executable is overkill.
[13:51] <paulliu> mzanetti: Yeah.. thanks.
[13:52] <mhr3> tedg, no, it shouldn't change, but such a tool doesn't exist cause the command line will be a command screen :)
[13:53]  * tedg always wanted to use that autoconf test for max command line length
[14:07] <tedg> Saviq, Oh, thinking about your URL comment from last week.  We need the URL handler to be DBus because we want apps to be able to use it, and apps won't be able to talk to upstart directly.
[14:09] <Saviq> tedg, sure, the app manager could expose that DBus API, but still give to upstart to actually launch it?
[14:10] <mzanetti> nic-doffay: can you do a code review?
[14:10] <mzanetti> nic-doffay: https://code.launchpad.net/~mzanetti/unity/8-lockscreen-design-tweaks/+merge/171089
[14:11] <tedg> Saviq, App manager?
[14:11] <Saviq> tedg, the thing that exposes the app stack for you from Mir
[14:11] <tedg> Saviq, Yes, I think that the launching of apps should be with upstart, along with the URL to activate.
[14:12] <tedg> Saviq, I don't think that should take care of dispatching URLs.
[14:12] <tedg> Saviq, There's no reason to have that logic in there.
[14:12] <Saviq> tedg, something needs to map URL/mimetype to apps
[14:13] <Saviq> tedg, either in an upstart job (I'd prefer that, as this would work just like gnome-open or whatever)
[14:13] <tedg> Saviq, So you'd like to call "url-dispatch http://slashdot.org" and forget.
[14:13] <Saviq> tedg, yup
[14:14] <tedg> Saviq, Okay, I'm good there :-)  Ignore the tech behind the curtain ;-)
[14:14] <tedg> Saviq, Do we know the URLs we need to support for Oct?  http, application, tel ?
[14:15] <Saviq> tedg, I'd say whatever the apps want
[14:15] <Saviq> tedg, via the usual means
[14:15] <Saviq> .desktop?
[14:15] <tedg> Saviq, The manifest format for Click isn't complete for all that yet, so I'd prefer to know what the base ones are to hard code them first.
[14:17] <Saviq> tedg, then whatever apps we want to be able to launch like this
[14:17] <Saviq> tedg, so phone, browser, video, music for sure
[14:17] <tedg> Saviq, Yeah, just trying to avoid building a registration system for Oct.  Let that be v2.0
[14:18] <Saviq> tedg, mhm
[14:20] <kenvandine> sil2100, i've uploaded the fix for check
[14:22] <nic-doffay> mzanetti, sure
[14:24] <mzanetti> and here's another one: https://code.launchpad.net/~mzanetti/unity/8-launcher-new-folding/+merge/171076
[14:24] <moteprime> Hi there. Trying to install unity next on 13.10 but there'a a problem with the guide on: http://unity.ubuntu.com/getinvolved/development/unitynext/#running-unity
[14:24] <mzanetti> who would lik to?
[14:25] <mzanetti> moteprime: define "problem"
[14:25] <sil2100> \o/
[14:25] <moteprime> ./build
[14:25] <moteprime> ./build: 64: ./build: cmake: not found
[14:25] <moteprime> make: * No targets specified and no makefile found.  Stop.
[14:25] <mzanetti> moteprime: try ./build -s
[14:26] <mzanetti> Cimi: could you do this one? https://code.launchpad.net/~mzanetti/unity/8-launcher-new-folding/+merge/171076
[14:26] <moteprime> did that in the step before that.
[14:26] <moteprime> mzanetti: did that in the step before that. seems it work ok.
[14:27] <mzanetti> moteprime: then install cmake yourself
[14:27] <mzanetti> moteprime: apt-get install cmake
[14:27] <moteprime> i did after that. get new error: bzr: ERROR: Parent of "/unity/unity8" does not exist. ﻿
[14:28] <moteprime> mzanetti: mostly just want to report problems with the guide.
[14:29] <mzanetti> moteprime: thing is, this guide is intended for people developing on unity next.
[14:29] <mzanetti> moteprime: being able to solve erros like "cmake: command not found" is kinda a prerequisite for that
[14:30] <sil2100> tedg: hi!
[14:30] <sil2100> tedg: any luck with the libdbusmenu armhf test failures?
[14:31] <mzanetti> moteprime: the bzr issue is a bit weird indeed
[14:31] <Cimi> mzanetti, sure, as soon as my headache disappears
[14:31] <tedg> sil2100, alesage has been trying to get log files on Jenkins.  We might be switching to a porter box today.
[14:31] <mzanetti> moteprime: can you do a "bzr branch lp:unity/8.0" manually?
[14:31] <alesage> tedg, sil2100 I'll be tackling after a mtg
[14:32] <Cimi> mzanetti, Saviq btw I'm on the right path for unlimited scrolling on the calenar
[14:32] <Saviq> Cimi, cool :)
[14:32] <Cimi> mzanetti, 5 items in the model, each time appends or prepends an item to the model, removes one from the other side
[14:32]  * mzanetti doesn't allow himself any more to give advice to cimi in that regard :D
[14:33] <Cimi> mzanetti, still using list model and list view though
[14:33] <mzanetti> Cimi: sounds interesting
[14:33] <Cimi> seems to work
[14:33] <katie> Saviq, hey are you coming to this meeting?
[14:33] <mzanetti> Cimi: cool
[14:33] <Cimi> supports scrolling
[14:36] <sil2100> alesage, tedg: thanks guys :)
[14:37] <moteprime> mzanetti: sorry phone rang,  Manually ?
[14:37] <mzanetti> moteprime: typing that yourself, not using ./buid
[14:38] <moteprime> ok. I think i better quit this. as you say, it's for dev's. i'm in over my head.
[14:39] <moteprime> mzanetti:  ok. I think i better quit this. as you say, it's for dev's. i'm in over my head
[14:41] <moteprime> mzanetti: thanks anyway
[14:42] <mzanetti> dandrader: https://bugs.launchpad.net/touch-preview-images/+bug/1194150
[14:42] <mzanetti> dandrader: what can you think of here?
[14:42] <mzanetti> dandrader: I've seen that behavior too
[14:42] <mzanetti> dandrader: sometimes it seems it just doesn't get the input
[14:48] <dandrader> mzanetti, don't know. haven't experienced that myself yet
[15:31] <mzanetti> dandrader: ping
[15:36] <Saviq> greyback, that it? :D
[15:36] <greyback> Saviq: what did you expect, our life stories?
[15:37] <Saviq> greyback, it took an hour in my calendar!
[15:37] <greyback> Saviq: oh that's wrong
[15:37] <Saviq> greyback, that's precious resource! ;D
[15:37] <greyback> Saviq: Your calendar simply doesn't like you
[15:37] <Saviq> greyback, indeed it does not
[15:46] <dandrader> mzanetti, pong
[15:46] <mzanetti> dandrader: hey. after revealing the launcher for about 200 times I have a feeling whats happening
[15:47] <mzanetti> dandrader: if you hold the phone in your right hand and try to reveal the launcher from the left hand
[15:47] <mzanetti> err
[15:47] <mzanetti> dandrader: if you hold the phone in your right hand and try to reveal the launcher with the thumb
[15:47]  * dandrader listens
[15:47] <mzanetti> dandrader: then its very likely that you put the thumb with full width down
[15:48] <mzanetti> dandrader: not just the tip
[15:48] <mzanetti> dandrader: that is most likely triggering too much vertical deviation and rejecting the gesture
[15:49] <mzanetti> dandrader: you understand what I mean?
[15:49] <dandrader> mzanetti, yes
[15:49] <mzanetti> dandrader: so not sure right now if just increasing the vertical deviation is good...
[15:49] <dandrader> mzanetti, did you put some console.log() of qDebugs to see details on the recognition decision?
[15:50] <dandrader> s/of/or
[15:50] <mzanetti> dandrader: not enough, no... but in the cases where the launcher fails to reveal, also the edge hinting is NOT triggered
[15:50] <mzanetti> => the touch must have happened on the DDA, not outside of it
[15:51] <mzanetti> still it rejects the gesture even though the drag is perfectly horizontal
[15:51] <mzanetti> and it only happens if I hold it exactly like described
[15:51] <mzanetti> if using the index finger, or intentionally holding the thumb to touch more with the tip, revealing of the launcher suceeds 100%
[15:52] <dandrader> mzanetti, it might be worthwhile to have the reporter record his gesture that fails to bring up the launcher and have it attached to the bug report
[15:52] <dandrader> mzanetti, question is how to do that recording
[15:52] <fginther> jibel, ping
[15:53] <dandrader> mzanetti, maybe just some console.log() on touch position changes would be enough
[15:53] <mzanetti> dandrader: well, we could provide packages with the DDA printing out everything it does
[15:53] <dandrader> mzanetti, and then we add such gesture to our qmltest pool
[15:54] <dandrader> that way there would be a precise communication between reporter and devs
[15:56] <sil2100> didrocks: btw.! Unity check failed because one machine got probably struck by the dbus issue
[15:56] <sil2100> didrocks: do you think it's ok to publish anyway?
[15:57] <dandrader> mzanetti, shall I take this bug or are you working on it?
[15:57] <sil2100> Actually no, it's some autopilot issue, it cannot leave the showdesktop mode, looking into that
[15:57] <mzanetti> dandrader: I'm not actively working on it right now, no
[15:57] <didrocks> sil2100: if the result on the other one is fine, yeah, but we should get mhr3 on it when we detect it :)
[15:57] <didrocks> ah ok
[15:57] <mzanetti> dandrader: if you have the time, that would be great
[15:57] <dandrader> mzanetti, do we have fuzzy comparison for floats in qml tests?
[15:58] <mzanetti> dandrader: I think yes...
[15:59] <mhr3> didrocks, i feel dirty now, you used mhr3 as a tool name :P
[15:59] <didrocks> ahah :)
[16:00] <sil2100> didrocks: the bug we have now is 'safe'... it seems autopilot has some state error, and thinks that we're in desktop mode all the time, hm
[16:01] <sil2100> I'll run the publish job without the 'force' ;)
[16:01] <mzanetti> dandrader: hey
[16:01] <mzanetti> dandrader: do a adb shell
[16:01] <mzanetti> dandrader: and then "getevent"
[16:01] <didrocks> sil2100: ok :) please ping QA so that they look at the issue though :)
[16:01] <mzanetti> dandrader: is that something you could work with?
[16:02] <mzanetti> dandrader: getevent -l  <-- for readable names
[16:03] <mzanetti> dandrader: we could have a script that people just start and use it and it converts all the data to some format we can replay
[16:06] <sil2100> didrocks: packaging changes look fine too: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.0.4daily13.06.24-0ubuntu1.diff/*view*/
[16:09] <didrocks> sil2100: +1 from me :)
[16:13] <jibel> fginther, pong
[16:15] <fginther> jibel, is there a way to debug the cu2d-qa-head tests on the test system itself?
[16:15] <jibel> sil2100, getent is better than grep to check if a user or group exists. Also I think there might have a situation where this job will start before autopilot is installed
[16:17] <fginther> jibel, also. the autopilot job for these jobs are not being published (for example: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/75/)
[16:17] <sil2100> jibel: hm, how can we force this being called after autopilot installation? Which upstart job does that?
[16:20] <sil2100> jibel: since this must be essentially called after package installation, otherwise it doesn't make sense - I wanted to do that in the run-autopilot script at first, but didrocks recommended using a upstart job
[16:21] <didrocks> sil2100: run-autopilot script won't worked, you are already logged in when it happens
[16:21] <jibel> sil2100, yes, because in run-autopilot the user is already logged in and any group membership change won't have effect until next login
[16:22] <sil2100> Makes sense, yes
[16:22] <sil2100> jibel: so how can we force upstart ordering?
[16:24] <fginther> sil2100, what issue are you working on with group membership?
[16:25] <fginther> sil2100, I think I'm seeing an issue with the autopilot group and uinput
[16:25] <sil2100> fginther: https://code.launchpad.net/~sil2100/otto/autopilot_add_setup_upstart_job/+merge/171075
[16:25] <sil2100> fginther: yes, solving that
[16:25] <sil2100> fginther: since I checked and ubuntu was not in the autopilot group
[16:26] <fginther> sil2100, very cool
[16:28] <sil2100> jibel, didrocks: never really used upstart too much, but maybe adding 'start on (starting lightdm and stopping otto-setup) ?
[16:29] <didrocks> sil2100: I don't know much, try poking james as well? (but what you tell makes more)
[16:29] <didrocks> sil2100: oh, and laney might know!
[16:32] <fginther> didrocks, hello. What's the recommendation for addressing a test failure that's caused by an external package (i.e. a qa-head test is failing due to a change in bamf lp:1193502)?
[16:32] <jibel> sil2100, it would be start on (starting lightdm and stopped otto-setup)
[16:33] <jibel> fginther, you can start the job and connect with the KVM if you want to see the tests running live
[16:33] <sil2100> \o/
[16:33] <sil2100> So I was close :)
[16:33] <jibel> fginther, I enabled publication of AP jobs, thanks for pointing it
[16:34] <fginther> jibel, thanks. sil2100 indicated that the problem I'm investigating is already being fixed
[16:34] <jibel> didrocks, we should change the runner to add an option to not shutdown even if all the tests are done, otherwise if you start the test env after a run it will shutdown immediately because there is nothing to run
[16:36] <didrocks> jibel: yeah, we can have it shipping a config for it
[16:44] <sil2100> jibel: pushed modifications
[17:06] <Saviq> aaaargh I added reminders for the standup meeting...
[17:06] <Saviq> now I can't get rid of them at all
[17:07] <Saviq> stupid Lighting adds reminders to all the events in the past, but doesn't mark them dismissed <facepalm>
[17:09] <sil2100> fginther: jibel: if you guys have a moment, could you review that otto merge? Thanks :)
[17:09] <tvoss> Saviq, ping
[17:09] <Saviq> tvoss, pong
[17:36]  * greyback eod
[17:56] <Trevinho> fginther: it seems that the bamf problem you mentioned is likely to be caused by the fact that now it's upstart that launches bamfdaemon... and it seems that something is not correctly initialized at that point... mhmh
[17:58] <fginther> Trevinho, are you able to reproduce the issue?
[17:59] <Trevinho> fginther: yes... probably you get the same also when launching any app from terminal, I get it not matched with any desktop file
[17:59] <Trevinho> fginther: it doesn't happen with unity launcher since it uses the desktop notifications
[18:01] <Trevinho> fginther: ah, no... sorry wrong example
[18:01] <Trevinho> fginther: the real problem is debugging it easly, as it happens only when bamfdaemon is started by init
[18:02] <fginther> Trevinho, mhm, I see
[18:03] <Trevinho> fginther: does it happen also when you run the single test by hand?
[18:04] <fginther> Trevinho, no. the problem only shows itself when the test is started from the autostart method
[18:14] <Trevinho> fginther: it seems like that the process parent pid confuses BAMF.. I'm able to reproduce the issue by using syspeek indicator... launching that on init, causes bamf to match the gnome system monitor as syspeek itself when I launch it from the indicator menu... No other way to reproduce it though :/
[18:15] <Trevinho> fginther: oh, well nautilus seems to be affected as well, weird issue
[18:38] <seb128> Trevinho, hey (3rd try, maybe that one is working ;-)
[18:38] <Trevinho> seb128: hey
[18:38] <Trevinho> did you ping me before? :o
[18:38] <seb128> Trevinho, yes, this morning (with context ;-) and again this afternoon
[18:38] <Trevinho> seb128: weird, I didn't see any notification... sorry about this
[18:39] <Trevinho> seb128: anyway what's up?
[18:39] <seb128> Trevinho, current saucy matches nautilus with the wrong .desktop for me, is that a known issue?
[18:39] <seb128> I get a "?" icon matching it
[18:39] <Trevinho> seb128: yes, I'm already on it :)
[18:39] <Trevinho> seb128: I don't know if there's a bug, but I've noticed that
[18:39] <seb128> which seems to be /etc/xdg/autostart/nautilus.deskop (I pinned it to the launcher and looked at the config)
[18:39] <Trevinho> seb128: it seems that upstart launches apps with startup-notification..
[18:39] <seb128> Trevinho, that might be following the nautilus 3.8 update, but that desktop is using NoDisplay=true...
[18:39] <seb128> oh
[18:39] <Trevinho> seb128: I'm not sure if this is something that it's a good thing, but...
[18:40] <seb128> well, you are on it, so all good
[18:40] <seb128> Trevinho, thanks ;-)
[18:41] <Trevinho> seb128: well, I've noticed this and... I'm not really sure if it's upstart or bamf that shoudl actually avoid  this...
[18:42] <seb128> Trevinho, remind me again why bamf doesn't ignore NoDisplay=true .desktop files?
[18:43] <Trevinho> seb128: at the beginning it didn't that, then I've added the support for it
[18:43] <Trevinho> seb128: I forgot to filter manually added .desktop files such as the one that are set on startup-notifications
[18:43] <Trevinho> seb128: however the rationale is also to try to match an application when possible with a valid .desktop file
[18:44] <Trevinho> seb128: as no-display is mostly related to an application list (such as dash app view), not to the dock
[18:44] <Trevinho> seb128: however right now we mostly ignore no-display desktop-files... at least they have a minor prioerity
[18:44] <Trevinho> priority*
[18:45] <seb128> Trevinho, nautilus installs like 5 .desktop, how do we determine the best match then?
[18:45] <Trevinho> matching the ones in autostart folder it'st still a bug tough
[18:45] <seb128> Trevinho, NoDisplay should be fallback imho
[18:45] <seb128> not primary choice
[18:45] <Trevinho> seb128: in fact it's what we do now, but desktop-id is the main priority
[18:49] <seb128> Trevinho, ok, I don't know what changed, if it's nautilus 3.8 or something with the session/upstart happening recently
[18:49] <Trevinho> seb128: don't know, but it's not the only case...
[18:49] <Trevinho> seb128: and I guess it's also due to upstart way to launch things
[18:49] <Trevinho> seb128: need to check fully, but I guess it's that
[18:50] <seb128> Trevinho, ok, well as long as you can reproduce you can debug
[18:50] <seb128> Trevinho, let me know if you need debug infos though
[18:50] <seb128> Trevinho, I get the issue here with nautilus
[18:50] <Trevinho> seb128: yeah, unfortunately on new sessions only :|
[18:50] <seb128> new sessions?
[18:50] <seb128> like not after killing bamf?
[18:51] <seb128> or new configs?
[18:51] <seb128> because it happens with my user config which is not new
[18:51] <Trevinho> seb128: oh, it's actually gnome-session
[18:52] <seb128> that got updated to 3.8
[18:52] <Trevinho> seb128: no... it happens only on fresh sessions :)
[18:52] <Trevinho> seb128: here's my dbus call on launched signal... (b'/usr/share/applications/nautilus.desktop', ':1', int64 15693, @as [], {'startup-id': <'compiz-15566-tricky-nautilus-0_TIME36276131'>, 'origin-desktop-file': <b'/usr/share/applications/compiz.desktop'>, 'origin-prgname': <b'compiz'>, 'origin-pid': <int64 15566>})
[18:53] <Trevinho> ops, sorry wrong paste
[18:53] <Trevinho> (b'/etc/xdg/autostart/nautilus-autostart.desktop', '', int64 15599, @as [], {'origin-prgname': <b'gnome-session'>, 'origin-pid': <int64 15367>})
[18:54] <Trevinho> it will be easy to filter these .desktop files out though
[18:55] <seb128> "these"?
[18:55] <seb128> xdg ones?
[18:56] <seb128> or NoDisplay=true ones?
[18:58] <Trevinho> seb128: I think xdg ones... as NoDisplay are to be filtered, but also xdg ones, as most of them are not using NoDisplay
[18:58] <seb128> right
[18:59] <seb128> I still think that NoDisplay should be enough
[18:59] <seb128> nautilus.desktop is a visible item
[18:59] <seb128> while /etc/xdg/autostart/nautilus-autostart.desktop is not
[18:59] <seb128> the visible one should match first
[19:17] <Trevinho> seb128: yes, that's true... the problem is that nautilus uses the same pid for all the instances, and this changes the matching code path
[19:17] <Trevinho> seb128: that's why just doing nautilus -q workarounds the issue
[19:17] <Trevinho> seb128: just to know is there already a bug open for this?
[19:18] <seb128> Trevinho, not that I know, do you want me to open one?
[19:18] <Trevinho> seb128: oh, would be nice, thanks
[21:07] <mhall119> tvoss: hey, can you clear something up for me?
[21:07] <mhall119> is XMir an X server in it's own right, or does it just run X.org on top?
[21:42] <tedg> mhall119, I believe it's an xserver that has it's "driver" as Mir
[21:52] <mhall119> ok, so anything that another DE might have expected to be available from x.org will still be there