=== maclin__ is now known as maclin === m_conley_away is now known as m_conley [06:03] Good morning === maclin_ is now known as maclin [07:35] Hello, world!\n [07:46] seb128, hey! [07:47] good morning desktopers [07:47] * seb128 thinks it's monday morning and when IRC start blinking in the minute you run it, that can't be good [07:47] hey darkxst [07:48] * darkxst just got internet again! sorry :) [07:48] no worry ;-) [07:49] cyphermox, ping [07:50] seb128, so what will happen with the gnome-desktop transition for U? [07:50] cking, it's like 3am on a sunday night for him, you might want to let some context for later [07:51] darkxst, dunno, we didn't discuss U and what we do with GNOME components yet [07:51] i'll pop him an email [07:51] seb128: I know its monday morning when I feel extraordinary sleepy ;) [07:51] we said we would discuss it tomorrow at the meeting [07:51] mvo, good morning ;-) [07:51] seb128: and GOOD MORNING (in best jdub voice) [07:51] seb128, when is the meeting? [07:51] mvo, you forgot the freedom lover part! [07:51] darkxst, weekly meeting, 15:30utc [07:52] seb128: haha, very true [07:52] but it's the weekly team roundtable, I expect us to discuss a bit what we do but we are probably going to continue discussions on lists after that [07:53] seb128, right thats pretty impossible for me to attend.. [07:53] but I am sure you know by now, how much we are blocked by the old gnome-desktop! [07:56] then there are the CSD issues as well I guess === m_conley is now known as m_conley_away [07:57] we know about gnome-desktop [07:57] we can probably go ahead with that transition in U [07:57] but I think we are going to clean out some bugs through SRUs first and do Debian merges [07:58] e.g usual start of the cycle tiding up work [07:58] before starting with new transitions/changes [07:58] * darkxst notices cogl transition has already started ;) [07:58] what are the issue with CSD (out of the fact that they don't work out of gnome-shell, which is an issue but one for everybody but you) [07:59] yeah, we autosynced with Debian [07:59] which is sort of my point [07:59] seb128, exactly that, most 3.12 apps are using CSD's now [07:59] we already have transitions started through the Debian syncing [07:59] part of it can be solved by making Unity ignore the WM hints [07:59] so we need to clear those out before adding new ones [07:59] the issue is not specific to Unity [08:00] try running one of those under xfce [08:01] then xfce should ignore the hints as well I Guess, either way upstream won't take patches to disable via themeing in GTK [08:03] CSD or "let's make things incompatible with everything existing and give the finger to everyone telling them to go change their code" :/ [08:04] seb128, that said I did semi-play with this and have some half-baked patches, if you really want to disable CSD's from gtk and carry as distro patches [08:04] hallo [08:04] Laney, hey, how are you? [08:05] hey Laney [08:05] darkxst, we didn't define what to do yet, but yeah we are going to need to decide on something [08:05] I think we are going to end up patching the default apps to not use CSD at least under Unity [08:05] same we patched them to have menus [08:05] that's the only way to have them not regress in user experience [08:06] seb128, not sure how you guys can criticise gnome for going off in there own direction, which is exactly what you guys are doing! just a slightly different direction [08:06] seb128, you can't patch the apps, you either need to patch GTK or WM [08:07] darkxst, we can patch the apps to not use a gtkheaderbar [08:07] Everything is using GTKHeaderBar now [08:08] you would be better off patching GTKHeaderBar to not display window controls [08:08] darkxst, I don't criticise GNOME for going their own direction, I criticize app writers to not think about their users on non gnome-shell desktops [08:08] darkxst, in their defence they were used to have GTK working on any desktop without effort [08:08] which is not true anymore, and most app writer didn't notice [08:09] GNOME is a desktop! and only the official GNOME apps are using CSD's? [08:10] official ? [08:10] like gthumb [08:10] or d-feet ? [08:10] I'm also unsure that e.g file-roller is "an official GNOME app" [08:10] it's a standalone app and it probably has as many users out of GNOME desktop that it has there [08:11] it's just that GNOME like to call everything hosted on their git as "part of GNOME" [08:11] same for gnome-calculator [08:11] that was gcalctool and a standalone app, long before there was a notion of GNOME apps [08:11] those are just GTK apps that happen to have been historically hosted on the GNOME infrastructure [08:13] seb128, I suppose GTK could be redifined GNOME toolkit now and then everything makes sense! [08:13] right [08:14] what is let to know if app writers are still wanting to use it then [08:14] because most have users out of GNOME [08:14] QT is just as alien! [08:15] you can resize and move qt apps on any desktop though ;-) [08:16] +1 [08:16] seb128, you can disable lack of titlebar on any desktop by ignoring the WM hint in the window manager [08:16] (while gtk might in fact be the gnome toolkit, xfce still uses it) [08:17] ochosi, gtk was once GIMP toolkit [08:17] darkxst, "you" is not the apps writers nor the users in that case [08:17] darkxst: i know, are you making a point? [08:18] seb128, what does it have to do with the app writers? [08:18] well, the situation currently is that app writers using gtkheaderbars end up having a buggy experience for their users on a variety of desktops [08:18] sure you can claim that those desktop could patch that wm [08:19] seb128: hi! how are you today? [08:19] but reality is that there are plenty of desktop which behave buggy currently with new gtk widgets [08:19] desrt, hey, very good ;-) how are you? had a good w.e ? [08:19] seb128: yup. weather in berlin is very nice :) [08:19] great [08:19] we had a whiskey tasting last night :) [08:19] they forecast rain for weeks here, still didn't get it [08:20] lol [08:20] *ears prick up* [08:20] don't complain :p [08:20] was that a dholbach plan? ;-) [08:20] hi seb128, desrt [08:20] no. kat, dave, claudia and claudia's husband(?) [08:20] k [08:20] chrisccoulson, hey, how are you? [08:20] larsu was supposed to join but he bailed at the last minute. boo. [08:20] chrisccoulson, do you highlight on whiskey? ;-) [08:21] seb128, not bad thanks. and you? [08:21] good thanks! [08:21] hah, not quite. i'd just sat down when I noticed it ;) [08:21] ;-) [08:21] oh I didn't reply [08:21] weekend was playing mgs and climbing = good ;-) [08:21] ;-) === davidcalle_ is now known as davidcalle [08:22] seb128, point being, window decorations can be re-enabled by ignoring the XWM hints, everything else can be controlled via themes and/or xsettings [08:23] (in 3.12) [08:23] darkxst, is "ignoring the XWM hints" correct or a workaround hack? [08:23] i.e. you can make the CSD's display, minimise, maximise and close [08:24] or nothing [08:24] seb128, correct, not just a hack, that is how upstream expect things to work [08:24] "ignoring" doesn't seem proper behaviour [08:24] if there is an hint it's probably for a reason and not to be ignored? [08:25] seb128, its a "hint" not a "demand" [08:25] well, if somebody bothered adding hint that's probably for a reason [08:25] seb128, right, but that is for GNOME reasons [08:26] darkxst: did you also have a good weekend? :) [08:26] * seb128 has the feeling desrt is trying to stop that discussion [08:26] seb128: too early on monday morning for pointless trolls [08:26] desrt, it's not really a troll, we need to figure out what we do with CSD this cycle [08:26] it seems this conversations tends to go around in circles... [08:27] though it drifted to "who is to blame" which is probably not useful [08:27] seb128: there is a very simple solution to this problem: add frame extents to compiz [08:27] larsu, shrug [08:27] it's not about compiz [08:27] xfce has the same issue [08:27] wmaker has the same issue [08:27] ...and back to 'who to blame' :) [08:27] and I can go on if you want [08:28] desrt, I had a good 10 day climbing trip :) [08:28] ^Laney :) [08:29] seb128, from my discussion upstream, "hints" are more like recommends in apt [08:29] larsu, also I'm not sure that even if compiz was to have proper decoration/border for those we wouldn't have an UI "regression" for Unity users in consistency/behaviour [08:29] darkxst, right, and the reply to "packages have buggy recommends" is not "make apt ignore recommends" [08:31] "_GTK_FRAME_EXTENTS" [08:31] looks like a pretty universally-supported and well-specified hint [08:31] i mean... why hasn't everyone else done this already? [08:31] seb128: fair enough - this is a gtk extension and gtk ought to have a better fallback if it doesn't exist [08:31] desrt <- sarcastic [08:31] larsu <- benefit of being in the same room [08:32] I didn't figure it out until I asked - it is even harder for people on irc [08:33] seb128, hmm, this is not buggy, its intentional [08:33] seb128, If some WM wants window decorations, it should ignore the hints [08:33] darkxst, so an hint was invented/added in the goal of making wms ignore it? [08:34] well the default behaviour should be to have decoration [08:34] which hint? turning off window decorations? what about if I change chrome to not use the system titlebar? [08:34] so the code works everywhere [08:34] i don't think you can just ignore the hints [08:34] now if gnome-shell is to do something new and specific, they can have an hint to opt in for that [08:35] that would be the logical way to do things imho [08:35] so gtk only checks whether the screen is composited and has rgba visuals to decide whether to enable csd [08:35] seb128, maybe, but 3.12 is well past freeze now, so good luck changing anything there! [08:35] is there a way for the wm to advertise the things it supports? [08:35] we could make gtk check that... [08:36] Trevinho: ^ [08:36] _GTK_FRAME_EXTENTS is in _NET_SUPPORTED under metacity [08:36] gtk should just check this.... [08:37] larsu, I played with this ages ago, let me dig up my patches [08:37] s/metacity/mutter/ [08:37] it is not in compiz (obviously=) [08:38] this is mega-easy [08:38] gdk already has code for reading this list and storing it on the screen [08:39] desrt, with 3.12 its just the window decorations [08:41] you have GtkHeaderBar:decoration-layout to see the window control within the buttons [08:56] seb128: is there a bug open about the can't-resize-csd-windows? [08:57] (upstream, ideally...) [09:00] desrt, larsu: not that I know, darkxst might know better, he has been working with upstream on those issues [09:01] to be honest- I didn't spend much energy on that since the plan for the LTS was to just avoid those [09:03] larsu, I don't think so, well I haven't seen one [09:05] thanks [09:05] larsu, is that just a theming issue though? adwaita has invisible borders to make grabbing the handles easier I believe [09:08] darkxst: it's both. You need the extension so that resizing a borderless window works and theming to draw the shadow [09:08] (which is drawn client side, oddly enough) [09:15] larsu: http://ur1.ca/h77j3 [09:15] larsu, not sure why that is odd? CSD's are client side ;) [09:17] news flash: resizing maybe not related to csd... [09:20] darkxst: just seems like it should be done in the compositor [09:20] so that stacking shadows can be dealt with properly [09:29] larsu: http://ur1.ca/h77me [09:37] larsu: yes, as said the _NET_SUPPORTED on root window can define that [09:37] larsu, desrt: the problem is that I don't see any app on gtk 3.10 (speaking of trusty SRUs) to export that... Thus I didn't implement on new decos [09:38] so there is a bug in gtk and also a bug in compiz [09:38] the bug in gtk is that it doesn't properly check for frame extents [09:38] but bug in compiz is that it doesn't resize windows that have borders [09:38] desrt: the bug is in unity now... Compiz doesn't handle decorations anymore [09:39] i'm gonna install xfce and check what happens there [09:39] desrt: but, well it's true we need to add an input border to these as well [09:39] desrt: ask seb128 [09:39] he tests on xfce all the time [09:40] seb128: can you test something for me? [09:42] desrt, yes? [09:43] seb128: nvm. installed it myself. [09:43] xfce has a totally different issue [09:43] k [09:43] it _always_ draws the titlebar, ignoring the hint [09:43] seems that gnome-shell is the only good WM here [09:43] (...and even gtk gets it wrong there) [09:44] * desrt tries kwin [09:44] anyway, back to the general problem, I don't the we can just ignore the headerbar hint on non-gnome desktops, as the header bar might also include elements (such as non-window-buttons) that might be not shown anywhere else.. [09:44] desrt, right, xfce is what gives you https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png [09:44] well, at least you know it's the calculator ;-) [09:44] this is xfce's fault, for sure [09:45] lol [09:45] that's a nice way to save vertical space [09:45] Trevinho, ignoring the hint still leaves the GtkHeaderBar in place [09:45] so you have a titlebar and the header bar [09:45] it is possible to override appmenu and window controls from theming/xsettings [09:45] darkxst: mh, so making it act like a toolbar without wm buttons, right? [09:46] Trevinho, exactly [09:46] atleast in gtk 3.12 [09:46] so if you use adwaita on gnome-classic you loose? [09:47] seb128: probably... [09:47] well... gnome-fallback, you mean [09:47] right [09:47] gnome classic works, obviously [09:47] gnome-panel+compiz [09:47] whatever that is called [09:47] compiz is borked [09:47] gnome-panel + ion [09:47] gtk + metacity will be broken right now for stupid reasons (gtk bug) [09:47] if you prefer :p [09:47] after my patch, gtk+metacity would work [09:47] since metacity is a good WM [09:48] compiz, on the other hand... ;) [09:48] s/a/the [09:48] * larsu hides [09:48] lol [09:48] what about "awesome"? ;-) [09:48] or whatever Laney is using [09:48] that frame based wm [09:48] desrt: it's quite trivial to fix *unity* as well ;) [09:48] that's not good, obviously. It's awesome [09:48] larsu, ;-) [09:48] Trevinho: please fix it :) [09:49] kwin does the same as xfce.... [09:49] seems that these hints (from *motif*) are not yet supported in these modern WMs :) [09:49] desrt: I will, but since we're focusing on T still, I will do that once gtk is exporting the atom [09:49] Trevinho: doesn't work that way. [09:49] Trevinho: you export the atom. [09:49] ah, ok [09:49] or rather, you don't [09:49] and then gtk sees that you don't and changes its behaviour [09:50] what you need to do is to support the 'border' hint properly [09:50] ie: i want a border on this window, but no titlebar [09:50] I see... [09:50] and if the user's unity/compiz/etc. theme has 0-width borders then you need to figure out how resizing will work... [09:51] xmonad [09:51] I don't have decorations [09:52] MWM_DECOR_BORDER is the name of the motif hint [09:53] _MOTIF_WM_HINTS [09:53] long live legacy! [09:57] desrt, yes that is it! hardly a new invention! [10:00] darkxst: do you know an upstream bug link for this issue? [10:01] desrt: would this recent change impact on us https://git.gnome.org/browse/gtk+/commit/?id=fb9a6bb6d8d6b60b25c9b9853decbc As it seems related to other WMs with duplicated borders [10:02] Trevinho: interesting...... [10:02] i was just about to add this check back in [10:02] i think maybe this was the wrong fix.... [10:03] * desrt will talk to mclasen about this later.... [10:03] * desrt feels like he just wasted a lot of time [10:05] desrt, there was a bug regarding titlebars, I will see if I can find it later (cooking dinner now) [10:06] and pretty sure it was mclasen who said the WM should ignore hints [10:07] vala-0.24, any objections? [10:07] i hate wms [10:08] wichard stallman [10:08] lol [10:08] seb128: on settings on the desktop. The brightness bar appears for a split second and then vanishes I'm pretty sure there is already a bug I've seen for it I was wondering if you knew if there was a fix knocking about I can try at all [10:08] davmor2, no idea [10:08] Laney, is that a new parallel source? [10:08] yes as normal, switches the default [10:08] Debian already did it [10:09] I guess it works fine with gtk 3.10? [10:09] well, let's go for it [10:09] we can rollback if it turns out to be needed [10:10] nod, ta [10:12] hmm, brightness api changed for 3.10, but that hasnt landed in archives yet [10:12] davmor2, are you using a ppa? [10:13] darkxst: Nope default trusty [10:13] haha yeah I see that too [10:14] no idea then, the brightness changes have not landed yet [10:14] * darkxst had to patch them out of gnome-shell... [10:15] Error getting brightnesS: Timeout was reached [10:16] Laney, the api changes (I know off) are in g-s-d 3.10 and maybe gnome-desktop 3.10 [10:17] Probably not relevant [10:17] Laney, yes I gathered, just saying [10:18] Nod, thanks [10:27] yeah not sure you can fix this without the new API [10:27] it's "see if the GetPercentage method times out" to determine whether to hide the row === MacSlow is now known as MacSlow|lunch [10:43] Laney, good luck with that ;) [10:46] I suggest the best way to fix this is to take the new properties from g-s-d 3.10 :-) [10:47] I see they've replaced the 'screen' panel upstream [10:57] Laney, that would require my displayconfig daemon, but that would work [10:57] and gnome-desktop 3.10 of course [10:58] we can probably manage that this cycle [10:58] couple of weeks of merging fun first though [10:59] Laney, right, dbus activation is broken right now due to glib changes, but thats easy enough to fix [11:00] Laney, mind you I would like to go straight to 3.12 [11:01] haha [11:01] 3.10 -> 3.12 was somewhat less disruptive I believe [11:02] they always say that? [11:03] seb128, I am saying that, although I haven't dug too deeply on it, so not sure how it might affect all the legacy stuff you guys are carrying, but I think it might be minimal [11:03] there is at least an abi/api change on keyboard stuff [11:03] I think we should do it by steps [11:04] start with 3.10, stabilize that and then see what's next [11:05] seb128, I certainly won't have to time to work on a double transition this cycle [11:05] seb128, and you little steps, generally end up in us missing out on various bits [11:06] well, the alternative is too land more than we can chew in a cycle and take an hit in quality [11:06] which we decided to stop doing [11:06] quality first nowadays [11:06] seb128, for gnome-desktop then? [11:06] ^fork [11:06] have a libunity-desktop ;) [11:07] I would like to land gnome-desktop, gnome-setting-daemon (vanillised) and gnome-control-centre (vanillised) all at the same time [11:07] that wouldn't work for the reasons we already mentioned [11:08] then we would need to build e.g nautilus and eog with one of the 2 libs [11:08] which would lead to "fork or dual build any consumer of the library that got forked" [11:08] seb128, apps can all build off the fork [11:09] hum [11:10] well, let's see how the cycle shapes, I doubt we are going to have free cycles for that [11:10] most of the app-side stuff apart from the thumbnailer is dead now [11:10] we said we would land 3.10 this cycle, you can get g-s-d and g-c-c vanillised with it [11:10] that should be a good start [11:10] seb128: would you reject valabind please https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 [11:10] stupid wrong target [11:10] * Laney needs to dist-upgrade already [11:11] Laney, done [11:11] ty [11:11] yw [11:11] I wonder what to do here [11:11] I'm tempted to stay on the LTS until .1 [11:11] seb128, not exactly, you forked g-s-d/g-c-c to unblock us, but it wasn't enough [11:11] i bet you have multiple machines [11:12] not that I use [11:12] like I've my old laptop and a netbook [11:12] but I boot them once a week as test machines [11:13] darkxst, right, it's a step in the right direction, but we manage to do only so much each cycle [11:13] seb128, which is why I think we should skip g-d 3.10 [11:14] I fail to see the logic there [11:15] 3.10 is , 3.12 is [11:15] if we directly go to 3.12 we sign for the extra work [11:15] it makes more sense to do it by steps and see how things go and how busy everyone is [11:15] hmm, not sure about that [11:15] seb128, no, 3.10 was , 3.12 is [11:15] it assumes 3.12 is going to be much more difficult [11:16] but doing the work twice is certainly going to be harder than doing it at once [11:16] I don't assume anything without having looked [11:16] but that means I don't assume it's going to be trivial work either [11:16] Laney, if you want to asset the work for 3.12 and "own" the transition feel free [11:16] I think we need to know what the api changes are [11:16] we just need somebody who commits to do the work [11:16] and I'm not that somebody [11:17] but I'm not stopping others ;-) [11:17] well I wouldn't mind assisting if -gnome wants to drive it [11:17] we need somebody to lead/commit to do it [11:17] I don't mind assisting either [11:17] but that's the typical "no real owner" that leads to "nobody has cycles to do the bulk of the work" [11:18] seb128, seriously, you just drive away all assistance, right? [11:18] sure, those who want the change can work for it [11:18] darkxst, ? [11:18] I have put in countless hours on work that ultimately gets knocked back each cycle [11:20] there has been for sure some friction between stability/updates, especially with everybody being busy and the LTS coming [11:20] we spent quite some work previous cycle to lower those frictions/resolve it [11:20] seb128, this goes back well before the LTS [11:20] (e.g with u-s-d u-c-c) [11:21] seb128, right and then you basically abandoned g-c-c? and desktop-team never uploaded by g-c-c 3.8 branch [11:21] well, bottom line is that we working on resolving those issues, even if it takes time [11:22] well, g-c-c is yours, yes we mostly stopped working on it (though robert_ancell did some fixing before release for e.u.c ranked issues) [11:22] seb128, while I agree you are working on resolving the issues, your methodology just makes more work for us [11:23] hum, g-c-c 3.8 was ready? the situation got a bit confused, there was nothing in the sponsoring queue and you guys were aiming for 3.10 [11:23] Personally I'm happy to work with you on gnome-desktop 3.12 if you want to do that, I tend to agree that doing it twice makes it more unlikely to happen [11:23] you have been without internet at the same time as well [11:23] which was unfortunate [11:23] seb128, only a 3 or so weeks [11:23] well, not sure why g-c-c 3.8 fall through the cracks then [11:24] it was not listed on the sponsoring queue [11:24] and nobody pinged back to remind us about it [11:24] seb128, there was definately a MP for it [11:24] anyway the point of all this, Is i want to go straight to 3.12 this cycle for g-d, g-s-d, g-c-c [11:24] there were 2, and they were not based on current trunk [11:24] k [11:24] fair enough [11:25] let's work on getting gnome-desktop 3.12 then [11:25] seb128, yes [11:25] g-s-d g-c-c are all yours [11:25] Laney, thanks for proposing to help there [11:25] sure [11:26] also I patched cheese 3.12 to have a conditional header bar ;-) [11:26] seb128, happy to deal with those [11:26] #bleedingedge [11:26] Laney, cheese is not using GTKHeaderBar? [11:27] sure it is [11:28] Laney, seems really wrong to patch individual apps in that case [11:28] how did we get cheese 3.12 ?! [11:28] we didn't [11:28] k [11:28] (yet) [11:28] because we didn't have the discussions on what we do with GNOME/apps this cycle (yet) [11:28] seb128, are you ok with g-s-d and g-c-c getting added to the ubuntu-gnome packageset? [11:29] darkxst, yes [11:29] darkxst, btw does anyone plan to SRU g-c-c to list the correct OS version in trusty? [11:29] seb128: seems I earned the libnotify merge (https://merges.ubuntu.com/libn/libnotify/libnotify_0.7.6-1ubuntu3.patch) -- do you remember why we needed to revert the gir api? [11:29] seb128, noskcaj was supposed to be on that [11:30] pitti, https://bugzilla.gnome.org/show_bug.cgi?id=709524 summarize it well [11:30] Gnome bug 709524 in general "API/ABI change to due recent add_action changes?" [Normal,Unconfirmed] [11:31] pitti, https://bugzilla.gnome.org/show_bug.cgi?id=702390#c13 [11:31]