and gtk_application_window_add_menu_section (window, id, menu) [14:28] https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=amd64&ver=2.46.0-1&stamp=1443009041 https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=i386&ver=2.46.0-1&stamp=1443009390 [14:28] what happened to break this test? [14:29] good question :/ [14:30] it passes on other architectures [14:34] * Laney is running it in a loop [14:39] ._. [14:41] larsu: i agree with this. someone needs to write a patch :) [14:42] larsu: also: figure out how the heck this works on dbus...... [14:42] /org/gnome/gedit/windows/1/identifier i guess [14:42] ya... [14:42] or maybe /org/gnome/gedit/windows/1/menus/identifier [14:42] I have no better idea either :/ [14:42] i like that more [14:42] indeed, with "menus" [14:43] beyond that, the logic is _fairly_ simple [14:43] until you start thinking about how you'd make this work with the tracker [14:43] ie: how do you 'feed' it the correct external context? [14:45] we either need another GActionGroup-like abstraction (GMenuGroup anyone?) or some callback-based mechanism [14:45] or abuse the muxer [14:45] I was thinking callbacks [14:45] the muxer already deals in accels, so why not also menus? [14:46] the muxer already does too much [14:46] hm, indeed [14:46] it's sort of the logical place for it [14:46] since we expect menus to traverse the same hierarchy as actions [14:46] so the muxer would have set_menu_section() and get_menu_section() ? [14:46] just menu [14:47] yeah [14:47] it's sort of complicated, though [14:47] the namespacing is out of whack [14:47] the action group for the window is associated via "win" [14:47] but we would want this associated via "win.history" or whatever [14:47] which points to using GActionGroup itself as the mediator [14:48] how is this out of whack? [14:48] seems reasonable to me [14:48] muxer_set_menu_section() wouldn't work properly, i'm saying [14:48] hum [14:48] why not? [14:48] https://bugs.launchpad.net/bugs/1498945 claims that glib 2.45.7->8 makes evo ews not work [14:48] Ubuntu bug 1498945 in glib2.0 (Ubuntu) "[libglib2.0] evolution + evolution-ews" [Undecided,New] [14:48] because the identifier would have to be "win.history" [14:49] which means that the things that attach "win" actions wouldn't necessarily have to be associated with "win" [14:49] which is very very odd [14:49] i think what we want to do is add a new interface on GActionGroup for get_menu() [14:49] no [14:49] for dbus action groups that would be implemented by appending "/menus/" to the dbus path and requesting a dbusmenumodel [14:50] I still don't understand the problem. The muxer would be identified by "win" and hold a menu named "history" [14:50] muxers don't have prefixes [14:50] groups do [14:50] muxers are the repository for the root namespace... [14:50] this really really needs to be done as an extension to GActionGroup [14:50] ah indeed, they mux things [14:50] * larsu messed this up [14:50] which is _weird_ by the name [14:51] but really works sort of nicely when you think about it [14:51] I thought we had one for app and win, but we have *one* [14:51] well, we chain, right... ? :) [14:51] we actually _do_ have one for the app and win [14:51] yeah but at the top level we have one [14:51] but they are not named like that [14:51] so ya.. it's all very simple [14:52] GActionGroup grows new _get_menu() method [14:52] the benifit of having it in gactiongroup is that we wouldn't have to touch so many things [14:52] GSimpleActionGroup implements it with a hashtable and setters [14:52] but actions and menus were nicely separated before :/ [14:52] we expose that in the GtkWidget tree in the usual way, plus on GtkApplication and GtkApplicationWindow [14:52] GDBusActionGroup implements it by getting a GDBusMenuModel at the appropriate subpath [14:52] and for exporting we ... do something [14:52] but think about the reason for the separation [14:53] note also that we have gtk_application_get_menu_by_id() [14:54] what's with that? [14:54] that's separate, no? [14:54] it's the resources thing [14:54] I know [14:54] useful for forming gear menus and the like [14:54] ish [14:54] for example: eog pulls out the resources itself when constructing a window [14:54] well, in the beautiful future we can just have a menu-name property on GtkMenuButton and have it mine it out of the muxer [14:54] so they have a new copy of the menu model [14:54] so they can just not care about the window-specific menus [14:54] ya. gedit used to do it this way too [14:55] and simply insert them [14:55] then they fixed their code ;) [14:55] well [14:55] you can't really have window-specific dynamic menus with this [14:55] (i know it doesn't work for eog this way now, but this is what we are discussing) [14:55] I know, I'm fixing it [14:55] but I can't fix it properly until we have this [14:55] the only tricky bit is making sure the app and the window export the menus properly [14:56] and here's the fun part: [14:56] and when do you switch the dynamic sections? [14:56] do we add _list_menus() on GActionGroup interface [14:56] ? [14:56] we don't export a menu per window [14:56] if we do that, then we could make the action group exporter take care of the menu exporting automatically [14:56] which has a nice symmetry with the automatic handling on the other side [14:57] but it means that we need changed signals and _probably_ also need, then, to export this list on dbus as well [14:57] (with change signals there, too) [14:58] yeah we should do that [14:58] so this is worrying now [14:58] everything else would feel hacky I presume [14:58] because either we're going to spam the bus with menus nobody cares about or we need to adjust the GActionGroup dbus protocol (which is something i've wanted to do for a while anyway) [14:59] to be like the menu one? subscribing and all? [14:59] yes [14:59] this model is very nice [14:59] this is turning out to be a very big yak [14:59] at least until our magical explicit-subscription beautiful kdbus future [14:59] it is! [14:59] this is why it wasn't done yet :) [14:59] desrt: tell me how to implement this now [14:59] do you want to shave the whole yak? [14:59] yes [14:59] because you kinda need to... [14:59] can it wait until london? [15:00] we could take a day or two on this together [15:00] it's impossible to even do now [15:00] eog has a open with menu per window [15:00] which is in a popover (so might stay open) [15:00] so I can't just switch the application_get_menu_by_id() section around [15:00] * larsu hates this [15:01] * desrt shrugs [15:01] desrt: yes, it can. We need this for 15.10, but not with all the changes (I'm already preparing a much smaller patch) [15:01] okay [15:01] let's allocate a day or two in london to this [15:01] desrt: don't shrug. This is the biggest shortcoming of gmenumodel, because *every* app needs this [15:01] i think we covered all of the important bits in this discussion [15:01] ya, could do [15:01] i'll start thinking about the new dbus protocol [15:01] I think I'll start hacking on it before to see how it feels [15:02] yeah I might not get into that yet [15:02] something else i want to scratch off at the same time is the 'in transition' thing mclasen was asking about [15:02] maybe also per-target enabled states [15:02] ui elements? [15:02] like prelighting in switches [15:02] for turning on bluetooth or whatever [15:03] yes we should fix that [15:03] it's a pain [15:03] especially with switches [15:03] because they have such a weird quasi-model api [15:03] if you mix that with actions, you almost always get it wrong [15:04] and the other todo: the per-target enable/disable business [15:04] what do we need that for? [15:04] for simple enum/flags-type actions this makes sense, even if we can't possibly hope to do it in the general sense [15:05] like if we have a radiobutton group for connect using: bluetooth/wired/wifi/magic [15:05] ah, indeed [15:05] with detailed actions connectwith::bluetooth, etc. [15:05] desrt: gotta run real quick to pick up a ... package [15:05] and we want to disable only "magic" because there is no magic, but leave the others enabled [15:05] let's do this in London [15:05] good luck :) [15:05] yup [15:05] thanks :) [15:06] * larsu liked the magic example [15:12] infinity, jdstrand: FYI, re-enabling armhf in britney; queue is down to 8 [15:12] err, that was supposed to go into #u-devel [15:21] seb128, I've respun the Ubuntu MATE isos so they now include user-setup 1.48ubuntu7 [15:22] But this issue is still present - https://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/1498544 [15:22] Ubuntu bug 1498544 in user-setup (Ubuntu) "Autologin not correctly enabled on 15.10 installations" [High,Fix released] [15:22] flexiondotorg, patches are welcome [15:24] flexiondotorg, said differently, I've no idea why the fix is not working, I fixed an issue I saw with the shell code and it worked copied in a local script, I'm unsure how to test user-setup [15:24] so somebody who understands that better is going to need to do it [15:37] seb128, OK, I'll take a look. [15:37] flexiondotorg, thanks [15:38] flexiondotorg, it might be that somebody needs to import the updated user-setup in ubiquity [15:38] unsure how that works but I saw ubiquity changelog mentioning such imports [15:38] cyphermox probably knows if that's needed [15:39] yes, that's exactly it [15:39] I can update ubiquity now [15:39] cyphermox, thanks [15:39] flexiondotorg, ^ [15:40] seb128, cyphermox Thanks. [15:40] cyphermox, Anything I can do to help? [15:43] still no Trevinho or andyrock? [15:43] seb128: haven't seen them all day [15:43] seb128: I'm here, did I miss any ping? [15:43] yeah, same here [15:43] oh hi Trevinho :) [15:43] Trevinho, yes, you did, several this morning [15:43] seb128: I was in the call :) [15:43] Trevinho, should watch this channel :-/ [15:43] Ouch... /me reads backlog [15:44] Trevinho: did you file that bug we talked about yesterday (argb windows for csd)? I'd like to subscribe myself [15:44] Trevinho, I tracked down bug #1498775 to the lightdm change to support "audit" [15:44] bug 1498775 in unity (Ubuntu) "Greeter auth doesn't unlock unity lockscreen" [High,New] https://launchpad.net/bugs/1498775 [15:44] Trevinho, unsure why, do you know if unity would need to catch up with pam config changes from lightdm or something? [15:44] Trevinho, I guess it's more one for andyrock though? [15:45] seb128: yeah, he's more on that... [15:45] seb128: did lightdm changed anything on PAM? [15:45] yes [15:45] Trevinho, http://launchpadlibrarian.net/218120238/lightdm_1.16.0-0ubuntu1_1.16.1-0ubuntu1.diff.gz [15:45] is the diff of that update [15:45] +session required pam_loginuid.so [15:46] though you said you were listening to logind [15:46] seb128: adding that to the unity.pam file fixes the issue? [15:46] pam_loginuid.so [15:46] so unsure why that has an impact [15:46] seb128: it might, but not sure what that module does [15:47] maybe we should ask tyhicks [15:47] he did the lightdm change [15:49] seb128: I don't see how the modified pam config would cause that bug [15:50] tyhicks, I don't know what cause it, but that lightdm change is what creates the double unlock issue [15:50] I downgraded/upgraded lightdm several times and confirmed [15:50] hrm [15:51] seb128: have you tried to hack your unity.pam also? [15:51] Trevinho, no, I don't understand pam enough to do that [15:53] seb128: mh ok, I also don't think unity needs it... [15:55] I'm trying some ideas [15:55] tyhicks, thanks [16:00] seb128: if you enter your password a second time, does it log you in? [16:00] (it does here... just wanting to verify that's the case with you too) [16:01] tyhicks, yes [16:01] it's just that it's supposed to unblock directly and not ask again [16:02] seb128: there should be no password prompt at all? [16:04] tyhicks, the greeter should unlock the session [16:04] Trevinho mentioned that unity listens to some logind signal for that [16:04] Yeah, let me be more precise [16:05] seb128: but should you have to enter the password to return back to the original session? [16:05] tyhicks, yes, on the unity-greeter [16:05] ok [16:06] So, we connect to org.freedesktop.login1.Session.Lock/Unlock signals [16:06] seb128: can you verify wether the unlocked signal is emitted for you? [16:07] Trevinho, sorry in an hangout then I need to go for sport, but can try tomorrow morning [16:07] seb128: ok, that's fine... I can check that as well [16:08] seb128: as for the switcher, was just a configuration mess I guess [16:08] seems so [16:08] it might be due to me [16:08] I played with cairo-dock yesterday trying to see if the unity-control-center icon changed when changing panels [16:11] ah, i see [16:11] larsu: as back to your thing... I didn't open any bug yet [16:12] I mean for the argb [16:13] larsu: so there were two things discussing, and they mixed up, so the other thing was related to the double eog/eog panel/deco entry, right? [16:30] Trevinho: looks like it has to do with the pam changes :/ [16:30] Trevinho: I'll have to find some time to dig into it some more later today [16:30] hm, tyhicks what that model does? [16:32] tyhicks, can you comment on the bug? just to avoid that robert_ancell or others dup work not knowing somebody started looking [16:38] Trevinho: that's different and I'm fixing that (by putting a traditional menu on eog) [16:39] larsu: I see, although maybe that could be fixed for every app.. By checking whether the win name matches the menu, and update accordingly for example... [16:40] larsu: for the ARGB thing, instead, I've checked, but unity doesn't do anything special for those windows (a part from not adding decorations), so I guess that gtk should react differently in our scenario === alan_g is now known as alan_g|EOD [16:44] Trevinho: hm? Last time I checked unity didn't draw shadows [16:44] and you said this is hard, because the windows are not rectangular [16:45] larsu: ah, yeah... right... I had saved a change, let me retry it [16:45] thanks :) [16:45] larsu: I was thinking you were speaking of the corners not being transparent [16:45] I am [16:45] they're not because it's disabled in gtk [16:45] and I'm going to enable it as soon as unity can deal with it [16:46] the check is in gtkwindow.c pretty obvious if you want to try [16:46] what would be the change in gtk? Enabling argb or what? [16:46] yeah, ok [16:46] yes [16:46] it's just an if [16:48] k... adding to my list [17:04] bye! [17:04] Laney: good night! [18:00] g'night [18:02] hey [18:02] Trevinho: no putting +session required pam_loginuid.so [18:02] in unity.pam [18:02] does not make sense [18:02] andyrock: yeah, in fact it was my guess [18:03] seb128: does reverting lightdm fix the issue? [18:04] also we had some changes in unity that could cause this issue [19:32] andyrock: it seems so [19:32] andyrock: check with tyhicks also [19:36] Trevinho: reverting the lightdm pam changes, even while keeping the lightdm code changes, results in the expected behavior [19:43] tyhicks: any idea how why this is happening? [19:43] have you tried to check if the logind signal is emitted? [19:44] andyrock: I haven't had a chance to look into it yet [19:44] andyrock: I haven't investigated whether logind is emitting a signal [19:45] andyrock: the pam_loginuid module simply writes the uid to /proc/self/loginuid [19:46] andyrock: I'm guessing that affects logind in some way [19:48] well let me know if you need help investigating the issue [19:49] tyhicks: at least for the unity side [19:51] andyrock: thanks! I hope to get to it soon [20:19] good night! [20:26] Sweet5hark: still enjoying libocon i presume? :) [20:27] ochosi: umm, yes. fratically generating slideware ... [20:27] :> [20:28] good luck then! [20:41] so uh... gonna go out and meet with a couple of friends [20:41] goodnight everybody! [20:42] * desrt will probably be around later in the evening a bit [21:05] hi all [21:29] bye, bbl [22:39] Morning folks. [23:48] Back in a bit, gotta run some errands.