[08:18] hey everyone [08:18] hey ochosi [08:18] mornign [08:18] ali1234: to correct you: i'm not the author of that patch, i solely ported it to work with xfdesktop4.11. but yeah, i guess that kinda makes me responsible for this regression... [08:19] i wonder how to work around that though. maybe only update the wallpaper when xfdesktop exits? [08:20] ochosi, Did you talk to eric about the upower patch for session? [08:20] Noskcaj: sorry, haven't caught him ol in the last two days [08:20] ok [08:20] eric_the_idiot, PING [08:20] just in case [08:21] it's fine, i'll talk to him [08:21] either way, it's not like we're in a big rush already [08:21] you could also simply take his patch and add it to a test-build in a PPA [08:21] then talk to our QA lead about getting it tested [08:22] well darkxst (ubuntu gnome dev) is wanting the transition done ASAP so gnome can be tested [08:23] and debian will be uploading soon too [08:24] yeah, then follow my other suggestion ;) [08:26] ok, will do [08:26] that's what it's going to boil down to anyways, you know [08:26] since eric wrote that one patch, i presume he'll think it's ok [08:27] so we should give it some testing to see whether everything works as expected [08:27] if the xfce4-session maintainer thinks it should be implemented another way, we can always take the upstream solution later [08:53] ochosi: any idea? bug 1321443 [08:53] bug 1321443 in xfce4-settings (Ubuntu) "xfce4-settings-manager toolbar style doesn't change" [Undecided,New] https://launchpad.net/bugs/1321443 [08:54] could it be that (some) gtk3 applications have hardcoded theme/style settings? [08:55] that's more than probable [08:55] also, i've never used that setting so i can't say if it even works for gtk3 [08:57] same here, so no clue [08:57] a quick test indicates it doesnt work for gtk3 [08:59] ok [08:59] so it changes the setting "ToolbarStyle" in Gtk's settings [08:59] that seems like a version independent thing [08:59] but the question is whether they possibly dropped that setting in gtk3 [09:00] or whether it's simply being ignored by apps [09:00] in gtk's settings? [09:00] another thing is that i think themes can modify it [09:00] yeah, check xfce4-settings-editor > xsettings > gtk [09:00] e.g. the ButtonImages setting really works for Gtk2/3 [09:00] right, but that's on the xfce side [09:00] or the button-sizes [09:01] we don't know if these settings are actually applied to gtk3 [09:01] well as i said, as ButtonImages works for both gtk2/3, yes [09:02] ok, so any idea what we should do with the lp report? [09:02] look: https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-toolbar-style [09:02] GtkSettings:gtk-toolbar-style has been deprecated since version 3.10 and should not be used in newly-written code. [09:02] This setting is ignored. [09:03] if something doesn't work in gtk3, just assume it's deprecated ;) [09:03] ah :D [09:03] wanna update and close the report then? [09:04] done [09:05] thanks :) [09:06] guess we should remember this when xfce finally moves to gtk3, that this setting has to be dropped [09:07] yes, we should [09:08] by creating a report? or some roadmap wiki? [09:08] hm, otoh there are so many deprecated things... i guess we'll notice [09:09] i hope we can begin the transition in the winter or something [09:16] chromium in 14.04 really has some issues... [09:17] not the least of which is that it's chromium [09:20] i've never tried chrome tbh [09:20] * elfy neither and I only try chromium for long enough for it to annoy me :) [09:21] ochosi, out surrent logind patches break eric's one [09:21] *current [09:22] ok, i guess then we'll have to investigate that a bit more [09:26] chromium is always behind with updates on ubuntu [09:27] it's also behind on tracking its users, from what i read [09:27] elfy: thing is that firefox+flash has become an extremely unstable combo in 14.04 for me, so i need an alternative sometimes [09:28] yep - I understand that for people [09:31] yeah, chromium/chrome have issues now [09:31] they no longer use gtk [09:31] right, aurora and all [09:32] but that's getting better on its own [09:32] and firefox is working towards better gnome/gtk integration [09:32] yeah, what annoys me a bit is the visual inconsistency [09:32] suddenly chrome/ium's popups disappear with a fade-out [09:33] that makes users wonder why it doesn't happen everywhere [09:37] I just have issues with bookmarks, it's enough to stop me using it :) [13:04] brainwash: btw, have time to look into the xdg-screensaver issue? [13:11] ochosi: no, I don't have access to my old pc with the xubuntu installation, so I don't really test or fix xfce related things right now [13:11] maybe I should not have left that old thing behind :D [13:13] are there any other ways to prevent the screensaver to be triggered? [13:14] nope [13:14] like simulating input events [13:14] not any reliable ones [13:14] we want a general solution, not one we have to implement in every app [13:17] xdg-screensaver is the problem in this case [13:17] there has to be a maintainer for it [13:19] wait, so you're not using xubuntu anymore? [13:21] no, but I did have my (x)ubuntu test machine to mess around with things [13:23] what are you using instead of xfce now? I would think you can install couple desktops, one for normal user and one for a test user [13:24] space is limited, 40gb ssd here [13:24] I use plain X with a basic window manager [13:25] working and developing for xfce means also that I need to install all the ubuntu dev packages and so on [13:26] actually you don't need any of that for debugging xdg-screensaver :) [13:27] i suspect it's just as broken if you don't use light-locker but the built-in screensaver extension [13:27] yeah, neither do you :P [13:27] I think so so [13:27] well, frankly i'm asking you because i'm busy with many other things [13:27] light-locker does not do any magic [13:28] so yeah, it'll take quite some time until i get to that [13:29] we still got some time until 14.10 :) [13:30] saying "i don't want to" would be enough, no need to dance around [13:31] ok, then I don't want to [13:32] yeah, i got that. that was more a note for the future [13:33] :) [13:55] ochosi: bad news, xdg-screensaver works fine here [13:56] it inhibits screensaver + dpms [13:57] i presume you use the same version as is found in ubuntu? [13:57] (with the strange patch) [13:59] yes, downloaded and tested it [14:01] does power-manager monitor these settings? [14:01] the timeouts [14:03] I guess that we should ask the affected users to attach the output of "xset -q" [14:03] while a movie is playing [14:05] https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1309744/comments/11 [14:05] Ubuntu bug 1309744 in xdg-utils (Ubuntu) "Light Locker blanks the screen when playing video" [Undecided,New] [14:06] which patch? [14:14] there is a patch that kinda duplicates the callbacks for when the screensaver extension is used in ubuntu [14:15] i could never make sense of it [14:23] brainwash: actually "xdg-screensaver status" only works for me the first time i run the command [14:23] after that i don't get "enabled" or "disabled" but simply nothing [14:24] mmh, parole does not actually call .. status [14:25] still weird, it works fine here [14:26] but this might be a hint :) [14:28] Works fine here too. [14:30] Unit193: you're using stock xubuntu 14.04 with light-locker? [14:33] No [14:34] well then, errr... :) [14:36] ochosi: did you already check "xset -q" while playing a movie with parole? [14:37] maybe some timout is not set properly [15:31] brainwash: i did, and it doesn't get changed [15:35] ochosi: and after running "xdg-screensaver suspend "? [15:35] some random (valid) window id will do I guess [15:35] use "xprop" [15:39] yeah, still not suspended [15:39] i mean the screensaver time is still 1980 (the value to which i set it) [15:41] ok [15:42] you didn't close the window before checking xset -q, right? [15:43] ofc not [15:43] i guess one would have to add lots and lots of debug statements to the script [15:43] you can add "set -x" [15:44] and then redirect the output [15:44] could power-manager interfere somehow? [15:44] Noskcaj, pong [15:44] and reset the timeout? [15:47] because xdg-screensaver works in non Xubuntu/Xfce [15:49] power-manager only interferes with the presentation mode [15:49] (which i have deactivated) [15:50] otherwise it doesn't touch the blank times [15:58] brainwash: i think i got it [15:58] note: i think :) [15:58] at least it works now [15:59] hah, awesome, it sets the screensaver timeout back to the default value of "600" upon resume, so it obviously doesn't remember the time that was set before [16:00] upon resume [16:00] yeah, after running xdg-screensaver resume windowid [16:01] yea, but suspend is our problem, isn't it? [16:01] both works now [16:01] sounds good [16:02] well, the script not remembering the previously set value actually blows big time if you ask me [16:02] but that's simply a missing feature [16:03] if i wouldn't dislike bash scripts so much, i guess i'd add it [16:04] I hate css a lot more than bash scripts [16:04] dislike is probably a better word [16:05] if you want we can switch [16:05] i'd do a lot of css for not having to do bash :) [16:10] brainwash: when you looked before, did you find an "upstream" for xdg-utils? [16:10] or is it simply maintained on a distro basis? [16:12] I asked here the other day. https://wiki.ubuntu.com/Xubuntu/Roadmap is an almost empty page. [16:12] I don't know what the current focus(es) are. [16:13] ochosi: http://cgit.freedesktop.org/xdg/xdg-utils/ [16:14] and the ubuntu package includes a patch which should be dropped [16:16] so there are some reasons to prepare a new release of xdg-utils [16:23] anyway, it's extremely silly to first detect a DE (in our case "xfce") and then do a "case $DE in" where xfce isn't handled at all [16:23] same goes for lxde [20:00] eric_the_idiot, If your still here, could you try and get the upower fix committed to xfce-session git soon? Also, could you please refresh you patch to work with our patched version of session (our logind patch conflicts with it) [21:12] ochosi: can I add shimmer-themes to the list in bug 1056978? [21:12] bug 1056978 in xfwm4 (Ubuntu) "Resizing windows by grabbing window borders is difficult" [Undecided,Confirmed] https://launchpad.net/bugs/1056978 [21:13] you plan to provide a version of greybird with thicker borders, right? [21:14] knome added that to the roadmap [21:14] currently i don't think i'll have time for greybird-a11y [21:15] mmh, I wanted to implement the invisible border resizing, but sadly no time to do it either [21:16] and upstream does not seem to like the invis border idea, because it needs the compositor -> won't fix [22:20] zequence: Good luck on the 16th, if I don't catch you before then.