[00:00] dinner time, back in a bit [00:00] Default didn't do this? [00:01] Oh, well yeah xfsettingsd never paints it for me. [00:03] I think it used to be just one, functional one [00:03] now its just one dead one [00:03] wait, xfsettingsd sets the root pixmap? [00:04] bbiab [00:04] ochosi: I don't see why it would. But it isn't now. [00:04] bluesabre: Ah, so I did fix that, now it's one dead, one functional. [00:04] Well, "fix". [00:05] * Unit193 wonders if he's off the hook now. [00:15] :) [00:16] so I'd be generally in favor or swapping it out instead of trying to figure out why it dies, unless you have any ideas? [00:17] ehm, what sets the theme then if we "swap out" xfsettingsd? [00:17] not sure why it's defunct and all, but it's clearly doing its job if we see greybird and not the gtk3 default theme in ubiquity, no? [00:18] and i'm still not convinced that xfsettingsd has anything to do with setting the wallpaper [00:18] ^ [00:18] iirc ubiquity used to cairo-paint it built-in [00:18] I think those may be controlled by ubiquity [00:18] (but i might be misremembering that part) [00:18] hm right [00:18] i guess we have us some ubiquity code to read then :) [00:19] * Unit193 calls not it. [00:19] * bluesabre already did [00:19] actually [00:19] ubiquity doesn't paint the desktop for us [00:19] if it would set the theme, wouldn't i grep "Greybird" in it? [00:20] its in xubuntu-live-settings iirc [00:20] ah [00:20] k [00:20] sets some gsettings variables, and ubiquity grabs those [00:20] guess i should shut up until i've read the code too :) [00:20] :) [00:21] yeah, i thought that adding the gsettings var for the bg was enough and ubiquity would paint it [00:21] that was probably a fake memory though [00:22] start here https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L366 [00:23] http://paste.openstack.org/show/LInGit7mfbk7EE8L831y/ is what I use. :P [00:24] Yeah, you can check for background_image, I've already looked through this. :P [00:26] * ochosi is busy looking for why and when the panel was disabled for xfwm4 [00:28] my previous fix, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1375893/comments/4 now lines 404-407 [00:28] Launchpad bug 1375893 in xfdesktop4 (Ubuntu) "Black background to Try/Install Dialogue" [Medium,Confirmed] [00:29] let's get that pushed then i guess, unless you wanna figure out why xfsettingsd is defunct [00:29] btw, that bug should really be re-assigned to !xfdesktop (although i'm not sure what to) [00:29] http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/5770 [00:31] bzr blame wont tell me the real one. :P [00:32] http://paste.openstack.org/show/FMJNzU5OLBcPzj9F3BZx see? [00:32] darn it blame [00:33] yeah [00:33] i know that already [00:33] i'm still browsing the bzr history [00:33] I wouldn't. :D [00:33] no need for >1 of us to waste his time on this [00:34] ochosi: 4185 [00:34] right [00:34] so it was superm1 who disabled it [00:35] ochosi: I'm faster? :D [00:35] you are, but i hate bzr *more* [00:35] ochosi: Are you sure? I've converted a whole repo just to add a couple commits. [00:35] so since superm1 said today that he was fine with re-enabling the panel as long as it works, we can go for it now [00:36] Yep. [00:36] as soon as that is re-enabled, i can add a custom background for us for the panel [00:36] the default one stinks [00:36] brb, running out of battery... [00:36] Talk to xnox? [00:36] k [00:36] And sure, I can request the merge when I get back home, no problem. === GridCube is now known as GrinchCube [00:40] Unit193, cool [00:40] bluesabre: Anything else I'm not remembering? [00:42] dunno... I think I might create a dev trello since I keep forgetting mini-tasks [00:43] * bluesabre reviews blueprints [00:44] [xubuntu-dev] Evaluate the 14.10 decisions relative to default IRC client and decide action(s) for 15.04 release: TODO [00:44] I'm rather content to say we are fine without [00:44] but haven't heard much else [00:48] yeah [00:49] i'd tend to agree [00:49] i mean we can always do a survey, but the question always remains how representative that'll be [00:49] i'd say as long as googling "xubuntu xchat" doesn't turn up lots of heated comments, we're probably fine [00:51] I can toss it onto the agenda for tomorrow if you want to cover it [00:51] i briefly investigated whether there is quantitative data of the ppl who connect to #xubuntu in terms of which client they use, but freenode doesn't collect that data anymore and didn't hold on to data collected on that previously [00:51] yeah, we can formally cover it tomorrow [00:52] if you add a dev-trello, please link it to the blueprint [00:52] i actually wanted to go through the blueprints with you and everyone else at some point [00:52] since you won't be at the meeting, we can quickly browse through devel now if you want [00:52] If it was me, I wouldn't bother with a script or a poll, if no one comes here (irc) or the ML to complain I would keep the status quo :) [00:53] drc: well, i'd have used the data if it had been readily available. i'm also not really convinced of polls [00:53] not only because of being representative, but also in terms of the expectations it creates in participants [00:53] yup [00:54] That's what I was getting at...more work than knowledge. [00:54] did you get anywhere with panel-switch btw? [00:54] ochosi, Unit193, let's discuss now if you're around for a bit :) [00:54] ochosi: not yet [00:54] we can also postpone that if it turns out we have enough work for 15.04 [00:54] not sure how much work it'd be [00:54] its just a matter of finding time lately [00:54] there's little enough to do [00:54] haha, as always ;) [00:54] that's the same for everyone [00:55] bluesabre: I'm not sure, but logind-handle-lid-switch was set to "false" in trusty-updates and it's still set to "false" in utopic/vivid with the new xfpm 1.4 release [00:55] right, but I think the logic was flipped and wrong... its a confusing mess [00:55] bluesabre: did "investigate reduction of gnome depends" have any concrete roadmap? [00:55] wrong + wrong = right? [00:55] :D [00:55] yeah, sadly +1 on that [00:55] wrong + wrong = NaN [00:56] is basically where we're at there ;) [00:56] ochosi: it was more or less, if we have any ideas there, we go for it [00:56] ok [00:56] so i'll flip that to "inprogress" then [00:56] since it's sorta ongoing always [00:57] same with "shared components"? [00:57] or did you have something specific in mind [00:57] there were some suggestions for not-so-good alternatives [00:57] as in? [00:57] they were just posted here, replacing games and the calc [00:57] oh right [00:58] the safest thing would probably be transitioning to more mate components to reduce the headache of gnome upgrades [00:58] probably [00:58] although calc is actually still fine [00:58] yes [00:58] just looked at it in vivid [00:58] the calc is generally A-OK [00:58] but yeah, we'll have to wait until gtk3.14 hits us to be really sure... [00:59] whenever that finally lands... I feel like its taking longer than it really is :) [00:59] there were discussions about calc maybe because of the CSDs [01:00] but xfwm4 just received patches by ofourdan(!) to support that better [01:00] I don't mind the CSDs, they work well enough in xfce, and look better than hacking a toolbar back in [01:00] yeah, absolutely [01:00] while not being 100% consistent, it could be worse [01:01] what about the lgg-settings to debian thingy being blocked? [01:01] its gotten better, I think gnome devs finally decided what they wanted to do with them, and the results are improved [01:01] lgg-settings being blocked is a matter of updating, then potentially uploading to debian (in-freeze), or just to ubuntu [01:02] oh right [01:02] actually there are so many pending merges by andrew, i've completely lost track of the greeter lately... [01:02] we should aid to review the lightdm-gtk-greeter merges, merge them in, do a dev release, and pushing that on to get tested [01:02] aid? [01:02] plan... [01:02] words failing [01:02] heh [01:02] i guess i was also too involved with other things to be able to focus on the greeter at all [01:03] now i feel i don't know the codebase well enough anymore, because so much has changed [01:03] yeah [01:03] is andrew still actively developing? [01:03] yeah [01:03] yup [01:03] andrew kicks butt and keeps adding things... he toned it down a bit since we asked for stability [01:04] so he'll fix bug 1398619 some day [01:04] bug 1398619 in lightdm-gtk-greeter (Ubuntu) "No indicators displayed when systemd-sysv is installed" [Undecided,Confirmed] https://launchpad.net/bugs/1398619 [01:04] I can fix that soon [01:04] please do! :) [01:04] maybe one day this weekend, and include it in the next release [01:04] sometimes i wish he would also work on other things, i guess i'm sorta done with what i wanted to achieve with the greeter... [01:04] ochosi, maybe you can ask him to do so? :) [01:05] knome: yeah, maybe maybe, there are so many things one could do with enough time. frankly i feel i'm juggling enough as it is ;) [01:05] asking doesn't cost a lot of your time :) [01:05] well no, but if i ask him, that will likely not be the end of it [01:05] it is usually the beginning of a conversation [01:06] either he has that idea himself, or he might need coaching/motivation [01:08] :) [01:11] ochosi: anything else of interest? [01:11] what's the bluez5 workitem about? [01:11] new bluez coming soon (maybe with gtk 3.14?) [01:11] (sorry, distracted chatting to superm1 about mythbuntu and ubiquity...) [01:11] or with systemd [01:11] or something [01:11] oh, is it? [01:11] something, somewhere [01:12] these things are taking their time to land (again) [01:12] Noskcaj knows more in that area [01:12] its because debian is in freeze [01:12] is there any experimental PPA we could use to test bluez5? [01:12] just to prep ourselves a bit [01:12] Noskcaj or tim? has one somewhere [01:13] that workitem is a bit fuzzy, that was mainly why i asked [01:13] and actually testing from a PPA would've been what i'd have expected [01:13] if a PPA is there already, all we need is a call for testing after some exploratory testing we do ourselves [01:13] it might have other dependencies, I just don't know enough there [01:14] k, we can also assign it to Noskcaj btw [01:14] good idea [01:14] lets do that [01:14] if everything is just "xubuntu-dev" then everybody will think you have to do all that by yourself [01:14] and you will think everyone will help [01:15] and nothing will get done :) [01:15] so i'd encourage you to assign those things you wanna do personally to yourself [01:15] ++ [01:15] makes sense [01:15] then it'll be clearer for others (like me) where you want assistance [01:17] btw, slightly different topic, but still xub and devel related [01:17] i talked to cavalier about your gsettings branch in order to get it merged in finally [01:18] right [01:18] he promised to look at it on the weekend [01:18] looking forward to having something this weekend :) [01:18] guess we'll have to remind him :) [01:18] but yeah, everything worked with it [01:19] so to the worst i'll just merge it personally [01:19] sounds good [01:19] then we can get that into 15.04 and consider what to do with the settings app [01:20] we could e.g. do a downstream patch for xfpm and add a new "locking" tab to it (or even "light-locker") and make it configurable there [01:21] yeah [01:21] since switching to gsettings means we'll get rid of much of the code lls currently holds [01:21] sounds like a good idea [01:22] then probably just move the "lock on suspend" option over to that tab too in our downstream patch [01:22] and make it a "security" tab [01:22] shouldn't be too hard actually [01:23] but yeah, first we need ll 1.5.1 [01:23] yeah, let's get that, then we can have fun [01:24] okeydokey, i'll try to push that then [01:25] hm, i would imagine gtkplug would work with gtk2/3 btw [01:26] it says you can even use it with QT [01:27] might break with later versions of gtk + mir/wayland [01:27] and also, might not [01:27] seems it's still fine with gtk3 stable [01:28] but yeah, might or might not [01:28] it doesn't seem too hard though to make it pluggable [01:28] cool, let's start adding things to our various roadmaps then [01:28] (apart from the examples i know being c and the apps in question being python) [01:28] http://wiki.smdavis.us/doku.php?id=development [01:28] :) [01:30] ok [01:31] lls might be a good place to start with vala conversions [01:31] since it is so tiny [01:31] vala conversions? [01:32] if we want to start doing vala development at all... I've considered it for a few things [01:32] well only if we don't dissolve it into a tab in xfpm [01:32] since its lighter than python [01:32] yeah, it used to be under heavy development when i looked at it last [01:32] but i guess it has consolidated meanwhile [01:33] yeah, its doing better now, and has better gtk bindings that python-gobject (sadly) [01:33] ok, added those few thoughts to the dev roadmaps [01:33] thanks [01:34] I think I'll try reviewing some greeter merges tonight so I can say I was productive :) [01:34] cool [01:34] * ochosi already pushed a patch to xfwm4, so he's safe [01:34] :D [01:35] also found the source of the bug elfy reported against intelligent hiding [01:35] although the fix will likely be ugly [01:35] anyway, gotta hit the sack [01:35] ochosi, that'll hurt [01:35] * knome hides [01:36] oh yeah [01:36] bluesabre: oh, and that bluetooth-indicator thingy, python-libindicator or whatever it was... adding that to the seed would be cool [01:36] ochosi, quick note about intelligent hiding [01:36] when used with window plugin, its kind of annoying that it hides when clicking on a different window button [01:36] it only hides if the newly focused window overlaps [01:36] I think it should stay elevated as long as the mouse is still there [01:37] if thats possible [01:37] and it's only feeling annoying cause it's hiding too quickly imo [01:37] only a minor annoyance though [01:37] it should slide away more slowly [01:37] yeah [01:37] sliding is more difficult with gtk2 :( [01:37] the whole logic is quite complex already, so i'm not sure about your suggestion [01:38] yeah, np [01:38] might take a lot of time to figure that out without breaking something else [01:38] bluesabre: What are we going to talk about? And dev trello doesn't sound too bad. I'm not actually using blueprints at all as it is, so couldn't be worse than that. [01:38] the slow sliding should be there already [01:38] maybe we can finish the gtk3 port eventually [01:38] just have to activate it [01:38] or: find a good way to activate it [01:38] :) [01:38] Also glanced over something that said gtk 3.14. Seen it in Debian, it's kind of crap. [01:39] more things broken probably [01:39] bluesabre: well, new features were added, so the gtk3 port is out of date. so better do 4.12 before really working on gtk3 [01:39] particularly for parole if not using clutter [01:39] meh, that sucks [01:39] yeah, 4.12 is priority [01:39] clutter really eats more cpu [01:39] anyway, i'll doze off [01:40] nighty! [01:40] less than X, more than VX [01:40] *XV [01:40] seeya [02:22] * Unit193 petpets bluesabre. [02:22] :) [02:23] this one seems desirable, https://code.launchpad.net/~kalgasnik/lightdm-gtk-greeter/allow-debugging-option/+merge/243139 [02:25] That it does. Did he do the config one? ;) [02:25] So, did you need me for something? (re: pinging.) [02:25] nah [02:25] go on and have fun [02:26] Was thinking of taking a walk, 25F/13/F out. [02:26] Just have to finish tea. So yes, do ping/add me to the devel trello if you make one. Thought about creating a wiki page with what I'm doing and what progress I have with it. [02:27] sure, that sounds good [02:27] wondering how I should lay out the dev trello... per project, per dev, priority bugs, etc [02:30] i would probably do that per project, most useful for tracking process [02:30] sleeps -> [02:33] yeah [02:33] later knome [08:38] morning all [08:47] morning elfy [08:48] hi ochosi [08:49] so i'm already one step further on the bug you reported yesterday [08:49] yea, read that :) [08:49] don't have a fix yet, but it probably will be a tiny bit ugly (if it's even fixable) [08:50] I was thinking about that - but then came up against panel at the top :p [08:50] logically speaking (for my workflow at least) with panel at bottom and a window rolled up [08:50] generally speaking, i'd have to find a way to know what size the window-decorations have [08:51] I have decided that window is in the way and thus panel wouldn't be - so regardless of what window size is, when window rolled up - panel should show [08:51] and looking at it that way - you don't need to know window size - just rolled up state [08:53] but then I thought of panel at top - and rolled up the title bar is over the panel, if you then unhide the panel you can't see title bar to unroll it ;) [08:54] though alt-tab to a window that's rolled up does maximise it again [09:07] yup [09:07] that's the problem [09:08] i still have to check the size of rolled up windows cause they might still overlap [09:08] same with panels on the sides btw, not just on top [09:09] mmm [09:10] not sure why you need to know size - just the rolled up state - or is there not something which says "this_is_rolled_up" [09:10] anyway - all beyond my pay grade :D [09:11] how would i check whether the panel and the rolled up window overlap without knowing the size? [09:11] i'm basically intersecting rectangles [09:13] man, corner-tiling is really really useful, i can see that already after using it for 5mins [09:13] well if x is maximised - and panel is not floating about in the middle - aren't they always going to overlap - if they didn't then the panel wouldn't actually be hidden [09:13] yeah, but rolled-up != maximized [09:14] no of course not [09:14] just think of a rolled-up window as a very small one, but if you ask it how big it is, it'll still tell you its rolled-down size [09:15] yes I understand that :) [09:15] but if window IS maximised AND rolled up then panel should show surely? [09:16] anyway - I think we're in danger of confusing each other here :p [09:16] if it's maximized and rolled up it can still overlap with the panel or not overlap with the panel [09:17] so yeah, currently they always overlap because we don't know the size of the rolled-up window, but instead only the size of the maximized window [09:17] (in case that's what you were hinting at) [09:17] mmm [09:17] sort of :) [09:19] mkay :) [09:21] what I'm logically alluding to is that if you did have a max'd window which is now rolled up - irrespective of size - you've moved it out of the way and the panel should unhide [09:22] because user isn't thinking about what the code thinks is the size - but what they actually see [09:23] yeah, i agree [09:23] then again, the panel might still get in the way in some cases (as you pointed out yourself, especially with panel at the top) [09:23] so it's still worth to check [09:23] yep [09:23] but yeah, in 90% of all cases, the panel will go away anyway [09:24] currently i'm considering to delay to hide the panel [09:26] not sure how that would resolve it [09:26] no, that's a different point [09:27] ok :) [09:27] i think sometimes it's a bit unpractical that it goes away immediately [09:28] showing immediately is good i think, but hiding could be slightly delayed [09:28] so that there's no "i wanted to click a button in the panel twice" and it hides meanwhile so the second click reaches "something else below" [09:30] good point [09:31] but - you'd have to be quick moving the mouse after you clicked - as panel stays while mouse is over it [09:31] not if you click a window button of a window that is maximized i think [09:31] then it might go away quite quickly atm [09:32] I'll look at that a bit later - panel at bottom here :p [09:32] just about to wander off to work [09:32] sure, hf [09:32] I'd love to - but it won't happen :p [09:33] :] [09:33] make the best of it then [09:33] heh [09:34] really should call this shaded instead of rolled up I suspect :D [09:34] yeah [09:34] would make things a tad clearer [09:34] :) [09:50] Unit193: still awake? [10:29] Noskcaj: about bluez5, could you give me/us an update on what's coming and whether there is a PPA or something to test things in advance? [10:33] ah ok, i've found it already... [10:42] ochosi: "There no some icons in system tray" -> python-libindicator not installed? [10:42] you mentioned this package here some time ago [10:43] and dropbox is a python app (last time I checked) [10:47] oh, the reporter already solved the problem.. [10:59] ochosi: corner-tiling? [10:59] how? :D [10:59] will fix the python-libindicator item tonight [11:04] bluesabre: drag window to corner and get 25% window size [11:04] there's already a branch with it [11:04] ah, thought you might have already punted it to trunk [11:05] nope, needs more testing [11:05] also, currently it also implements a maximize-on-move-to-top option that i'm not sure i wanna push [11:05] fwiw, bluez5 seems to work okay with my bluetooth keyboard [11:05] * bluesabre prefers that over 50% at top [11:05] no improvements/downsides [11:06] bluesabre: yeah, but then tile-to-bottom also doesn't work anymore [11:06] and that can be useful [11:06] especially with corner tiling [11:06] true [11:07] so how about 25%/50% all around? [11:07] yeah, that's what it can do currently [11:07] i mean, i guess i know what you mean :) [11:07] yeah, gotcha [11:07] you can either do 25% (via corners) or 50% (via sides) [11:08] or do 25 + 25 on the left and 50% on the right [11:08] which is pretty cool [11:08] it would also be cool to be able to bind the corner tiling to keyboard shortcuts [11:08] yeah, that should be possible [11:08] with maximize, i'm thinking while people might be used to it, there are still soooo many other ways to maximize windows... [11:08] (double-click the titlebar, click the maximize button, kb-shortcut) [11:10] agreed [11:15] alrighty, time for work... bbl [11:25] knome: humm, i guess the XSD needs an amendment where it says that members of "xubuntu developers" have upload rights [11:26] that's not true anymore [11:26] and being admitted to that team also has become more as in other teams i'd say [11:27] hm? [11:27] has become more? [11:27] well the process used to involve the ubuntu development board [11:27] oh, right [11:27] yeah [11:27] but it doesn't anymore, becoming a member of xubuntu-dev is mostly being approved by team lead [11:27] and (maybe) xpl [11:27] * bluesabre concurs [11:27] gives you push-rights, but no upload rights [11:28] ~xubuntu-uploaders is the new upload team [11:28] if you want, i can help with drafting the text, but since it's mostly still a process description, it should go through without a hitch, so just notice the list that this is going to happen [11:28] i'm wondering whether we should just remove that paragraph [11:28] yeah, or that [11:28] since there are no fundamental differences with becoming a member of any other team [11:28] or sub-team [11:29] * knome looks at the actual text now [11:29] yes, i remember i never really liked that one, but served a function back then [11:30] we could also redraft a paragraph on how to become a sub-team member, but then again, most of our sub-teams are one-man/woman shows, so i don't really see the need... [11:30] redraft? [11:30] what's wrong with the current one? [11:30] as long as we're less than 20 people i guess we can manage without [11:30] i mean, isn't that pretty much accurate? [11:30]