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