[00:37] ochosi: just the one [01:45] ochosi: latest daily packages, brightness icon is white again [07:51] bluesabre: yeah, it's possible that i haven't pushed the brightness icon yet, don't remember right now [10:06] morning everyone :) [10:09] morning [10:09] hey ochosi. I'm back :) [10:10] everything that's good it's bound to have an end :( [10:10] so did my holidays [10:10] sorry to hear [10:10] hope you enjoyed yourself [10:10] from the look of my email I see that I have a lot to catch on [10:11] yes I did. Three weeks of nothing but surfing and biking [10:48] slickymasterWork: sounds awesome [10:49] ochosi: I've just finished 2014-07-29 meeting log and starting the 2014-08-14 one [10:49] do you know if knome has started on pkexec yet? [10:50] not sure, haven't talked to him about it yet [10:50] ok, I'll ping him about it [10:51] I see there's also the new NetworkManager item to be worked on [10:54] slickymasterWork, wb [10:55] ochosi: thing is, the icon was correctly colored, at least for a day [10:55] bluesabre: hm, fun :) [10:55] lemme check [10:56] ochosi: also, trying to add properties to the indicators with the greeter, e.g. ~separator:expand:nohide [10:56] er [10:56] :nodraw [10:56] and :center [10:56] ~spacer has the same issue as the xfce panel, can't really center anything [10:57] hey bluesabre, thanks. It's good to be back [10:57] mm, i see [10:58] bluesabre: tbh i'm not sure why it's not working [10:58] if I can't accomplish that, we'll just make the login panel look like the desktop panel (which, maybe we should do anyway) [10:59] as far as i can see, the icon is there in the correct size in the icontheme [10:59] could you check whether anything changes if you switch to -dark or elementary-xfce? [10:59] (i'm on a desktop here atm, so can't test anything) [10:59] elementary-xfce is correct [11:01] i could actually drop the icon for the brightness plugin from the icon theme, that'd make things a lot easier... [11:02] so how about -dark? (i presume you were using -darker) [11:02] -dark is white [11:02] -darker is white [11:03] argh [11:03] just found the issue i think [11:03] maybe just drop the white ones from 16/22/24 ? [11:03] er [11:03] keep them for those sizes [11:03] still early [11:04] yeah, i could, that'd mean not supporting the brightness plugin anymore [11:04] ok, could you quickly edit elementary-xfce-dark/index.theme [11:05] change "MinSize=24" (or whatever it is) to MinSize=33 [11:05] and then sudo gtk-update-icon-cache [11:05] these panel icons are really tricky [11:08] no good [11:08] i guess you're using -dark now, right? [11:08] cause it could be that the icon-cache doesn't work if you update -dark but use -darker [11:08] you can also set the minsize to 48 [11:09] or drop Min and MaxSize [11:10] updated -dark, switched to -dark [11:10] trying 48 [11:11] hm, that's really the only reasonable explanation i can think of right now [11:12] 48 failed, dropping min and max failed [11:12] I'll let you work it out ;) [11:12] argh [11:13] does the brightness icon have a shadow below it or not? [11:13] i mean the white version [11:13] yes [11:13] ok, then it [11:13] otherwise I'd think there was no icon [11:13] 's the 22px version [11:13] so the min/maxsize approach couldn't have helped anyway [11:16] btw, what are the chances of getting xfpm's 1.4 release into utopic? [11:16] (there won't be too many new features, mostly bugfix i think) [11:17] ochosi: depends when it lands [11:18] but we should be able to if its reasonable soonish [11:26] ok [11:26] well we're targetting debian i think [11:28] so might need a FFe for that [11:29] and i guess it'll help that we already have 1.3.1 [11:50] yeah [11:58] we're waiting for translators and new bugreports atm [12:00] cool [12:01] Heading to work, bbl [12:01] and trying to fix a few remaining issues [12:01] hf === brainwash_ is now known as brainwash [14:21] and roundabout now in #xubuntu is exactly why ditching gksu for a non-working pkexec is a big fail [14:22] yeah well, users who don't know what they're doing at all are not really a super-cool argument for shipping gksu... [14:24] so I give up caring about the end user? - who IS likely to have no idea at all, because some people in *buntu decided it's not a good idea and then nothing replaces it [14:25] that's really not what my argument was about... [14:25] I'd love to see the logs of the discussion from when it was decide to remove it, and how that took into consideration the user [14:26] ok, overstating it a bit so that it's clear: i think a user who doesn't know how to install gksu should probably not use it [14:26] because frankly I can't see how it's better for the end user to go from something that worked to nothing at all [14:27] ochosi: thing is that your argument is also valid for pkexec [14:27] and beforehand they didn't need to do that did they, they could just be told to use gksudo thunar to do a taks [14:28] slickymasterWork: thing is, pkexec doesn't just execute any random command with superuser rights, but specific apps that potentially need superuser rights [14:28] not for us in 14.04 it doesn't ochosi [14:28] we can ship a profile for thunar and pkexec in 14.04.2 [14:29] and now we've got someone telling someone to use sudo thunar instead of sudo -H or something [14:29] no need to be so upset (or if you are, let's channel that into more constructive ways) [14:30] I'm not upset - it just annoys me that the discussion that was had didn't deal with this then I guess [14:30] i think at least within xubuntu we didn't have much of a discussion, or if we did, i don't remember [14:30] and anyways, complain to knome about it. 14.04 is his responsibility ;) [14:30] lol [14:33] was before my time I think - I certainly don't remember anything [14:33] either way, we can either whine about it or try to get a pkexec profile for thunar and e.g. terminal included in 14.10 at least [14:33] or reuse gksu [14:34] i [14:34] i'd prefer to try to make pkexec work first [14:34] i personally don't see that profiles are needed for that many apps [14:35] I'd personally guessed at the 3 I did profiles for here [14:35] though the thunar one's now not working [14:36] nor mousepad - both cannot open display [14:36] well after creating the profiles for the apps we need, step 2 is to bug bluesabre about including the profiles in the packages and upload then [14:36] s/then/them [14:40] yep - well it appears that the ones in the roadmap page are not longer working [14:41] * elfy starts the long winded task of checking out -core again ... [14:41] hm, why are they not working anymore? [14:41] no idea ochosi - I get Cannot Open Display now :| [14:42] for all 3 [14:43] right, but why? [14:44] no idea ochosi - I didn't work out the syntax I just amended it to suit [15:00] ochosi: found something interesting, please take a look at bug 1325675 [15:00] bug 1325675 in xfce4-indicator-plugin (Ubuntu) "Indicator Plugin Area Refuses to Match Xfce Themes & Certain Icons are Cut Off" [Undecided,Confirmed] https://launchpad.net/bugs/1325675 [15:01] not sure about 2., but 1. may be caused by the gtk theme not supporting gtk3, right? [15:02] 2. is known [15:02] ubuntu changed their indicator api shortly before the release [15:02] because they wanted to support hidpi displays [15:02] so the indicator icons (which used to be hardcoded to 22px) come in any size now [15:03] and the plugin doesn't handle this anymore, because it still assumes that the icons are always 22px [15:03] putting that icon in a folder that is defined as fixed size in index.theme in the icon-theme fixes the issue btw [15:03] "fixes" = works around it [15:04] mmh, yeah, you should tell the affected people about this workaround :) [15:04] and yeah, issue 1 is probably what you suggested [15:04] feel free to quote me ;) [15:04] argh :D [15:05] so it's a dupe of bug 1313531 [15:05] bug 1313531 in xfce4-indicator-plugin (Ubuntu) "Huge Wallch icon in Xubuntu 14.04" [Undecided,Confirmed] https://launchpad.net/bugs/1313531 [15:06] yup [15:06] ok [15:08] and yeah, andrzejr gave the explanation there [15:12] ochosi: so they used to work in the old install, but because I use gksu I didn't know they were missing from this one ... once they are there - they all work fine [15:14] elfy: err, so what, the files in the wiki work after all? [15:15] indeed they do [15:15] ok, then let's add an item to development for bluesabre to upload them [15:15] we going to sru this back to 14.04 at some point too? [15:15] yeah, we can, but first step is to get it into 14.10 either wa [15:15] y [15:16] not so sure we need to bother with terminal tbh - sudo -i or any number of other options for that [15:17] right, so only thunar and..? [15:17] mousepad is the only other one [15:18] right, makes sense [15:18] so those two bluesabre should have access to [15:18] or even Noskcaj [15:18] the files are all on the roadmap for it [15:19] added to trello and features blueprint [15:19] cool, thanks [15:19] those files might need tidying up - not sure, but they all work [15:20] could you report a bug against mousepad and one against thunar adding those files? [15:20] okey doke [15:20] ideally link them to the features blueprint [15:20] then things should go ahead smoothly [15:20] yep [15:22] ochosi: launchpad only - or bugzilla? [15:22] for now launchpad is fine, although mousepad is more active than thunar, so you could give that a try [15:31] ochosi: ok - both done on LP, mpad on bugzilla and linked, both added to blueprint [15:31] sweet, thanks a lot elfy [15:34] s'ok :) [15:51] Hi. I have a few questions regarding the AppIndicator on xubuntu. I am trying to write an indicator applet (using python), and documentation is sparse, to say the least. The few source samples I found, I was expecting to see an indicator showing up, but no dice. Will the best way to take a look into an existing indicator (I found indicator-weather who seems to be a single 3kLoC python program) and reverse engineer the API? [15:59] isnt the indicator bar just a gtk widget? [16:01] lullis: statusicon? [16:06] lullis: yeah, i think the docs are scarce. i guess people who have written indicators have used other indicators as examples [16:06] also, not that the api changes a lot [16:07] if you wanna do something just for the xfce panel, a plugin would be better, and it's actually not that hard to do (and there's a sample plugin) [16:21] bug 1293287 should be fixed in utopic, but what about trusty? could or should it be fixed via backports at some point? [16:21] bug 1293287 in xfdesktop4 (Ubuntu) "xubuntu 14.04 'xfdesktop --reload' no longer cycles wallpaper image" [Undecided,Confirmed] https://launchpad.net/bugs/1293287 [16:21] by backporting the new dev release 4.11.7 [16:22] ochosi, it will have to be an indicator. Basically I have an application that deals with authentication through sd cards, and I need to put this indicator on both the desktop panel and on the login greeter. [16:23] lullis: i see. then i guess you have no choice but to look at existing examples. you might also want to ask around in #ubuntu-desktop [16:24] Ok, thanks. [17:28] Unit193: https://sigma.unit193.net/~unit193/core.html so Install gets you the tasksel, command-line doesn't - but currently BOTH still require the apt-get install command, - core is missing from selection [17:28] ochosi bluesabre ^^ [17:31] ochosi: so what's the plan with this and utopic - or are we going to revisit it in valiant vampire ? [17:58] elfy: i'm waiting for Unit193's feedback on this. have no idea what it would take to fix that so it's hard to judge for me whether we can fix it in time for 14.10 [18:00] ok - well I'm just drafting testcase(s) [18:08] Unit193: if you could have a look http://pad.ubuntu.com/xubuntu-core thanks [18:33] ochosi, elfy: Right, both require you to install xubuntu-core^ right now because tasksel hasn't been updated, I've pinged the person a couple times, but he's been on vacation I believe so that won't help much. [18:34] Unit193: who's "the person"? [18:34] okey doke - thought it was something like that [18:34] so i guess we can get that fixed after FF, right? (i mean tasksel being updated) [18:38] ochosi: cjwatson. [18:38] ahh [20:50] slickyma1ter, haven't, i've been busy with stuff, like laying around the summer cottage ;) [21:18] shouldn't xubuntu-default-settings provide the pkexec policy files for thunar and co? === halfie_ is now known as halfie [21:20] wouldn't it be better if they were shipped with the application packages itself? that way *anybody* using thunar could get that policy... [21:20] i mean of course it's a fair fallback *for now* to ship them in the default settings package [21:21] so it has be included upstream? [21:21] has to be [21:23] bug 1358361 [21:23] bug 1358361 in thunar (Ubuntu) "Thunar needs a pkexec policy" [Undecided,New] https://launchpad.net/bugs/1358361 [21:23] is targeting ubuntu [21:24] well, i'd imagine getting it included in upstream *xfce* would be the most ideal situation, but that's unlikely to happen/propagate for 14.10 at least [21:25] i was referring to the thunar package in ubuntu [21:25] right, kinda late [21:26] late and practically we'd have to get 1) policy added in the repository 2) release for all appropriate packages 3) aforementioned landed in debian and 4) synced to ubuntu [21:26] but still, xubuntu users will expect pkexec to work like gksu for every app, won't they? [21:26] so that might be a stretch even vrt. 15.04.. [21:26] of course they will. [21:26] oce it works for thunar, mosuepad and ... [21:26] once [21:27] that's why it's a fair fallbac *for now* to go the default settings route [21:27] and sure, they'll expect it to work in non-default apps too [21:27] that's one of the reasons why i prefer pkexec over gksu, it doesn't *just work* for any app that might not even need it [21:27] when it doesn't - well, then they'll have to file a bug and wait for the change to land to the package [21:27] hey ochosi ;) [21:27] people who know what they're doing can be trusted to install gksu [21:27] sudo xfdesktop4 :D [21:28] ochosi, and when you say that, everybody becomes one who can be trusted ;) [21:28] well i don't care what users do to their systems willingly [21:28] people just fall back to sudo [21:28] but i prefer to ship sane defaults [21:28] sudo works every time and breaks everything :) [21:28] brainwash, that's their pick, and they live with the consequences [21:30] and spam the forums and chats with questions about their broken user accounts :/ [21:30] aren't they doing that with PPA's already? [21:30] actually we asked via the mailinglist for users to submit apps they need to use with superuser rights [21:30] not the huge turnout [21:30] i mean, sure, it's stupid, but there are *already* a dozen ways to break your installation [21:31] So we should add more, cool. [21:32] how are we adding more? [21:33] i thought we were introducing something that was less prone to break stuff. [21:36] just noticed that the daily iso only ships firefox-locale-en [21:36] did something change? [21:37] should we be worried? :) [21:55] wow, here's one for all the folks who complain about light-locker: https://bugs.launchpad.net/bugs/1358504 [21:55] Launchpad bug 1358504 in unity (Ubuntu) "Screensaver leaks password key-presses through to applications" [Undecided,New] [21:55] great.. [21:56] well, nobody said writing a secure lockscreen from scratch was easy (which is why we didn't with light-locker) :p