[08:33] <Cimi> mzanetti, ping
[08:34] <Cimi> ah ok he's on holiday
[08:54] <Saviq> mhr3, we need to re-search when form_factor changes
[08:55] <Saviq> mhr3, with the branch you posted, the binding isn't setting the form factor early enough - the initial, empty search is already sent out
[08:55] <mhr3> Saviq, makes sense, will add it to my category override branch, k?
[08:55] <Saviq> mhr3, yeah
[08:55] <mhr3> Saviq, although it kinda sucks
[08:55] <Saviq> mhr3, I know
[08:56] <Saviq> mhr3, but I've no idea how to make it better
[08:56] <Saviq> mhr3, other than hardcoding it "lower" in the stack - which sucks more
[08:56] <mhr3> could make the first search a bit more delayed i guess
[08:57] <mhr3> s/a bit more//
[08:57] <Cimi> Saviq, how do I test the failing autopilot?
[08:57] <Saviq> Cimi, the small branch I just posted
[08:57] <Saviq> ?
[08:57] <Cimi> Saviq, the diff?
[08:57] <Saviq> Cimi, no idea what you mean ;)
[08:58] <Cimi> Saviq, I meant, I want to make autopilot to fail with my branch
[08:58] <Cimi> Saviq, so I know when I fix it :)
[08:58] <Saviq> Cimi, just write the test that fails
[08:58] <Cimi> Saviq, test shouldn't fail, should revert to default bg
[08:58] <Saviq> Cimi, ah that's what you mean
[08:59] <Cimi> so i need to test if it reverts
[08:59] <Saviq> Cimi, just write more tests for the background
[08:59] <Cimi> I think autopilot fails because doesn't have gsettings or so
[08:59] <Cimi> I had this concern, the piece of coe in shell.qml was written by michael
[08:59] <Saviq> Cimi, no, it fails because there are no wallpapers installed in jenkins
[08:59] <Cimi> because my original code was much longer
[09:00] <Cimi> and we were discussing about this possible failure
[09:00] <Cimi> here we go
[09:00] <Saviq> Cimi, there's at least two more tests that need to be added
[09:00] <Cimi> I wonder why CI merged it in the first place :\
[09:00] <Saviq> Cimi, yeah, that's weird
[09:00] <Saviq> Cimi, 1) that it reverts back to the default on failure
[09:00] <Saviq> Cimi, 2) that it doesn't reset the GSettings value
[09:00] <Saviq> Cimi, as looking at the code I believe 2) isn't correct either
[09:01] <Saviq> Cimi, add those two tests in tst_Shell.qml
[09:01] <Saviq> Cimi, and you'll know whether it's working or not
[09:01] <Cimi> ok
[09:01] <Saviq> Cimi, then we can test with ap
[09:02] <Saviq> mhr3, could you include the "re-search onFormFactorChanged" with the scopes-send-form-factor branch instead?
[09:02] <Saviq> mhr3, and drop the Timer from ScopeView.qml, too - it doesn't do anything
[09:02] <mhr3> Saviq, ok
[09:03] <Saviq> mhr3, we can make "phone" the default form factor for now
[09:03] <Saviq> mhr3, and later we'll know early on start, too
[09:04] <Saviq> mhr3, as in, m_formFactor("phone") in Scope::Scope()
[09:04] <mhr3> right
[09:04] <Saviq> instead of the Binding { }
[09:04] <Saviq> mhr3, but still we should re-search onFormFactorChanged, probably
[09:06] <Saviq> dednick, a medium-priority bug #1207269 for you
[09:07] <Saviq> dednick, also https://code.launchpad.net/~saviq/unity8/reenable-battery-drag-test/+merge/178911
[09:10] <Saviq> dednick, one thing about ↑ is that on Manta it took quite a long time to complete the swiping test (it would drag it down to 0)
[09:10] <Saviq> dednick, so we might want to fix that as part of the merge
[09:11] <dednick> Saviq: hm. ok, i havent tried 5.1 yet. just downloaded yesterday
[09:12] <nic-doffay> Saviq, give me a shout when you have a moment.
[09:12] <dednick> Saviq: will try get to it today
[09:15] <Saviq> dednick, 5.1 meaning Qt 5.1
[09:15] <Saviq> dednick, it's not in any image
[09:15] <Saviq> dednick, it's in ppa:canonical-qt5-edgers/qt5-beta-proper
[09:15] <Saviq> dednick, so it's really preparation work
[09:16] <Saviq> dednick, and as mentioned - medium priority
[09:16] <Saviq> nic-doffay, SHOUT!
[09:16] <dednick> Saviq: ah, didnt realise we had a ppa for 5.1. i d/led from website
[09:17] <nic-doffay> Saviq, so I got a new brief from design for this option selector. The animations are more complicated. It's going to need a lot of redoing. Does it make sense to at this point?
[09:17] <Saviq> nic-doffay, is there anything I can see?
[09:17] <nic-doffay> Saviq, yeah let me forward you a mail.
[09:17] <Saviq> thanks
[09:18] <nic-doffay> Some are easily accomplished early on the timeline. But others are more complicated. It would require procedural animations triggering each other upon completion instead of just simple state changes/transitions.
[09:18] <nic-doffay> Saviq, ^
[09:19] <Saviq> nic-doffay, transitions can have SequentialAnimations in them
[09:19] <Saviq> nic-doffay, so that's not necessarily difficult
[09:19] <Saviq> nic-doffay, but let me see what you got
[09:19] <nic-doffay> Saviq, that does help!
[09:20] <nic-doffay> Saviq, sent.
[09:20] <Saviq> nic-doffay, thanks
[09:25] <Saviq> nic-doffay, it looks fine - not complicated that much
[09:25] <mhr3> Saviq, hmm, there's something really odd, unity sends two Search()es on startup, the first one has the form-factor, the second doesn't... will try to fix that and then the Binding should be good enough
[09:25] <nic-doffay> Saviq, would you just recommend SequentialAnimations in transitions to accomplish that?
[09:25] <Saviq> mhr3, see if the Timer isn't causing that
[09:25] <Saviq> nic-doffay, only thing I'm afraid of is the "catching-up" of the selected items when the list contracts
[09:26] <Saviq> nic-doffay, as we've seen that if you select Option 4, it wouldn't always remain on screen
[09:26] <nic-doffay> Saviq, yeah that's what I was most concerned about myself.
[09:26] <Saviq> nic-doffay, but we can treat that as a bug for the time being
[09:26] <Saviq> nic-doffay, the rest should be easily achievable
[09:27] <nic-doffay> Saviq, the main thing I was wondering how to achieve with transitions was the fade out tick completely then fade in chevron etc.
[09:27] <Saviq> nic-doffay, yeah, SequentialAnimation
[09:28] <Saviq> nic-doffay, it should be a single image, even
[09:29] <Saviq> nic-doffay, just SequentialAnimation { UbuntuNumberAnimation { fade_out }; PropertyAction { change_source }; UbuntuNumberAnimation { fade_in } } or similar
[09:29] <nic-doffay> Saviq, yep I get that part but in the state you can only set a to: and from:
[09:30] <Saviq> nic-doffay, http://qt-project.org/doc/qt-5.0/qtquick/qtquick-statesanimations-animations.html#transitions-during-state-changes
[09:30] <Saviq> nic-doffay, it will be a little bit more complicated, as you need to "propagate" the state to the delegates
[09:31] <nic-doffay> Saviq, I've implemented that already.
[09:31] <Saviq> nic-doffay, just run for it, you'll manage
[09:31] <Saviq> nic-doffay, and if you have any issues in particular, ask
[09:31] <Saviq> nic-doffay, but it's doable relatively easily
[09:31] <Saviq> nic-doffay, you're overthinking it ;)
[09:31] <nic-doffay> Saviq, it's mainly that fade in/fade out I was wondering about.
[09:31] <Saviq> nic-doffay, ok cool
[09:32] <Saviq> nic-doffay, I'd probably just have a single SequentialAnimation that would be triggered onIconSourceChanged
[09:32] <dednick> anyone know much about qt event loops?
[09:32] <Saviq> nic-doffay, that would just take all your cases into account
[09:32] <Saviq> tsdgeos, your cue ↑↑ ;)
[09:32] <Saviq> nic-doffay, it's a sort of CrossFadeImage, really
[09:33] <Saviq> nic-doffay, so think if we couldn't use that - adding the possibility for it to be sequential and not parallel
[09:33] <tsdgeos> dednick: some, what's up?
[09:34] <dednick> tsdgeos: :) specifically related to the loopLevel. would a loop level 2 be a eventLoop inside loop level 1?
[09:35] <tsdgeos> dednick: i'd say so, es
[09:35] <tsdgeos> es -> yes
[09:36] <dednick> tsdgeos: i'm actually wondering if you know the event loop "structure" of a running app? where gui events come in vs glib events.
[09:37] <tsdgeos> i used to, but it's one of the things you forget easily :D I'd say "there's probably not a but in the event handling" but i found a bug there a few years ago so i won't say it
[09:37] <tsdgeos> let me try to refresh my memory
[09:37] <tsdgeos> s/found/fixed
[09:38] <tsdgeos> it was 4.x times too, may have changed a bit since then
[09:38] <dednick> tsdgeos: it relates to a problem i'm seeing with dbus signals generating qt events not being processed.
[09:42] <tsdgeos> dednick: so you have a dbus object that doesn't recive its signal?
[09:42] <tsdgeos> or?
[09:44] <dednick> tsdgeos: a dbus signal is causing the deletion of an object through a listview, but the deleteLater issued by the listview for the delegate is never actually actioned because the loopLevels dont match what is expected.
[09:45] <LCID_Fire> I see my application icon/name correctly in dash, but when I open it, it does not show up in the taskbar.
[09:46] <LCID_Fire> Hover on tasks gives me "untitled window"
[09:46] <LCID_Fire> where does it read these settings from?`
[09:46] <tsdgeos> dednick: wow
[09:46] <nic-doffay> Saviq, this is how I'm currently attempting it. https://pastebin.canonical.com/95553/
[09:47] <nic-doffay> The main thing I'm wondering about is how to set opacity via the state to properly work during the transition.
[09:47] <nic-doffay> (obviously needs some amendments to match the brief still)
[09:47] <nic-doffay> This is regarding only the image.
[09:47] <nic-doffay> on the right
[09:47] <dednick> tsdgeos: yeah, it's really weird. i'm not really sure what's going on.
[09:48] <dednick> tsdgeos: if i change the connection between dbus and qt to Qt::QueuedConnection, it works.
[09:48] <dednick> tsdgeos: but i'm trying to understand why :)
[09:49] <tsdgeos> dednick: change it where?
[09:50] <dednick> the dbus signal handler sends an invokeMethod to qt. I changed that to use QueuedConnection
[09:50] <dednick> tsdgeos: it's not dbus directly. it's gmenumodel
[09:51] <Saviq> nic-doffay, yeah, that looks too complicated to be in all of the delegates
[09:51] <tsdgeos> dednick: ah, ok
[09:51] <Saviq> nic-doffay, I'd look into CrossFadeImage to see how usefult it'd be (I imagine it'd be simple to make it sequential instead of parallel)
[09:52] <dednick> tsdgeos: i guess maybe dbus signals are processed on a lower loop level than the ui runs?
[09:52] <tsdgeos> should not
[09:52] <dednick> tsdgeos: being glib
[09:53] <nic-doffay> Saviq, that method didn't work anyway.
[09:53] <tsdgeos> dednick: but may be
[09:53] <nic-doffay> What was confusing me was how to change the state between chevron and tick and fade in /out.
[09:53] <tsdgeos> to be honest without having some time to devote to it i'm mostly guessing :D
[09:54] <nic-doffay> But I'll look into CrossFadeImage.
[09:54] <tsdgeos> and it seems you've already put that time on it
[09:54] <Saviq> nic-doffay, just look at the expanded property of the OptionSelector in the delegates
[09:54] <Saviq> nic-doffay, and change the image accordingly
[09:54] <dednick> tsdgeos: i have absolutely no idea about the levels. :) i was just guessing myself. maybe i'll take a look into that now.
[09:55] <tsdgeos> dednick: levels is just a loop inside a loop
[09:55] <tsdgeos> question is, why we have a loop of level 2
[09:55] <Saviq> nic-doffay, if needed, some additional booleans (to cater for the pause from the brief) might be needed
[09:55] <Saviq> nic-doffay, again, you'll get there
[09:55] <tsdgeos> that's evil and we should never have loops inside loops if possible
[09:56] <dednick> tsdgeos: ahha. qt loves loops in loops.
[09:56] <tsdgeos> dednick: hmmm, not really
[09:56] <dednick> tsdgeos: that's how modal dialogs work isnt it?
[09:56] <tsdgeos> they are heavly discouraged
[09:56] <dednick> tsdgeos: used to be anyway
[09:59] <nic-doffay> Saviq, where can I find info on CrossFadeImage?
[10:00] <Saviq> nic-doffay, http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/qml-crossfadeimage.html
[10:18] <Cimi> Saviq, why 12.10 and not 13.10?
[10:19] <Saviq> Cimi, that's just where they are
[10:19] <Saviq> Cimi, no more reasons
[10:19] <Cimi> yeah but it's confusing :P
[10:19] <Cimi> I was wondering that the other day
[10:43] <tsdgeos> Saviq: greyback: all: can you guys have a look at https://code.launchpad.net/~aacid/unity8/category-expansion/+merge/178726 ? I'm not really happy how i'm "exporting" the expandable/filtered status so that the header can show the correct image, but can't think of any other way at the moment
[10:43] <Saviq> tsdgeos, will do
[10:43] <greyback> tsdgeos: sure, once I'm done with your other MR
[11:10] <Cimi> Saviq, I'll keep working on the bug tonight, I have afternoon off (too blody hot here to work)… I started doing tests and now I am thinking how to fix the code
[11:13] <Saviq> Cimi, cool, tests failing?
[11:15] <nic-doffay> Saviq, I've managed to get something similar. My methods drastically differed though.
[11:15] <nic-doffay> I did use the CrossFadeImage though.
[11:16] <nic-doffay> It handled a lot of what I was wondering about.
[11:16] <Saviq> nic-doffay, so you're probably unsetting its source and setting it again later?
[11:16] <Saviq> nic-doffay, so that it fades out and back in?
[11:16] <nic-doffay> Saviq, yeah.
[11:16] <Saviq> nic-doffay, yeah, would be better to just build a "sequential" mode into it
[11:17] <Saviq> nic-doffay, so that when you set the new source you're done with it
[11:17] <Saviq> nic-doffay, and it would internally fade the image out, replace the source, fade it in again
[11:17] <nic-doffay> Saviq, next step is to handle the ShaderEffect I had applied to the image.
[11:17] <nic-doffay> the one which colours the component.
[11:17] <nic-doffay> It's a bit more complicated with CrossFadeImage.
[11:18] <Saviq> tsdgeos, instead of the toggleCollapse on all of the delegates, maybe would be easier to just change the delegates' state if (expandedIndex == index)?
[11:19] <Saviq> nic-doffay, do we actually need to color it?
[11:19] <Saviq> nic-doffay, we probably do, for theming, yeah
[11:19] <nic-doffay> Saviq, yeah def.
[11:20] <nic-doffay> Saviq, and it's better colouring it with a shader then having more assets.
[11:20] <Saviq> nic-doffay, yeah yeah, thing is that Icon { } handles it internally
[11:21] <Saviq> nic-doffay, maybe we should have a CrossFadeIcon that would use Icon { }s instead of Image { }s
[11:21] <tsdgeos> Saviq: not sure if i understand that
[11:21] <Saviq> tsdgeos, you have toggleCollapse() on the delegate
[11:21] <tsdgeos> yes
[11:21] <tsdgeos> you mean i can do it on the header code?
[11:21] <Saviq> tsdgeos, that looks for the currently expanded item and un-expands it
[11:22] <Saviq> tsdgeos, but because there can only ever be a single expanded item
[11:22] <Saviq> tsdgeos, the delegate could just change state if expandedIndex is its index
[11:22] <Saviq> tsdgeos, so that toggleCollapse would just change the expandedIndex
[11:22] <Cimi> Saviq, yes
[11:22] <Saviq> Cimi, good
[11:22] <Cimi> Saviq, will make it not fail :P
[11:23] <tsdgeos> ah, you mean filter: expandedIndex != index
[11:23] <Saviq> tsdgeos, yeah more or less
[11:23] <Saviq> tsdgeos, the toggleCollapse is too complicated for sure
[11:23] <tsdgeos> Saviq: sure, that works, i am not worried about that, i'm more worried about the sectionDelegate storing a "pointer" to the delegate
[11:28] <Saviq> tsdgeos, we could have Binding { }s in the delegate itself
[11:29] <Saviq> tsdgeos, to ListView.section
[11:29] <Saviq> or not, that would just be the text, right?
[11:29] <tsdgeos> yeah
[11:30] <tsdgeos> the delegate and the section don't really know eachother
[11:30] <tsdgeos> i added that item(index) funciton to LVWPH so that the sectiondelegate can query the delegate
[11:30] <tsdgeos> it will work since we never kill the delegate without killing the sectiondelegate
[11:30] <tsdgeos> but feels a bit weird
[11:38] <nic-doffay> Saviq, who should I chat to about that Icon in CrossFadeImage?
[11:39] <Saviq> nic-doffay, Kaleo was reviewing it originally
[11:39] <Saviq> https://code.launchpad.net/~laney/ubuntu-ui-toolkit/crossfadeimage/+merge/170391
[11:40] <Saviq> dednick, we don't need the .qmltypes in packages, do we?
[11:40] <dednick> Saviq: packages being?
[11:40] <Saviq> dednick, the .debs
[11:40] <Saviq> dednick, they're only used for qtcreator to do its magic
[11:41] <Saviq> dednick, but then it should be enough for us to have them generated locally
[11:41] <Saviq> dednick, and anyway it feels like we should have the .qmltypes static in our source tree
[11:41] <Saviq> dednick, at least when we stabilize, of course
[11:41] <dednick> Saviq: ah. well they are helpfull for projects outside unity8 because we import from packages. And if anyone decides to import from us...
[11:41] <Saviq> dednick, which they shouldn't ;)
[11:43] <Saviq> dednick, I'll go for a "if there's no qmlplugindump, don't fail" for now
[11:43] <dednick> Saviq: ok
[11:43] <Saviq> dednick, needed for cross builds
[11:47] <Saviq> tsdgeos, I think it's ok, nothing better comes to mind
[12:04] <dednick> WOOOOO. finally figured out this damn event loop crap.
[12:04] <dednick> only taken 3 days...
[12:09] <greyback> anyone using today's image having problems with wifi?
[12:12] <greyback> reboot seems to have sorted it. /unmsg all
[12:30] <larsu> so I'm writing a QQuickImageProvider for themed icons, and I'm wondering when requestedSize is set. Does anyone know?
[12:31] <larsu> it's not when using it from an Image element (component?) and setting its width/height
[12:32] <larsu> ah, sourceSize. Weird.
[12:34] <tsdgeos> greyback: yeah same happened here last time
[12:34] <tsdgeos> dednick: cool, explain!
[12:35] <dednick> tsdgeos: the glib event dispatcher doesnt increment the loopLevel before running g_main_context_iteration, which i think it is supposed to.
[12:35] <greyback> larsu: it's useful for things like SVG, as the SVG is converted into a pixmap, and that pixmap is held in memory. Then Image width/height scales that pixmap
[12:36] <dednick> tsdgeos: either that, or we should always be using queued connections from glib events...
[12:36] <tsdgeos> dednick: qmenumodel is sending a glib events or is processing glib events?
[12:36] <larsu> greyback: yeah I just figured that having source and display size separately is indeed a good idea. For example, the Image component gets resized when width/height aren't given
[12:38] <dednick> tsdgeos: processing glib events, and doing things which end up posting to qcorepplication.
[12:38] <tsdgeos> dednick: i see, we're on the bleeding edge and got cut :D
[12:38] <greyback> larsu: yep
[12:38] <dednick> tsdgeos: i havent tried 5.1 it might be fixed there.
[12:39] <tsdgeos> dednick: cleeding edge "feature wse" i meant
[12:39] <tsdgeos> i guess not much people is processing glib events in qt apps
[12:39] <dednick> tsdgeos: indeed
[12:39] <dednick> i've got a test app which reproduces the issue now, so i'll just post a bug to qt
[12:41] <tsdgeos> dednick: i'd suggest you engage with people at #qt-labs or the mailing list, bugs seem to be "low" in priority this days from what i see
[12:41] <tsdgeos> i.e. much easier to get answers
[12:42] <dednick> tsdgeos: ah. ok, i'll try that
[12:50] <MacSlow> larsu, ping
[12:51] <larsu> MacSlow: hey
[13:22] <mterry> My sound seems broken in saucy now.  Is that true for anyone else?
[13:22] <Saviq> mterry, seems to work here
[13:22] <mterry> hrm
[13:25] <seb128> mterry, where/how broken?
[13:26] <mterry> seb128, I'm actually seeing lots of weirdness
[13:26] <mterry> seb128, so no devices show up in the system settings sound panel.  no sound indicator
[13:26] <mterry> seb128, also, g-s-d, indicator-datetime, and deja-dup-monitor are all CPU spinning it seems
[13:26] <seb128> mterry, laney has been hitting issues where /run/user/1000/pulse was owned by root and breaking stuff
[13:27] <seb128> mterry, maybe that's what you get?
[13:27] <mhr3> Saviq, once i have support for the overridden categories, where would the actual call to it go? inside GenericScopeView?
[13:27] <mterry> seb128, I don't have anything under /run/user
[13:27] <Saviq> mhr3, we'll still need DashHome / DashApps, that would be small subclasses of GenericScopeView
[13:28] <Saviq> mhr3, just setting the overrides up
[13:28] <seb128> mterry, are you talking about touch or desktop?
[13:28] <mterry> seb128, desktop
[13:28] <seb128> how is that possible?
[13:28] <mhr3> Saviq, hm, ok
[13:30] <seb128> mterry, do you have libpam-systemd installed?
[13:30] <mterry> seb128, yup, latest
[13:31] <seb128> mterry, weird, did you screw your pam stack?
[13:31] <mterry> seb128, I haven't played with that recently, no
[13:31] <seb128> mterry, logind should create a /run/user/<uid> for every user at login and make e.g XDG_RUNTIME_DIR point to that dir
[13:31] <seb128> mterry, that's what e.g dconf is using
[13:31] <didrocks> sounds familiar to me :)
[13:32] <seb128> didrocks, how did you fix it?
[13:32] <didrocks> (what I had with the pam stack screwed up and no good group)
[13:32] <mterry> seb128, XDG_RUNTIME_DIR is set to /run/user/1001
[13:32] <didrocks> I rm my diverged conffiles
[13:32] <mterry> But that doesn't exist
[13:32] <seb128> mterry, https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1162836
[13:32] <didrocks> and rerun libpam-systemd post-inst
[13:32] <seb128> ups
[13:32] <seb128> mterry, ignore that, wrong bug
[13:32] <didrocks> https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1176910
[13:33] <didrocks> seb128: I think you wanted that one? ^ (mine)
[13:33] <seb128> mterry, ^ check if you are in that case
[13:33] <seb128> didrocks, yes
[13:33] <seb128> didrocks, though I doubt it's it
[13:33] <didrocks> yeah, just give it a shot in any case ;)
[13:33] <seb128> mterry has XDG_RUNTIME_DIR correctly set
[13:34] <seb128> mterry, anything in syslog about that?
[13:34] <seb128> mterry, does it persist across reboots?
[13:34] <mterry> seb128, yes, it persists
[13:34] <seb128> mterry, is pam_systemd.so listed in /etc/pam.d/common-session ?
[13:36] <mterry> seb128, it is now, but I just ran pam-auth-update manually, and didn't check beforehand.  Will reboot in case I fixed something
[13:36] <mterry> er, log out and in again
[13:36] <seb128> ok
[13:38] <mterry> seb128, no luck
[13:38] <seb128> :-(
[13:38] <seb128> mterry, nothing in /var/log/auth.log or syslog?
[13:39] <seb128> mterry, mount | grep /run/user ?
[13:41] <mterry> none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
[13:41] <seb128> that seems fine
[13:41] <seb128> can you mkdir a dir in there?
[13:42] <mterry> Aug  7 08:33:59 conga systemd-logind[674]: Failed to create /run/user: File exists
[13:42] <mterry> Is that a normal thing?
[13:42] <mterry> sure, root can mkdir there
[13:42] <seb128> normal user?
[13:43] <seb128> mterry, no, that's not normal
[13:43] <seb128> # ls -ld /run/user
[13:43] <seb128> drwxr-xr-x 3 root root 60 Aug  7 13:42 /run/user
[13:43] <mterry> seb128, no, but they shouldn't be able to, eh?
[13:43] <seb128> they should
[13:43] <seb128> it's a tmpfs
[13:43] <seb128> the subdirs should be owned by the respective user
[13:43] <mterry> drwx------ 2 root root 40 Aug  7 09:42 /run/user
[13:43] <mterry> seb128, sure, but I don't have any  subdirs
[13:43] <seb128> mterry, try to sudo rmdir it and reboot
[13:43] <seb128> ?
[13:44] <mterry> seb128, my /run/user is empty
[13:44] <seb128> mterry, seems like because of the permissions being wrong
[13:44] <mterry> seb128, but even in your /run/user, the 'other' group can't create subdirs
[13:44] <seb128> you are right
[13:45] <seb128> they are created through pam
[13:45] <seb128> mterry, https://bugs.launchpad.net/session-manager-touch/+bug/1206897
[13:45] <seb128> seems a bit similar
[13:45] <seb128> mterry, did you play with mir?
[13:45] <mterry> My syslog is full of pulse freaking out about no run dir
[13:45] <mterry> seb128, yes, I'm running mir now
[13:45] <seb128> mterry, ok, that's this bug I just pointed then
[13:46] <seb128> mterry, fix the permission on the dir and you should be fine
[13:47] <mterry> yup
[13:54] <mterry> seb128, all better, thanks
[13:56] <seb128> mterry, yw!
[13:57] <seb128> mterry, did you run the touch session script on your desktop? or do we have something else break the permissions on that dir?
[13:57] <mterry> seb128, I probably ran the touch session script
[13:57] <seb128> ok
[14:04] <seb128> dednick, Saviq: hey, I'm looking at adding a screen brightness slider to system settings, I was trying to figure out how the current touch indicator one is done ... is indicator-battery the right codebase? it seems custom cpp code, is that going to change?
[14:05] <Saviq> seb128, yeah, it's going to be integrated into indicator-power, right dednick tedg ↑?
[14:06] <seb128> Saviq, the indicator design doesn't have that slider on https://wiki.ubuntu.com/Power#Indicator
[14:06] <dednick> seb128: lp:indicator-power/phablet  is what we use on the phablet at the moment. will be replaced with indicator-power
[14:07] <dednick> seb128: and yes, the phablet version is packaged as indicator-battery
[14:07] <seb128> dednick, so standard unitymenumodel use?
[14:07] <dednick> seb128: yep
[14:07] <seb128> for the next one
[14:07] <seb128> ok
[14:07] <seb128> I'm going to wait on that I guess
[14:07]  * seb128 is trivial to find something to do which is not blocked on other pieces to land :p
[14:08] <seb128> Saviq, while you are there, you don't have a good heuristic to suggest to check from qml if the app is running on desktop or a device form factor?
[14:10] <MacSlow> larsu, dednick: ok... let's put that discussion about the intended use of UnityMenuModel for the extended snap-decisions (http://ubuntuone.com/3plX5yStNdhHqFS4yLqtO4) here...
[14:10] <dednick> larsu, MacSlow: so for the activate, if we need to send data, should this not be the 3rd param of "g_action_group_activate_action" with type validation against "g_menu_item_get_attribute_value(item, G_MENU_ATTRIBUTE_TARGET)" ?
[14:11]  * dednick still doesnt know what a target is...
[14:12] <larsu> dednick: read https://live.gnome.org/HowDoI/GAction
[14:12] <dednick> or rather typed against g_action_group_get_action_parameter_type
[14:12] <dednick> ooo
[14:12] <larsu> dednick: this already happens automatically if you call model.activate(index)
[14:13] <dednick> larsu: it looks like it's just sending the type, not data.
[14:13] <larsu> dednick: you only need to do it manually for custom widgets, which unitymenumodel doesn't know anything about
[14:13] <larsu> dednick: it sends whatever is in "target"
[14:13] <larsu> dednick: in other words: if you worry about the target, you're doing it wrong :P
[14:13] <dednick> larsu: why? the backend knows what target is surely?
[14:14] <dednick> as it set it..
[14:14] <larsu> dednick: but the backend doesn't know from which menu item an action was activated, which is precisely what "target" does
[14:15] <dednick> larsu: i see
[14:15] <larsu> dednick: but as I said, please don't worry about the target
[14:15] <MacSlow> dednick, larsu: "An action supports two operations: activation, invoked with an optional parameter (of the correct type, see above)..." so it is meant to offer this type of functionality
[14:16] <MacSlow> dednick, larsu: I don't see anything wrong with having that also exposed through QMenuModel/UnityMenuModel
[14:16] <dednick> larsu: we used to be able to send data with an activation in qdbusactiongroup
[14:17] <larsu> MacSlow: using actions would be okay (in fact, next gen notification spec will work with actions), but your dialog has nothing to do with a menu
[14:17] <larsu> dednick: and you should still be able to do that, but you should not have to worry about it if it is data that comes from the backend anyway
[14:18] <larsu> dednick: does the action.activate() you added not take a parameter?
[14:18] <dednick> larsu: no. that's the point
[14:18] <dednick> larsu: copied from model.activate(index)
[14:19] <larsu> dednick: model.activate() calls into the tracker, which sets the target. action.activate() needs to take a param, so that you can set it from the custom widgets
[14:19] <larsu> dednick: sorry I didn't catch that in the review, I'll add it
[14:20] <MacSlow> larsu, dednick: When I define an action in model (on the backend) that takes a parameter, I can't trigger it on the frontend anymore... as it's probably no longer found be QMenuModel/UnityMenuModel because of the added parameter
[14:21] <MacSlow> larsu, dednick: so I wait for that patch... I gladly test/review that with my proof-of-concept thing here
[14:22] <larsu> MacSlow: yes, but you're missing my point about GMenuModel being inappropriate for this case. Please extend fdo notifications instead.
[14:22] <dednick> larsu: there isn't a model.activate() anymore. i didn't see a difference..
[14:22] <MacSlow> Saviq, ^
[14:23] <MacSlow> larsu, I will use this via the notifications (with a new hint) in the end
[14:23] <Saviq> larsu, we discussed this last week, didn't we?
[14:24] <Saviq> larsu, fdo notifications isn't enough to be flexible enough
[14:24] <Saviq> well, it's not flexible enough
[14:24] <MacSlow> larsu, that "button.connect::login", the "::login"-part will not be used... I just added it because of your suggestion.
[14:24] <Saviq> and we're already (ab)using *MenuModels in other places, so it only feels right to only abuse a single thing
[14:25] <larsu> Saviq: we discussed this about the list of access points. I didn't know you want to make a toolkit out of it.
[14:25] <larsu> Saviq: fdo notifications can easily do this
[14:25] <Saviq> larsu, again, not a toolkit, just maybe 4 types of renderings
[14:25] <larsu> dednick: dude, you're right. Was I on crack when I reviewed this?! I'll fix it.
[14:26] <Saviq> larsu, a password entry, a list of access points, a login (username/password) entry
[14:26] <dednick> larsu: ta.
[14:26] <MacSlow> Saviq, larsu: btw... I will not expose a full set of toolkit... just two types of "dialogs" (one per added hint)... that's the current plan... finer changes might some along the way... and upon feedback I'll get once I present the fully working proof-of-concept thing
[14:27] <Saviq> larsu, how can fdo notifications do this?
[14:27] <MacSlow> larsu, ping/email me when you're done please
[14:27] <larsu> Saviq: I know that's what we agreed on, but that's not what MacSlow is doing. He has *one* additional notification type "use-gmenumodel" and tries to shoehorn the four dialogs through there
[14:28] <Saviq> larsu, yeah, that's what I was considering as well, the differentiation between the dialogs would happen on the menumodel root type
[14:29] <Saviq> larsu, we can do it either way, seemed more normal to just pass responsibility on to *MenuModel after you know you want to use a *MenuModel at all
[14:30] <Saviq> don't see much difference/value between that and adding another hint to notifications to say which type of a dialog we're looking at
[14:33] <larsu> Saviq: right, but now we need to encode all of the ui in the menu and then aggregate data from all menuitems into a reply
[14:33] <larsu> which normal menus never do
[14:33] <Saviq> larsu, not necessarily
[14:33] <larsu> hence this is not possible in GMenuModel
[14:34] <Saviq> larsu, if we agree that there's a single action with a known name
[14:34] <Saviq> larsu, that the password entry is supposed to "write" to, for example
[14:34] <Saviq> larsu, that would be enough
[14:34] <larsu> Saviq: exactly, but for that the server needs to know about the exact type of the dialog
[14:35] <Saviq> larsu, well, it's the server that initiates / builds the dialog, no?
[14:35] <larsu> wait, which side is the server for you?
[14:35] <larsu> I mean the thing displaying the notifications
[14:35] <Saviq> larsu, how is that the server lol ;)
[14:36] <Saviq> larsu, frontend / backend
[14:36] <Saviq> larsu, shell is frontend
[14:36] <larsu> Saviq: https://developer.gnome.org/notification-spec/
[14:36] <larsu> the server is the thing displaying notifications
[14:36] <Saviq> larsu, anyway, it can know that later, after having talked to the MenuModel, looking at the root type
[14:37] <larsu> okay so now the server nees to know about the specific types of dialogs
[14:37] <larsu> why in the world are we still encoding them as a menu model?
[14:37] <larsu> the server knows what it is, it could jut slap the two text boxes on there
[14:37] <Saviq> larsu, yes, that's what I want, the menumodel just needs to have actions to allow communication between the backend and frontend
[14:38] <larsu> shit, I said server again. Sorry :)
[14:38] <Saviq> larsu, I don't want / care for the menumodel to say:
[14:38] <Saviq> - root type: log entry
[14:38] <Saviq> | - label: "Username"
[14:38] <Saviq> | - text_entry
[14:38] <Saviq> | - label: "Password"
[14:38] <Saviq> | - password_entry
[14:38] <Saviq> | - buttons
[14:39] <Saviq> |   - cancel_button
[14:39] <Saviq> |    - ok_button
[14:39] <Saviq> -[ ]
[14:39] <Saviq> larsu, we just need text_entry, password_entry and a button
[14:39] <larsu> no!
[14:39] <MacSlow> Saviq, that's what I'm currently doing... http://pastebin.ubuntu.com/5958778
[14:39] <larsu> we need *nothing*
[14:40] <larsu> only a simple notification type: password-entry-dialog
[14:40] <Saviq> larsu, how do we then pass the password back to the service?
[14:41] <larsu> Saviq: an action
[14:41] <Saviq> larsu, and the state of the buttons (for they have to be disabled while you've not typed enough characters for a WEP password, for example)
[14:41] <Saviq> larsu, yeah, that's what I meant
[14:41] <larsu> right, that can be enceoded in the dialog shell-side
[14:41] <larsu> *encoded
[14:42] <Saviq> larsu, that's pushing too much towards the shell, IMO, but that's a detail
[14:42] <Saviq> larsu, can be solved with an action just as well
[14:42] <larsu> I agree, but the shell needs to know about this anyway
[14:43] <larsu> gmenumodel is not smart enough for dialogs
[14:43] <larsu> obviously, because it's for MENUS
[14:44] <Saviq> larsu, yeah, of course
[14:45] <Saviq> larsu, there would be an action "button_active" or something that the shell will look for
[14:45] <Saviq> larsu, and activate / deactivate the button based on it
[14:45] <Saviq> larsu, but the UI itself would be static - built in the shell from the start
[14:45] <Saviq> MacSlow, larsu, so yes, we don't want a real menu structure in there, just a set of predefined actions
[14:46] <Saviq> larsu, agreed?
[14:46] <larsu> I don't understand... you want the entry to send a dbus message on every key stroke and the service to find out whether the action should be sensitive?
[14:46] <MacSlow> Saviq, well that's the case
[14:46] <Saviq> larsu, or it can be simpler - a set of "minimum_length", "exact_length", "maximum_length" actions
[14:46] <Saviq> larsu, that the shell then enforces
[14:47] <larsu> Saviq: right, that's what I was thinking
[14:47] <Saviq> larsu, can probably work well enough
[14:47] <larsu> Saviq: if you want the shell to be a bit more dumb (which is a good point that I agree with), we could send extra data over fdo hints
[14:48] <larsu> that will make the shell-side a bit more complex
[14:48] <Saviq> larsu, yeah, I'd rather not mix'n'match
[14:48] <larsu> but also more elegant and easier reusable if we have many of those dialogs
[14:48] <larsu> Saviq: hm?! I'm proposing to use fdo notification spec instead of GMenuModel
[14:49] <Saviq> larsu, yes, but we need GMenuModel anyway, we won't be able to pass everything through fdo will we
[14:49] <Saviq> larsu, or it stops being elegant soon enough anyway
[14:49] <larsu> Saviq: no, we need notifications anyway
[14:49] <larsu> GMenuModel is the new thing in the mix
[14:50] <Saviq> larsu, how would you pass a list of WiFi networks through, with their signal strength
[14:50] <larsu> tbh, I wouldn't even use it for the networks list now that I think more about it
[14:50] <larsu> Saviq: aa{sv}
[14:50] <Saviq> larsu, and keeping it up to date
[14:50] <Saviq> larsu, that would mean sending over the whole list over and over again
[14:50] <larsu> ya, that's more interesting. There are two options:
[14:50] <Saviq> larsu, UI nightmare
[14:50] <larsu> (1) use a menu model for that part of the dialog
[14:50] <larsu> (2) simply resubmit the notification every 30s or so
[14:51] <Saviq> every 30s is not up to date ;)
[14:51] <larsu> Saviq: do you switch on and off networks all the time?
[14:51] <larsu> I don't know much about NetworkManager, but I can't imaging it scanning much more often
[14:51] <larsu> *imagine
[14:53] <Saviq> larsu, anyway, I believe shoe-horning it into fdo notifications is just as bad as shoehorning it into GMenuModel
[14:53] <Saviq> but the latter is more flexible
[14:53] <larsu> I'm telling you that this is close to impossible with GMenuModel
[14:53] <larsu> we're already using notifications
[14:53] <Saviq> larsu, what is close to impossible? just a list of entries with associated signal strength actions?
[14:54] <larsu> I think your perception of what gets shoehorned into what is upside down
[14:54] <larsu> Saviq: again, this is about GMenuModel, not actions
[14:54] <larsu> this is frustrating. Let me think about it some more and make a proposal on how to solve this.
[14:54] <Saviq> larsu, GMenuModel consists of a menu structure and actions, no?
[14:57] <Saviq> larsu, I just don't want to devise a new & different DBus protocol for every dialog type we need
[14:57] <Saviq> larsu, when all we need is really a list of key/value pairs passed one way or the other
[14:58] <Saviq> larsu, and that's what I thought we could abuse menumodels for, just keeping a list of actions and potentially a list of items to display in the wifi selector (as we do already in network indicator, btw)
[14:59] <mhr3> Saviq, how do i do the deriving that you mentioned? i tried changing the top level thing in DashApps.qml to ScopeView: public GenericScopeView, but that didn't really work
[14:59] <larsu> Saviq: right, and I was totally fine with that (and is what I proposed as (1) above). What I'm saying is impossible is putting whole dialogs in there
[14:59] <larsu> Saviq: GMenuModel is merely a way to describe menus. It uses actions for activation and state, but actions are in no way tied to menus
[15:00] <Saviq> mhr3, huh? just "GenericScopeView { ... }"
[15:00] <Saviq> larsu, that's completely fine
[15:01] <larsu> okay
[15:01] <mhr3> and that's exactly what i didn't know :)
[15:01] <larsu> Saviq: so what we're looking for is a balance between a toolkit-over-dbus and the shell not having to much logic in it
[15:01] <Saviq> larsu, I think there's just a misunderstanding here, and MacSlow sorry if I gave you the impression that the GMenuModel should hold the whole definition of the UI
[15:02] <Saviq> MacSlow, the QML for each type (based on the model's root type) should be just more-or-less static QML
[15:02] <Saviq> MacSlow, with some things driven by the menumodel actions (like labels, for example)
[15:02] <larsu> then we have a menu model to communicate the type to the shell
[15:03] <larsu> just get rid of the model, like I said
[15:03] <MacSlow> Saviq, so how is it meant to look like then?
[15:03] <larsu> slap the thing into the notification, or into the shell
[15:03] <larsu> depending on how you want aforementioned balance to be
[15:03] <larsu> for the network list, you can use a menu model (though I'd recommend against it)
[15:05] <Saviq> larsu, I just don't think fdo notifications are flexible enough to pass everything through it
[15:06] <Saviq> MacSlow, we need a minimal, predefined set of actions that the shell "knows" about, by name
[15:07] <MacSlow> Saviq, so more something like "com.canonical.snapdecision.password-dialog" and that then determines (on the frontend-side) what the thing will actually look like?
[15:07] <larsu> Saviq: they are, believe me. (here's a proof: you can pass arbitrary dbus types in "hints", a dbus message is simply a list of dbus types)
[15:07] <Saviq> MacSlow, yes, the root type
[15:08] <larsu> MacSlow: don't hardcode the action name, make the client set a hint
[15:08] <MacSlow> larsu, the problem with that is much more work for the app-developers to "just get a password" from the user
[15:08] <Saviq> larsu, but as said before - that's not good enough for when you want an updated list
[15:08] <larsu> just in case
[15:09] <Saviq> larsu, that would be the root type, so that will be hardcoded, and I'm perfectly fine with hardcoding the action names
[15:09] <larsu> MacSlow: this is for app developers?!
[15:09] <Saviq> larsu, MacSlow not "app devs", just system apps
[15:09] <Saviq> or services, more
[15:10] <Saviq> larsu, there's no "just in case", IMO - if you want a password dialog, you need to provide action a and action b, it won't work otherwise
[15:11] <Saviq> MacSlow, snap decisions are only for system services, remember
[15:11] <MacSlow> larsu, Saviq: oh... I thought it was meant as a more general "stock dialog" to help have a consistent look for whenever some app needs some authentication to happen
[15:11] <Saviq> MacSlow, and also I agree with larsu here that actually going through a menumodel it will be *more* difficult
[15:11] <Saviq> MacSlow, no, that would lead to spoofing
[15:11] <Saviq> MacSlow, apps would start stealing your passwords
[15:11] <Saviq> MacSlow, by impersonating system services
[15:12] <MacSlow> Saviq, yeah... I was a confused about that... but ok
[15:12] <larsu> Saviq: it's easier service side to be able to specify an action name, so that actions can be reused
[15:13] <larsu> Saviq: can't they do that anyway by sending Notify?
[15:13]  * MacSlow redoes the whole thing
[15:13] <larsu> I mean, nothing is stopping them from setting the right hints
[15:13] <Saviq> larsu, currently nothing
[15:13] <Saviq> larsu, but we'll have to protect it obviously
[15:15] <Saviq> larsu, I don't think it's a huge gain to reuse actions if you have to name them in hints...
[15:16] <Saviq> I simply don't think there will be much reusing for them
[15:17] <larsu> we don't dictate action names anywhere else
[15:17] <larsu> and I can't think of an example right now either, but that doesn't mean there isn't one
[15:17] <larsu> which is why I said "just in case" ;)
[15:18] <larsu> Saviq: not sure how you'll be able to protect it
[15:18] <larsu> can apparmor block messages based on its contents?
[15:18] <Saviq> larsu, not sure, in which case we'll need a whitelist in the notifications server
[15:18] <larsu> yeah, that would work as well
[15:19] <larsu> a bit ugly though
[15:19] <larsu> you could also just have a separate dbus call...
[15:19]  * larsu hides because he already made that point a while ago
[15:20] <Saviq> larsu, sure, we could separate the snap decisions interface
[15:20] <Saviq> larsu, I don't think that would be a huge difficulty, but not solving much either
[15:21] <tedg> Saviq, I can't seem to find the upstart job configuration for unity8.  Is that not written yet?
[15:21] <Saviq> tedg, lp:ubuntu-touch-session
[15:21] <Saviq> or well
[15:21] <Saviq> wherever ubuntu-touch-sessionlives
[15:21] <Saviq> +[ ]
[15:22] <larsu> Saviq: except that apps couldn't trick users into giving them passwords...
[15:22] <Saviq> tedg, http://bazaar.launchpad.net/~phablet-team/session-manager-touch/trunk/view/head:/upstart-session/unity8.conf
[15:22] <Saviq> larsu, that can be solved either way
[15:23] <Saviq> larsu, separate DBus interface isn't really a requirement, maybe just a cleaner solution
[15:23] <tedg> Saviq, Thanks, is that expected to move to the unity8 branch?  Seems more appropriate, no?
[15:23] <larsu> Saviq: yes, but the whitelist way is hacky and separates policy from apparmor
[15:23] <tedg> That's a pretty scary startup.
[15:24] <Saviq> larsu, I agree, we might yet get there, but that's not the issue at hand ;)
[15:24] <tedg> I think that apparmor can look at arguments, but it's not going to have super advanced parsing.
[15:24] <larsu> Saviq: of course :)
[15:24] <tedg> You could probably do "arg1=snap" but not break out structs
[15:24] <Saviq> tedg, yeah, will move to lp:unity8 at some point
[15:24] <larsu> tedg: ya, this would have to look into the hints dict
[15:25] <larsu> why the "sleep 2" before starting unity?
[15:25] <tedg> I don't think it could easily break down a dict.  I mean it does that internally, but the config file I don't think is that advanced.
[15:25] <tedg> larsu, Yeah, or the lack of a ofono-setup job?
[15:26]  * tedg is going to worry about that for now
[15:26] <tedg> isn't
[15:26] <larsu> tedg: yes, probably not, and I think it shouldn't be able to. That would make it easier to get things wrong
[15:26] <Saviq> larsu, for other stuff to settle - hopefully will go away later
[15:27] <larsu> Saviq: I thought upstart handles this for us?
[15:27] <Saviq> larsu, that's assuming the services settle up in a timely manner ;)
[15:27] <Saviq> larsu, or upstart has a way to tell when something settled
[15:27] <Saviq> tedg, ofono-setup is just a small run'n'forget script
[15:27] <tedg> Saviq, It can get signals from a process if it requires more time.
[15:28] <tedg> Saviq, Sure, doesn't mean that can't be a job.  Then it can check for things like file changes, etc.
[15:28] <Saviq> tedg, yeah, the process needs to know that it can do that, which we probably don't yet
[15:28] <larsu> Saviq: what tedg said. Also, unity should be able to function without these services, right?
[15:28] <Saviq> larsu, it does, even
[15:28] <Saviq> larsu, but if maliit doesn't settle in time, you don't get OSK for shell
[15:29] <tedg> larsu, I think part of the deps is to make the fallbacks not trigger, and thus make things take less CPU.
[15:29] <larsu> fair enough, 2s just seems so random
[15:29] <larsu> and makes the login take longer
[15:29] <Saviq> tedg, larsu anyway, it's ricmm's work
[15:29] <larsu> which is something we should optimize for
[15:30] <larsu> fair enough, I just noticed it
[15:30] <Saviq> larsu, how often do you boot your phone, otoh ;)
[15:30] <tedg> Perhaps I can convince seb128 to fix the Unity7 scripts by just adding a bunch of sleeps ;-)
[15:30] <Saviq> not a priority, simply
[15:30] <seb128> tedg, NO
[15:30] <seb128> ;-)
[15:30] <larsu> Saviq: not often, but when I do, I want it to be there quickly, because I'm waiting for it
[15:31] <tedg> seb128, We're trying to keep parity. ;-)
[15:31] <Saviq> larsu, I know
[15:34]  * tedg doesn't always reboot his phone, but when he does, it usually involves drinking heavily.
[15:35] <mhr3> larsu, are you still at the uni?
[15:35] <larsu> mhr3: yes, in c236. Come up, it's nice here!
[15:37] <MacSlow> Saviq, larsu: so you were expecting something along the lines for this... http://pastebin.ubuntu.com/5959326 ?
[15:38] <larsu> MacSlow: no.
[15:38] <Saviq> MacSlow, no menus at all
[15:38] <larsu> I was expecting that you put that information into notifcationh hints
[15:38] <Saviq> I wasn't ;)
[15:38] <larsu> I know :)
[15:39] <larsu> Saviq: we should talk about this over a beer some time ;)
[15:39] <Saviq> larsu, indeed
[15:39] <larsu> much easier than irc
[15:39] <larsu> Saviq: I'm in the land of beer right now, you should come down ;)
[15:39] <tedg> Saviq, Whoa, why no menus?
[15:39] <MacSlow> larsu, Saviq: I wait for a conclusion on this from your side... otherwise I'm really lost and don't know how to proceed.
[15:40] <Saviq> tedg, 'cause larsu says so ;D
[15:40] <Saviq> tedg, that's about system-dialogs^Wsnap-decisions with password entries etc.
[15:40] <tedg> I'm guessing you didn't tell larsu all the requirements :-)
[15:40] <larsu> tedg: he did.
[15:40] <tedg> It's not just passwords
[15:40] <Saviq> tedg, if I knew them! ;D
[15:41] <Saviq> tedg, but yeah, larsu knows what it's about
[15:41] <tedg> We need to be able to do things like the Wifi AP prompt as well: https://wiki.ubuntu.com/Networking#Connecting_to_wi-fi.2C_prompted
[15:41] <MacSlow> tedg, I know even less and have to implement it... how about that? :)
[15:41] <larsu> tedg: believe me, using menus for those dialogs is not only ugly, it's also damn near impossible
[15:41] <Saviq> tedg, larsu just disagrees whether menumodels are needed at all
[15:41] <larsu> tedg: wait, that large one as well?
[15:41] <tedg> larsu, It's not really "using menus" it's just providing a list of QML files to load.
[15:42] <tedg> larsu, The phone one.
[15:42] <larsu> right
[15:42] <larsu> tedg: that's not what MacSlow was implementing
[15:43] <larsu> MacSlow: I'll write a summary email which explains this a bit more concise than this backlog
[15:43] <larsu> MacSlow: (tomorrow)
[15:43] <tedg> My understanding is "here's a menu model load the widgets for it"
[15:43] <larsu> tedg: I'll cc you as well if you like
[15:43] <tedg> Sure, probably pete-woods as well.
[15:43] <larsu> okay, will do
[15:43] <tedg> He's the one hitting MacSlow's stuff.
[15:44] <MacSlow> tedg, that's what I'm trying to get implemented http://ubuntuone.com/3plX5yStNdhHqFS4yLqtO4 ... using... by now I've no real idea to be honest
[15:45] <MacSlow> tedg, I had the password-dialog almost fully working...
[15:45] <tedg> The screenshots make sense... but I'm more worried about architecture :-)
[15:46] <pete-woods> MacSlow: looks nice - I'm more interested in the means for how I push the data to your pretty UI, though :)
[15:46] <tedg> MacSlow, Though it really should be "Not an NSA van" ;-)
[15:46] <tedg> They'd never say if it was.
[15:47] <pete-woods> tedg: pretty sure that public hotspots are legally required to help the govt the same as any other ISP
[15:47] <larsu> tedg: or maybe they do because you'd never suspect that's theirs ;)
[15:48] <pete-woods> at least that's how it works in the UK
[15:48] <tedg> pete-woods, I'm sure they don't actually care about them.  If you already have the backbone, why care about the leaf nodes.
[15:49] <larsu> I agree, they probably just fall under the same legal definition
[15:49] <pete-woods> tedg: I would guess it depends on what bit of the govt you are - I would bet that some have better connections than others
[15:50] <tedg> I guess you could get person-to-person traffic.  Not sure that'd be useful, but it could be.
[15:50] <tedg> pete-woods, Internal politics at it's best :-)
[15:51] <tedg> pete-woods, BTW, I was looking at the code a bit, you probably want to suck in the AP list from the indicator and reexport it.
[15:52] <tedg> pete-woods, We could put it on another object path.
[15:52] <tedg> pete-woods, Reason being is that there's deduplication code in indicator-network for the APs that we don't want to have two instances of.
[15:52] <pete-woods> tedg: fair enough - atm I'm most interested in the going out part - the going in part was pretty easy
[15:53] <tedg> pete-woods, Understand, just trying to ensure we have the same list throughout the UI.
[15:53] <tedg> Not a high priority obviously.
[15:53] <pete-woods> tedg: should be easy enough to connect to the indicator's gmenumodel, right?
[15:53] <tedg> Yeah, it shouldn't be a big deal.
[15:54] <pete-woods> tedg: although that will mean I have to talk to a QAbstractItem model, which has one of the most awful API's I've ever had to deal with
[15:54] <tedg> More worried that you'd try to write that same code at some point.
[15:54] <tedg> pete-woods, Can you just use the glib API?  You'd just need one object that you could pass back into export.
[15:55] <pete-woods> tedg: it's not the connecting that's the problem, it's just iterating - I'm just being dramatic really ;)
[15:55] <MacSlow> pete-woods, I don't know yet
[15:56] <pete-woods> MacSlow: no problem :)
[15:56] <tedg> pete-woods, Okay.  I'm just saying that the DBus import in GLib exports GMenuModel, so you can just link it as a section and "magic happens."  There's no iterating.
[15:56] <MacSlow> pete-woods, I have some ideas... but those usually get rejected.
[15:56] <Saviq> MacSlow, lol
[15:57] <pete-woods> tedg: are we even using a gmenumodel now? - I'm going to stop any work on the indicator 'til I'm sure, as I have tests for creating the right menu already, but they could already be redundant
[15:57] <MacSlow> Saviq, but it's true... I know just very little about UnityMenuModel... and sofar have been using it wrongly in my first week of exposure to it
[15:58] <larsu> pete-woods: why would you need to iterate?
[15:58] <Saviq> MacSlow, I know even less, so no worries there
[15:58] <MacSlow> Saviq, I rather wait for some clarifying eMails from you and larsu and then re-do it
[15:58] <tedg> pete-woods, I think that we need to, but there is some discussion.  Waiting to understand more before I comment.
[15:58] <Saviq> MacSlow, yeah, let's see tomorrow
[15:58] <pete-woods> larsu: if I'm transforming the model in any way - atm I don't know what I'm pushing into the WiFi prompt UI
[15:58] <larsu> pete-woods: unitymenumodel gives you a qabstractitemlist from an indicator, which you can just put into a ListView
[15:59] <pete-woods> larsu: if it's just another gmenumodel, then yes, I'll just forward that on
[15:59] <MacSlow> Saviq, really curious how all this will look in the end... when everybody agrees on it :)
[16:00] <larsu> MacSlow: your "when" is very optimistic ... I'd go with "if" for now :P
[16:00] <MacSlow> Saviq, I'm going to try to get the listview for the wifi-APs to look a bit nicer (closer to the scribbles from mpt)
[16:00] <MacSlow> larsu, hope dies last eh :)
[16:00] <larsu> haha, true
[16:01] <tedg> dednick, so I added the signal, but I can't figure out how you guys want includes for tests.  Can you give me a pointer there?  https://code.launchpad.net/~ted/unity8/indicator-signals/
[16:01] <Saviq> MacSlow, remember nic-doffay is working on that
[16:01] <Saviq> MacSlow, so you might take his OptionSelector branch
[16:01] <Saviq> MacSlow, and work with that
[16:01] <MacSlow> Saviq, yeah... I know... I'm not using that yet
[16:01] <MacSlow> Saviq, wanted to jump-start with a stand-in for the time being
[16:01] <nic-doffay> MacSlow, just shout if you want to use it.
[16:02]  * larsu quickly closes the tab before looking at that patch :P
[16:02] <MacSlow> nic-doffay, I'll poing you tomorrow... eod now and I need to get one of my bikes sold :/
[16:04] <nic-doffay> MacSlow, cool. The OptionSelector API is done, it's just visual tweaks and some bug fixes left.
[16:04] <dednick> tedg: which includes?
[16:04] <nic-doffay> So you'll be able to use it without much interruption on the API side.
[16:04] <tedg> dednick, The ones from the pkgconfg line.
[16:05] <tedg> dednick, Added that in like the others for that plugin.  But since it's a member variable it has to be in the header (hate C++), so then the tests need it. :-/
[16:05] <MacSlow> nic-doffay, which of your branches is it... ubuntu-shape-option-selector or list-item-option-selector to get something like https://wiki.ubuntu.com/Networking#wifi-connecting-prompted going?
[16:06] <nic-doffay> MacSlow, that would be based off ListItemOptionSelector.
[16:06] <nic-doffay> But it would need some modding to look like that.
[16:06] <MacSlow> nic-doffay, ok
[16:07] <dednick> tedg: can't you just forward declare?
[16:07] <dednick> and put the include in cpp?
[16:08] <dednick> #lovec++
[16:10] <tedg> Sure, if that's acceptable for the coding style.
[16:14] <dednick> tedg: not sure about coding style regarding forward declarations. but in my opinion, if it's private i dont see why it cant be.
[16:14] <dednick> Saviq: ^ ?
[16:15] <tedg> dednick, Well, I'm a big believer in "define everything once and only once".
[16:15] <tedg> But, I understand that C++ makes this difficult.  So if that's the accepted work around, I'm fine with it.
[16:15] <tedg> I just want my patch to land :-)
[16:17] <dednick> tedg: well the proper way to handle it is to use private data.
[16:17] <dednick> but still requires a forward declare ;)
[16:18] <tedg> I think the pimple design patter works around this problem in C++ probably the best.
[16:19] <tedg> It's kinda silly to use everywhere though.
[16:20] <larsu> Saviq: fyi, https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/add-unity-theme-icon-provider/+merge/179011
[16:45] <theseb> help! can't seem to get nautilus+MIME settting right for .tex files.....nautilus can open them with "Open With" but not using the default "Open"..why?
[16:48] <greyback> theseb: if you right click any .tex file, select "properties" and then click the "Open With" tab, you should be able to set the default "Open" application
[16:50] <theseb> greyback: yea i've done that many times but the "Open" doesn't open ANYTHING even after making sure i selected a default app
[18:27] <mterry> QML question...  What determines what is at the top of the "z" stack?  Order in qml file?  Whichever was made visible most recently?
[18:30] <Saviq> mterry, order between siblings
[18:30] <Saviq> mterry, and then you can override with Item.z
[18:30] <Saviq> mterry, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#z-prop
[18:30] <tvoss_> Saviq, ping
[18:30] <Saviq> tvoss_, pong
[18:33] <mterry> Guh, I can't seem to figure out why this DragHandle isn't receiving events