| === michi__ is now known as michi | ||
| === michi is now known as Guest35414 | ||
| === salem_ is now known as _salem | ||
| === jono is now known as Guest5052 | ||
| === tvoss_ is now known as tvoss|flaky_wire | ||
| === jamesh_ is now known as jamesh | ||
| === tvoss|flaky_wire is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss|flaky | ||
| === seb128_ is now known as seb128 | ||
| Cimi | mzanetti, ping | 08:33 |
|---|---|---|
| Cimi | ah ok he's on holiday | 08:34 |
| Saviq | mhr3, we need to re-search when form_factor changes | 08:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| Saviq | dednick, a medium-priority bug #1207269 for you | 09:06 |
| ubot5 | bug 1207269 in Unity 8 "Indicator animation slow with Qt 5.1" [Medium,Triaged] https://launchpad.net/bugs/1207269 | 09:07 |
| Saviq | dednick, also https://code.launchpad.net/~saviq/unity8/reenable-battery-drag-test/+merge/178911 | 09:07 |
| 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:10 |
| dednick | Saviq: hm. ok, i havent tried 5.1 yet. just downloaded yesterday | 09:11 |
| nic-doffay | Saviq, give me a shout when you have a moment. | 09:12 |
| dednick | Saviq: will try get to it today | 09:12 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| nic-doffay | Saviq, sent. | 09:20 |
| Saviq | nic-doffay, thanks | 09:20 |
| 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:25 |
| 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:26 |
| 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:27 |
| Saviq | nic-doffay, it should be a single image, even | 09:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| dednick | tsdgeos: :) specifically related to the loopLevel. would a loop level 2 be a eventLoop inside loop level 1? | 09:34 |
| tsdgeos | dednick: i'd say so, es | 09:35 |
| tsdgeos | es -> yes | 09:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| tsdgeos | dednick: so you have a dbus object that doesn't recive its signal? | 09:42 |
| tsdgeos | or? | 09:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| tsdgeos | dednick: change it where? | 09:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| nic-doffay | Saviq, where can I find info on CrossFadeImage? | 09:59 |
| Saviq | nic-doffay, http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/qml-crossfadeimage.html | 10:00 |
| Cimi | Saviq, why 12.10 and not 13.10? | 10:18 |
| 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:19 |
| 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 | 10:43 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:10 |
| Saviq | Cimi, cool, tests failing? | 11:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| Saviq | tsdgeos, we could have Binding { }s in the delegate itself | 11:28 |
| Saviq | tsdgeos, to ListView.section | 11:29 |
| Saviq | or not, that would just be the text, right? | 11:29 |
| tsdgeos | yeah | 11:29 |
| 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:30 |
| nic-doffay | Saviq, who should I chat to about that Icon in CrossFadeImage? | 11:38 |
| Saviq | nic-doffay, Kaleo was reviewing it originally | 11:39 |
| Saviq | https://code.launchpad.net/~laney/ubuntu-ui-toolkit/crossfadeimage/+merge/170391 | 11:39 |
| 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:40 |
| 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:41 |
| 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:43 |
| Saviq | tsdgeos, I think it's ok, nothing better comes to mind | 11:47 |
| === alan_g is now known as alan_g|lunch | ||
| dednick | WOOOOO. finally figured out this damn event loop crap. | 12:04 |
| dednick | only taken 3 days... | 12:04 |
| === MacSlow|lunch is now known as MacSlow | ||
| greyback | anyone using today's image having problems with wifi? | 12:09 |
| greyback | reboot seems to have sorted it. /unmsg all | 12:12 |
| larsu | so I'm writing a QQuickImageProvider for themed icons, and I'm wondering when requestedSize is set. Does anyone know? | 12:30 |
| larsu | it's not when using it from an Image element (component?) and setting its width/height | 12:31 |
| larsu | ah, sourceSize. Weird. | 12:32 |
| tsdgeos | greyback: yeah same happened here last time | 12:34 |
| tsdgeos | dednick: cool, explain! | 12:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| 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:41 |
| dednick | tsdgeos: ah. ok, i'll try that | 12:42 |
| === alan_g|lunch is now known as alan_g | ||
| MacSlow | larsu, ping | 12:50 |
| larsu | MacSlow: hey | 12:51 |
| === _salem is now known as salem_ | ||
| === greyback is now known as greyback|lunch | ||
| 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:22 |
| seb128 | mterry, where/how broken? | 13:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| seb128 | mterry, do you have libpam-systemd installed? | 13:30 |
| === greyback|lunch is now known as greyback | ||
| mterry | seb128, yup, latest | 13:30 |
| 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:31 |
| 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 |
| ubot5 | Launchpad bug 1162836 in likewise-open (Ubuntu Precise) "likewise screws up PAM configuration for other services" [Medium,Fix released] | 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:32 |
| ubot5 | Launchpad bug 1176910 in pam (Ubuntu) "pam-auth-update can fail during raring -> saucy upgrade leading you to a broken session" [Undecided,Invalid] | 13:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| mterry | seb128, no luck | 13:38 |
| seb128 | :-( | 13:38 |
| seb128 | mterry, nothing in /var/log/auth.log or syslog? | 13:38 |
| seb128 | mterry, mount | grep /run/user ? | 13:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| seb128 | they are created through pam | 13:45 |
| seb128 | mterry, https://bugs.launchpad.net/session-manager-touch/+bug/1206897 | 13:45 |
| ubot5 | Launchpad bug 1206897 in ubuntu-touch-session (Ubuntu) "logind fails to work, falling back to ConsoleKit when /run/users has wrong permissions" [High,Triaged] | 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:45 |
| seb128 | mterry, fix the permission on the dir and you should be fine | 13:46 |
| mterry | yup | 13:47 |
| mterry | seb128, all better, thanks | 13:54 |
| seb128 | mterry, yw! | 13:56 |
| 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 | 13:57 |
| 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:04 |
| Saviq | seb128, yeah, it's going to be integrated into indicator-power, right dednick tedg ↑? | 14:05 |
| 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:06 |
| 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:07 | |
| 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:08 |
| 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:10 |
| * dednick still doesnt know what a target is... | 14:11 | |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| MacSlow | larsu, dednick: so I wait for that patch... I gladly test/review that with my proof-of-concept thing here | 14:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| Saviq | larsu, yeah, that's what I was considering as well, the differentiation between the dialogs would happen on the menumodel root type | 14:28 |
| 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:29 |
| 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:30 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| === mpt_ is now known as mpt | ||
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| larsu | gmenumodel is not smart enough for dialogs | 14:43 |
| larsu | obviously, because it's for MENUS | 14:43 |
| Saviq | larsu, yeah, of course | 14:44 |
| 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 |
| === alan_g is now known as alan_g|tea | ||
| Saviq | MacSlow, larsu, so yes, we don't want a real menu structure in there, just a set of predefined actions | 14:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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 |
| === dednick is now known as dednick|afk | ||
| 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:50 |
| 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:51 |
| 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 |
| === alan_g|tea is now known as alan_g | ||
| Saviq | larsu, what is close to impossible? just a list of entries with associated signal strength actions? | 14:53 |
| 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:54 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| Saviq | mhr3, huh? just "GenericScopeView { ... }" | 15:00 |
| Saviq | larsu, that's completely fine | 15:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| Saviq | larsu, I just don't think fdo notifications are flexible enough to pass everything through it | 15:05 |
| Saviq | MacSlow, we need a minimal, predefined set of actions that the shell "knows" about, by name | 15:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| Saviq | larsu, I don't think it's a huge gain to reuse actions if you have to name them in hints... | 15:15 |
| Saviq | I simply don't think there will be much reusing for them | 15:16 |
| 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:17 |
| 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:18 |
| 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:19 | |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| * 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:26 |
| 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:27 |
| === dednick|afk is now known as dednick | ||
| 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:28 |
| 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:29 |
| 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:30 |
| tedg | seb128, We're trying to keep parity. ;-) | 15:31 |
| Saviq | larsu, I know | 15:31 |
| * tedg doesn't always reboot his phone, but when he does, it usually involves drinking heavily. | 15:34 | |
| mhr3 | larsu, are you still at the uni? | 15:35 |
| larsu | mhr3: yes, in c236. Come up, it's nice here! | 15:35 |
| MacSlow | Saviq, larsu: so you were expecting something along the lines for this... http://pastebin.ubuntu.com/5959326 ? | 15:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| tedg | larsu, The phone one. | 15:42 |
| larsu | right | 15:42 |
| larsu | tedg: that's not what MacSlow was implementing | 15:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 :) | 15:59 |
| === jhodapp is now known as jhodapp|lunch | ||
| 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:00 |
| 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:01 |
| * 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:02 |
| === jasoncwarner__ is now known as jasoncwarner | ||
| 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:04 |
| 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:05 |
| 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:06 |
| dednick | tedg: can't you just forward declare? | 16:07 |
| dednick | and put the include in cpp? | 16:07 |
| dednick | #lovec++ | 16:08 |
| tedg | Sure, if that's acceptable for the coding style. | 16:10 |
| 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:14 |
| 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:15 |
| === greyback__ is now known as greyback|food | ||
| dednick | tedg: well the proper way to handle it is to use private data. | 16:17 |
| dednick | but still requires a forward declare ;) | 16:17 |
| tedg | I think the pimple design patter works around this problem in C++ probably the best. | 16:18 |
| tedg | It's kinda silly to use everywhere though. | 16:19 |
| larsu | Saviq: fyi, https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/add-unity-theme-icon-provider/+merge/179011 | 16:20 |
| === greyback|food is now known as greyback | ||
| === jhodapp|lunch is now known as jhodapp | ||
| 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:45 |
| 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:48 |
| 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 | 16:50 |
| === alan_g is now known as alan_g|EOD | ||
| 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:27 |
| 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:30 |
| mterry | Guh, I can't seem to figure out why this DragHandle isn't receiving events | 18:33 |
| === daek_ is now known as Daekdroom | ||
| === salem_ is now known as _salem | ||
| === jono is now known as Guest48557 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!