<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="log-store-xml.xsl"?>
<log>
<message time='20131209T15:05:30' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, https://bugzilla.gnome.org/show_bug.cgi?id=720106 ?</message>
<message time='20131209T15:05:32' id='services' name='Services' token='' isuser='false' type='normal'>Bug 720106: normal, Normal, ---, mutter-maint, UNCONFIRMED, Simplify the _NET_WM_WINDOW_OPACITY handling</message>
<message time='20131209T15:05:43' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, (first part of the surface-content cleanup)</message>
<message time='20131209T16:07:15' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: hey, should we revert 666e5f1 keybindings: Port to Clutter ?</message>
<message time='20131209T16:07:25' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, no, why?</message>
<message time='20131209T16:08:59' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: well, you said last friday that the port to ClutterEvent was defeated anyway</message>
<message time='20131209T16:09:22' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, only for pointer events.</message>
<message time='20131209T16:09:40' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, since key focus is done explicitly in mutter and not related to picking, we&apos;d actually have a better chance of getting it right</message>
<message time='20131209T16:11:02' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: I&apos;d rather have this stuff consistent</message>
<message time='20131209T16:11:29' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, no, it&apos;s fine. Trust me, owen and I went over it.</message>
<message time='20131209T16:11:54' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, and by the way, you probably didn&apos;t notice, but I *didn&apos;t* revert the Clutter port for pointer events.</message>
<message time='20131209T16:12:08' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, we have both an X method and a Clutter method.</message>
<message time='20131209T16:17:28' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, I was going to write a giant comment about the event flow in every case.</message>
<message time='20131209T16:17:57' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: what I&apos;m trying is getting gnome-shell-wayland working in X mode</message>
<message time='20131209T16:18:08' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>and keybindings are broken</message>
<message time='20131209T16:18:16' id='jasper' name='Jasper' token='' isuser='false' type='normal'>hm, why?</message>
<message time='20131209T16:18:57' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, running mutter-wayland as an X compositor, keybindings work fine for me</message>
<message time='20131209T16:19:00' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: basically because the JS handlers don&apos;t cope with the signature change of MetaKeyHandlerFunc</message>
<message time='20131209T16:19:14' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, did we depend on that at all?</message>
<message time='20131209T16:20:07' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: with mutter, the event is annotated as type gpointer and seems to be skipped</message>
<message time='20131209T16:20:36' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, right, but it&apos;s the last field</message>
<message time='20131209T16:20:47' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>but on -wayland it&apos;s a ClutterEvent* so we need to change the JS handlers args</message>
<message time='20131209T16:20:49' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, after that is user_data, which is automatic</message>
<message time='20131209T16:21:29' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>no, it&apos;s *display, *screen, *window, *event, *binding, *data</message>
<message time='20131209T16:21:35' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, oh, wait, there&apos;s a binding in there somewhere, but do we use that anywhere?</message>
<message time='20131209T16:21:54' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>yes, see the handlers in windowManager.js</message>
<message time='20131209T16:22:07' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, switching it so that it goes *binding, *event, *data should fix it then</message>
<message time='20131209T16:22:39' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, I thought it would get filled in with &quot;null&quot;, tbh. Skipping it just seems absolutely wrong to me.</message>
<message time='20131209T16:22:44' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: it does, but then it breaks running on mutter</message>
<message time='20131209T16:23:04' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, switch it on both places.</message>
<message time='20131209T16:23:11' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, then it should work fine.</message>
<message time='20131209T16:23:41' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>oh I see</message>
<message time='20131209T16:23:46' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, that said, does anything even use the &quot;event&quot; argument in mutter&apos;s default keybindings?</message>
<message time='20131209T16:23:51' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, we might just want to remove it everywhere.</message>
<message time='20131209T16:24:05' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>let me check that</message>
<message time='20131209T16:25:02' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: do you have a plan for The Big Merge? :-)</message>
<message time='20131209T16:25:16' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, merge https://git.gnome.org/browse/mutter/log/?h=wip/surface-content in</message>
<message time='20131209T16:25:40' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, then merge with mutter-wayland taking priority, except for &quot;po&quot; -- use master for that.</message>
<message time='20131209T16:26:57' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>ok</message>
<message time='20131209T16:41:45' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, a review on https://bugzilla.gnome.org/show_bug.cgi?id=720106 would be appreciated</message>
<message time='20131209T16:41:46' id='services' name='Services' token='' isuser='false' type='normal'>Bug 720106: normal, Normal, ---, mutter-maint, UNCONFIRMED, Simplify the _NET_WM_WINDOW_OPACITY handling</message>
<message time='20131209T16:43:07' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: ok, after I finish with this keybindings thing</message>
<message time='20131209T16:43:20' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, cool, thanks</message>
<message time='20131209T16:43:53' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: btw, getting the xwayland windows working would be great so that things start working reasonably well again</message>
<message time='20131209T16:44:10' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, I&apos;m still undecided about what to do for that.</message>
<message time='20131209T16:44:55' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, the problem is that by the time we call XMapWindow and we get the set_window_id request, we&apos;ve already told the compositor about our window</message>
<message time='20131209T16:44:55' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: needs to be discussed with krh ?</message>
<message time='20131209T16:45:09' id='mclasen' name='mclasen' token='' isuser='false' type='action'>is +1 for working reasonably</message>
<message time='20131209T16:45:28' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, I don&apos;t think so. I think fixing XWayland so that it does set_window_id at CreateWindow time would be better, but not mandatory</message>
<message time='20131209T16:47:40' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: can&apos;t we just if (is_wayland_compositor) { XMapWindow(); /* then create the MetaWindow from the wayland surface from the X server */ } else { do_what_we_do_now(); } ?</message>
<message time='20131209T16:48:01' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>in the XMapRequest handler</message>
<message time='20131209T16:49:34' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: this is basically what the weston xwm does. not sure how well it maps to us though</message>
<message time='20131209T16:50:15' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, because mutter is a tanker of a codebase</message>
<message time='20131209T16:50:32' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, do_what_we_do_now(); is split across window.c, frame.c, display.c</message>
<message time='20131209T16:50:53' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, and we want to do 90% of it for both XWayland and X compositors</message>
<message time='20131209T17:36:10' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>hi Jasper, what&apos;s the plan for integration of IM with the shell onwards? noticed that the &quot;control the presence status from the shell&apos;s system menu&quot; feature is gone in 3.10 and was wondering if that&apos;s a decision or a regression bug or whatnot</message>
<message time='20131209T17:36:24' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>(just curious)</message>
<message time='20131209T17:36:40' id='jasper' name='Jasper' token='' isuser='false' type='normal'>nekohayo, it was added back somewhat to the message tray menu</message>
<message time='20131209T17:36:52' id='jasper' name='Jasper' token='' isuser='false' type='normal'>nekohayo, I think we want to move a lot of this to the Chat app</message>
<message time='20131209T17:37:10' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>oh well the control of notifications yes, but the presence status I mean</message>
<message time='20131209T17:37:15' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>chat app != polari?</message>
<message time='20131209T17:38:11' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>thinking of reforging Empathy&apos;s UI or to make an actual new non-IRC chat app?</message>
<message time='20131209T17:38:12' id='jasper' name='Jasper' token='' isuser='false' type='normal'>nekohayo, chat app is empathy/chat</message>
<message time='20131209T17:38:24' id='jasper' name='Jasper' token='' isuser='false' type='normal'>nekohayo, rishi started on a gnome-chat module, but I don&apos;t know how official that is.</message>
<message time='20131209T17:38:36' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>ah</message>
<message time='20131209T17:43:33' id='rishi' name='rishi' token='' isuser='false' type='normal'>Jasper: It is based on the designs on the Wiki page.</message>
<message time='20131209T17:43:41' id='rishi' name='rishi' token='' isuser='false' type='normal'>Do not know if that makes it official or not.</message>
<message time='20131209T17:44:07' id='rishi' name='rishi' token='' isuser='false' type='normal'>But if someone else is interested to run with it, or modify empathy instead, be my guest.</message>
<message time='20131209T17:44:21' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: ^^^</message>
<message time='20131209T17:49:13' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>rishi, I&apos;m not part of the empathy team or anything so don&apos;t get me wrong, but just looking at the list of files in https://git.gnome.org/browse/gnome-chat/tree/src I see that it&apos;s all in C, and with some parts salvaged from empathy... so why not just modify empathy in the first place anyway?</message>
<message time='20131209T17:50:28' id='mccann' name='mccann' token='' isuser='false' type='normal'>we&apos;ve tried for 3 years now</message>
<message time='20131209T17:50:42' id='mccann' name='mccann' token='' isuser='false' type='normal'>there seems to be no interest in that</message>
<message time='20131209T17:53:05' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>no interest from the empathy team to accomodate a new design? you&apos;re kidding me</message>
<message time='20131209T17:54:00' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>pretty sure cassidy was excited about those designs last time I asked</message>
<message time='20131209T17:56:58' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>and I recall him being involved in bug reports wrt how to solve the problem of consistency/persistence and I&apos;m pretty sure he&apos;s in favor of the &quot;unify the contact list with the chat window instead of the MDI problems we have now&quot;</message>
<message time='20131209T17:57:21' id='jasper' name='Jasper' token='' isuser='false' type='normal'>Cool, so it should be easy to get him interested again.</message>
<message time='20131209T17:57:30' id='jasper' name='Jasper' token='' isuser='false' type='normal'>Feel free to try.</message>
<message time='20131209T17:58:01' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>would be interesting</message>
<message time='20131209T18:00:24' id='mccann' name='mccann' token='' isuser='false' type='normal'>nekohayo: I&apos;m not kidding you</message>
<message time='20131209T18:00:41' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>mccann, you meant in terms of vision or in terms of manpower?</message>
<message time='20131209T18:01:29' id='mccann' name='mccann' token='' isuser='false' type='normal'>both and in terms of not being wise</message>
<message time='20131209T18:01:51' id='mccann' name='mccann' token='' isuser='false' type='normal'>I see no point in completely tearing empathy apart and rewriting it completely</message>
<message time='20131209T18:02:07' id='mccann' name='mccann' token='' isuser='false' type='normal'>the designs are 100% different from what empathy is today</message>
<message time='20131209T18:02:23' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>that doesn&apos;t mean writing from scratch is more efficient</message>
<message time='20131209T18:02:41' id='mccann' name='mccann' token='' isuser='false' type='normal'>given that the new designs will take time to develop I think it is much better to leave what already works working</message>
<message time='20131209T18:02:47' id='mccann' name='mccann' token='' isuser='false' type='normal'>nekohayo: it is actually</message>
<message time='20131209T18:02:53' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>especially if we&apos;re in the same programming language and toolset, that reminds me a lot of http://www.joelonsoftware.com/articles/fog0000000069.html</message>
<message time='20131209T18:02:56' id='mccann' name='mccann' token='' isuser='false' type='normal'>and much less shitstorm</message>
<message time='20131209T18:03:05' id='jasper' name='Jasper' token='' isuser='false' type='normal'>We&apos;re reusing code from empathy when we can.</message>
<message time='20131209T18:03:11' id='jasper' name='Jasper' token='' isuser='false' type='normal'>It&apos;s not like we&apos;re starting from scratch.</message>
<message time='20131209T18:03:15' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>hm</message>
<message time='20131209T18:03:18' id='jasper' name='Jasper' token='' isuser='false' type='normal'>And a large part of it is part of Telepathy.</message>
<message time='20131209T18:03:51' id='mccann' name='mccann' token='' isuser='false' type='normal'>there is no such thing as &quot;from scratch&quot; in free software anyway - I hate that phrase</message>
<message time='20131209T18:04:07' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>so basically Chat is to Empathy what Empathy is to Gossip - the new experimental skunkworks potential replacement</message>
<message time='20131209T18:04:20' id='jasper' name='Jasper' token='' isuser='false' type='normal'>The reason we&apos;re able to bootstrap a chat app quickly is because we have a lot of code and libraries that we can use.</message>
<message time='20131209T18:04:34' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>&apos;cause honestly Empathy doesn&apos;t feel like a finished and polished product, it feels like something from the 2.x era tacked onto the 3.x era</message>
<message time='20131209T18:04:43' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>and I&apos;m pretty darn sure empathy devs agree with that sentiment</message>
<message time='20131209T18:04:45' id='mccann' name='mccann' token='' isuser='false' type='normal'>nekohayo: you can think of it however you want but it has a different design and is a different app</message>
<message time='20131209T18:05:14' id='mccann' name='mccann' token='' isuser='false' type='normal'>I&apos;d love to see the &quot;empathy&quot; developers make Chat honestly</message>
<message time='20131209T18:06:02' id='mccann' name='mccann' token='' isuser='false' type='normal'>or anyone else who wants to help</message>
<message time='20131209T18:06:03' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>if gnome-chat matures I somewhat assure you people would be ditching empathy in favor of it - &apos;cause fundamentally, Empathy is no different than Pidgin</message>
<message time='20131209T18:06:26' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>so what&apos;s the point of Empathy&apos;s existence in a gnome3 world when there is gnome-chat...</message>
<message time='20131209T18:06:33' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>and pidgin,...</message>
<message time='20131209T18:06:40' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>(just my train of thought there :)</message>
<message time='20131209T18:06:47' id='mccann' name='mccann' token='' isuser='false' type='normal'>what does that question even mean?</message>
<message time='20131209T18:07:25' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>it means to me that gnome-chat, be it a separate app as it is now or the morphing of empathy, is going to make Empathy obsolete from an evolutionary standpoint</message>
<message time='20131209T18:07:38' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>guess it&apos;s hard to convey what I mean right now</message>
<message time='20131209T18:07:57' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>that&apos;s not necessarily a bad thing</message>
<message time='20131209T18:08:08' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>just the natural consequence</message>
<message time='20131209T18:09:14' id='mccann' name='mccann' token='' isuser='false' type='normal'>If you are asking me if *I think* there is any point in continuing to work on Empathy - then no</message>
<message time='20131209T18:09:32' id='mccann' name='mccann' token='' isuser='false' type='normal'>but everyone is entitled to their own opinion on how they spend their time</message>
<message time='20131209T18:09:58' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>I understand your perspective and I see what you mean</message>
<message time='20131209T18:10:01' id='jasper' name='Jasper' token='' isuser='false' type='normal'>and just so we&apos;re clear, mccann is talking about empathy the app, not empathy the codebase</message>
<message time='20131209T18:10:17' id='jasper' name='Jasper' token='' isuser='false' type='normal'>whether empathy the app wants to be chat the app is another question, and that&apos;s up to the empathy maintainers</message>
<message time='20131209T18:10:54' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>what is an app if not for its &quot;name&quot; and the codebase?</message>
<message time='20131209T18:10:59' id='jasper' name='Jasper' token='' isuser='false' type='normal'>its design</message>
<message time='20131209T18:11:04' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>oh yeah that</message>
<message time='20131209T18:11:07' id='mccann' name='mccann' token='' isuser='false' type='normal'>heh</message>
<message time='20131209T18:11:33' id='mccann' name='mccann' token='' isuser='false' type='normal'>if empathy and Chat both try to implement the same design I&apos;m not opposed</message>
<message time='20131209T18:12:02' id='mccann' name='mccann' token='' isuser='false' type='normal'>but it doesn&apos;t make any sense to me to break what is working when it is easier not to</message>
<message time='20131209T18:12:09' id='mccann' name='mccann' token='' isuser='false' type='normal'>I&apos;ve been through that way too many times</message>
<message time='20131209T18:12:11' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>well you&apos;re touching the core of the issue: if both do that, it&apos;s a big waste. On the other hand, as I understand it, your perception is that empathy folks don&apos;t have time/motivation to do it anyway</message>
<message time='20131209T18:12:23' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>ah hm</message>
<message time='20131209T18:12:36' id='jasper' name='Jasper' token='' isuser='false' type='normal'>I think it&apos;s also that if we want to port one codebase over, we&apos;ll be in this midway state where everything is broken.</message>
<message time='20131209T18:12:36' id='mccann' name='mccann' token='' isuser='false' type='normal'>it doesn&apos;t work that way</message>
<message time='20131209T18:12:45' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>I see</message>
<message time='20131209T18:12:46' id='jasper' name='Jasper' token='' isuser='false' type='normal'>And that just sucks for everybody.</message>
<message time='20131209T18:13:31' id='jasper' name='Jasper' token='' isuser='false' type='normal'>So sure, we&apos;ll reuse the empathy code when it makes sense, but really, Chat is a seperate app and it probably makes more sense to not morph from one to the other.]</message>
<message time='20131209T18:13:32' id='mccann' name='mccann' token='' isuser='false' type='normal'>am I all broken up inside that geary didn&apos;t start with evolution?</message>
<message time='20131209T18:13:36' id='mccann' name='mccann' token='' isuser='false' type='normal'>not at all</message>
<message time='20131209T18:13:59' id='mccann' name='mccann' token='' isuser='false' type='normal'>is that a waste? not to me</message>
<message time='20131209T18:14:27' id='jasper' name='Jasper' token='' isuser='false' type='normal'>geary also uses some of evolution&apos;s code when it thinks it helps</message>
<message time='20131209T18:15:03' id='mccann' name='mccann' token='' isuser='false' type='normal'>yeah whatever</message>
<message time='20131209T18:15:28' id='mccann' name='mccann' token='' isuser='false' type='normal'>the most important thing is really intention</message>
<message time='20131209T18:17:46' id='dj-death' name='dj-death' token='' isuser='false' type='normal'>maybe the fact that geary is written in vala prevents it to be part of the evolution package</message>
<message time='20131209T18:17:47' id='mccann' name='mccann' token='' isuser='false' type='normal'>when we started working on the designs for all the core apps I reached out to pretty much everyone working on similar apps</message>
<message time='20131209T18:18:20' id='mccann' name='mccann' token='' isuser='false' type='normal'>some of them bought into the new designs. like the epiphany maintainers.</message>
<message time='20131209T18:18:33' id='mccann' name='mccann' token='' isuser='false' type='normal'>most didn&apos;t</message>
<message time='20131209T18:18:40' id='mccann' name='mccann' token='' isuser='false' type='normal'>which is totally fine</message>
<message time='20131209T18:18:49' id='mccann' name='mccann' token='' isuser='false' type='normal'>we can and should have apps to chose from</message>
<message time='20131209T18:19:20' id='mccann' name='mccann' token='' isuser='false' type='normal'>anyway hmm is claudio reviewing my Web patch?...</message>
<message time='20131209T18:19:48' id='claudio' name='claudio' token='' isuser='false' type='normal'>mccann, WAT</message>
<message time='20131209T18:19:56' id='claudio' name='claudio' token='' isuser='false' type='normal'>WAT IS LOVE</message>
<message time='20131209T18:20:01' id='claudio' name='claudio' token='' isuser='false' type='normal'>BABY DONT HURT ME.</message>
<message time='20131209T18:20:16' id='jasper' name='Jasper' token='' isuser='false' type='normal'>hi</message>
<message time='20131209T18:20:27' id='mccann' name='mccann' token='' isuser='false' type='normal'>NO MORE</message>
<message time='20131209T18:20:50' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>thanks for the clarifications mccann, Jasper :)</message>
<message time='20131209T18:21:48' id='jasper' name='Jasper' token='' isuser='false' type='normal'>nekohayo, it&apos;s sort of a different approach</message>
<message time='20131209T19:04:38' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland fd8cc9b mutter src/wayland/meta-xwayland.c * xwayland: Remove outdated code * https://git.gnome.org/browse/mutter/commit/?id=fd8cc9b</message>
<message time='20131209T19:04:38' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 1b600f5 mutter src/compositor/meta-window-actor.c * window-actor: Use g_signal_connect_object * https://git.gnome.org/browse/mutter/commit/?id=1b600f5</message>
<message time='20131209T19:07:42' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 56aae17 mutter src/compositor/meta-window-actor.c * window-actor: Remove outdated code path * https://git.gnome.org/browse/mutter/commit/?id=56aae17</message>
<message time='20131209T19:07:42' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 3e179c0 mutter src/ (6 files in 2 dirs) * window: Add a simple meta_window_get_toplevel_xwindow utility * https://git.gnome.org/browse/mutter/commit/?id=3e179c0</message>
<message time='20131209T19:07:42' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master f8b4c28 mutter src/compositor/meta-window-actor.c * window-actor: Remove (private) xwindow property * https://git.gnome.org/browse/mutter/commit/?id=f8b4c28</message>
<message time='20131209T19:07:43' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 734deeb mutter src/compositor/meta-window-actor.c * window-actor: Remove meta-screen property * https://git.gnome.org/browse/mutter/commit/?id=734deeb</message>
<message time='20131209T19:07:47' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 8a76383 mutter src/compositor/meta-window-actor.c * window-actor: Make the meta-window property construct-only * https://git.gnome.org/browse/mutter/commit/?id=8a76383</message>
<message time='20131209T19:07:51' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master a3eb5e5 mutter src/compositor/meta-window-actor.c * window-actor: Move signal handler connections to the meta-window setter * https://git.gnome.org/browse/mutter/commit/?id=a3eb5e5</message>
<message time='20131209T19:08:18' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland f0fa4d8 mutter src/ (6 files in 2 dirs) * window: Add a simple meta_window_get_toplevel_xwindow utility * https://git.gnome.org/browse/mutter/commit/?id=f0fa4d8</message>
<message time='20131209T19:08:18' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 422648e mutter src/compositor/meta-window-actor.c * window-actor: Remove (private) xwindow property * https://git.gnome.org/browse/mutter/commit/?id=422648e</message>
<message time='20131209T19:08:18' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 98dbba1 mutter src/compositor/meta-window-actor.c * window-actor: Remove meta-screen property * https://git.gnome.org/browse/mutter/commit/?id=98dbba1</message>
<message time='20131209T19:08:19' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 65f2e29 mutter src/compositor/meta-window-actor.c * window-actor: Make the meta-window property construct-only * https://git.gnome.org/browse/mutter/commit/?id=65f2e29</message>
<message time='20131209T19:08:23' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland e30be38 mutter src/compositor/meta-window-actor.c * window-actor: Move signal handler connections to the meta-window setter * https://git.gnome.org/browse/mutter/commit/?id=e30be38</message>
<message time='20131209T19:11:11' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 66af41f mutter src/compositor/meta-window-actor.c * window-actor: Remove outdated code path * https://git.gnome.org/browse/mutter/commit/?id=66af41f</message>
<message time='20131209T19:12:01' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, owen: hm, I&apos;m running into the &quot;null surface actor&quot; case</message>
<message time='20131209T19:13:07' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Well, the easiest thing to do is to make MetaSurfaceActor only *optioanlly* have content</message>
<message time='20131209T19:13:27' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I took your advice about making MetaSurfaceActorX11 / MetaSurfaceActorWayland.</message>
<message time='20131209T19:13:33' id='jasper' name='Jasper' token='' isuser='false' type='normal'>(and the code got cleaned up a lot)</message>
<message time='20131209T19:13:45' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen: I&apos;m wondering why we have meta_compositor_window_mapped and meta_compositor_add_window as separate things -- do we ever unmap the client window unless we&apos;re destroying it?</message>
<message time='20131209T19:14:11' id='jasper' name='Jasper' token='' isuser='false' type='normal'>Simply waiting until we map the client window with the first QUEUE_SHOWN before telling the compositor about it should solve it.</message>
<message time='20131209T19:16:09' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Not sure. Have you checked for O-R windows when we create the MetaWindow - do we create that in MapNotify?</message>
<message time='20131209T19:18:00' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 5a63aaa mutter src/compositor/meta-window-actor.c * window-actor: Fix build * https://git.gnome.org/browse/mutter/commit/?id=5a63aaa</message>
<message time='20131209T19:20:12' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, it depends on when we call meta_window_new</message>
<message time='20131209T19:22:16' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, that&apos;s when meta_compositor_add_window is called -- at meta_window_new.</message>
<message time='20131209T19:22:49' id='jasper' name='Jasper' token='' isuser='false' type='normal'>At that time, we&apos;ve queued a CALC_SHOWING, so that will happen on the next later run</message>
<message time='20131209T19:24:27' id='jasper' name='Jasper' token='' isuser='false' type='normal'>I&apos;m unsure about O-R windows -- meta_compositor_window_mapped / meta_window_actor_show doesn&apos;t seem like it will be called (since calc_showing didn&apos;t map the window), so I&apos;m unsure what will happen overall.</message>
<message time='20131209T19:25:11' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, how do you feel about removing meta<message time='20131209T19:29:00' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, https://git.gnome.org/browse/mutter/commit/h=wayland&amp;id=153d8efcf5827c3d444088801cb5de7a5c241d4b</message>
<message time='20131209T19:29:03' id='jasper' name='Jasper' token='' isuser='false' type='normal'>erm</message>
<message time='20131209T19:29:09' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, https://git.gnome.org/browse/mutter/commit/?h=wayland&amp;id=153d8efcf5827c3d444088801cb5de7a5c241d4b</message>
<message time='20131209T19:29:26' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I added a special &quot;surface_mapped&quot; property that gets used on show/hide.</message>
<message time='20131209T19:31:22' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: mm, that&apos;s sort of horrible, to have both &quot;mapped&quot; and &quot;surface_mapped&quot; concepts that mean approximately the same thing</message>
<message time='20131209T19:31:40' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, attaching NULL buffers is sort of horrible in general.</message>
<message time='20131209T19:32:00' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I didn&apos;t look too closely at any of the other boolean fields I might have adapted.</message>
<message time='20131209T19:32:04' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: But if you can get rid of the &quot;mapped&quot; concept, then I don&apos;t have any real objection to it. Just check carefully through the cases</message>
<message time='20131209T19:32:38' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, the only thing I ran into so far was shading, but I think we can simply implement that without unmapping the client window.</message>
<message time='20131209T19:32:48' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: If you can&apos;t, it seems the approach would be to post-hoc fill a MetaSurfaceActorWayland </message>
<message time='20131209T19:32:56' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: That&apos;s not ICCCM compliant</message>
<message time='20131209T19:33:23' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, is minimizing without unmapping ICCCM compliant?</message>
<message time='20131209T19:33:34' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Hard to say....</message>
<message time='20131209T19:33:44' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Probably not either :-)</message>
<message time='20131209T19:34:07' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>Jasper: shading will have to be done client-side with csd, I guess</message>
<message time='20131209T19:34:08' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I didn&apos;t know the ICCCM had anything to say about shading windows.</message>
<message time='20131209T19:34:17' id='jasper' name='Jasper' token='' isuser='false' type='normal'>mclasen, if we even want to support it...</message>
<message time='20131209T19:34:28' id='mclasen' name='mclasen' token='' isuser='false' type='action'>doesn&apos;t, but has already gotten requests for it</message>
<message time='20131209T19:35:52' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: How would you support shading without unampping the client window? Use a frame window that isn&apos;t a parent of the client window? </message>
<message time='20131209T19:37:31' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Spending a lot of effort on that does seem like it&apos;s putting the cart before the horse - since the ability to unmap an X11 window is not *actually* keeping you from having a wayland window appear with a surface actor when it first appears</message>
<message time='20131209T19:37:40' id='owen' name='owen' token='' isuser='false' type='normal'>(xwayland window)</message>
<message time='20131209T19:38:29' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, the big issue is that XWayland is calling set_surface_id on MapNotify, not CreateNotify.</message>
<message time='20131209T19:38:54' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: What happens when the XWayalnd window is unmapped?</message>
<message time='20131209T19:39:05' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I have no idea.</message>
<message time='20131209T19:39:32' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I think it would make sense to attach a NULL buffer.</message>
<message time='20131209T19:41:24' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, I&apos;d imagine &quot;UnrealizeWindow&quot; is called on unmap? I&apos;m not sure.</message>
<message time='20131209T19:42:04' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, it destroys the surface on UnrealizeWindow: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/xwayland/xwayland-window.c?h=xwayland#n156</message>
<message time='20131209T19:42:06' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: How much of a  bother would it be to not create the MetaWaylandACtor when the MetaWaylandSurface is created, and instead tie its life cycle to the MetaSurfaceActorWayland ?</message>
<message time='20131209T19:42:58' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: So basically, in the ICCCM Iconified state, there&apos;s a MetaWindow, but no surface</message>
<message time='20131209T19:43:03' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, there is no &quot;MetaWaylandActor&quot;. There is only &quot;MetaSurfaceActorWayland&quot;</message>
<message time='20131209T19:43:27' id='owen' name='owen' token='' isuser='false' type='normal'>Rrr, yeah, that didn&apos;t make a lot a sense</message>
<message time='20131209T19:43:27' id='jasper' name='Jasper' token='' isuser='false' type='normal'>I&apos;m assuming one of those should have been &quot;MetaWindowActor&quot;</message>
<message time='20131209T19:43:55' id='owen' name='owen' token='' isuser='false' type='normal'> Jasper: How much of a  bother would it be to not create the MetaSurfaceActorWayland when the MetaWaylandSurface is created, and instead tie its life cycle to the MetaWindowActor?</message>
<message time='20131209T19:44:34' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, for subsurfaces, that means that if they attach a NULL buffer, their input / opaque regions will go away.</message>
<message time='20131209T19:44:45' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, unless we store that somewhere. So that&apos;s not spec-compliant.</message>
<message time='20131209T19:45:04' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: To deal with the ICCCM Iconfieid state then you can ether a) Allow MetaWindow with no MetaWindowActor b) Allow MetaWindowActor wth no surface or c) Stop using the ICCCM Iconfiied state</message>
<message time='20131209T19:45:24' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, what does mutter do right now?</message>
<message time='20131209T19:45:32' id='jasper' name='Jasper' token='' isuser='false' type='normal'>just under X, not Wayland</message>
<message time='20131209T19:46:10' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: But you could store the input/opaque regions elsewhere, right?</message>
<message time='20131209T19:48:04' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: I&apos;m thinking that th e transition between Iconiied and Normal is the map/unmap methods on MetaWindowActor - but that doesn&apos;t make much sense, since the compositor doesn&apos;t care if the client window is mapped, it cares if the *toplevel* is mapped, and for a shaded window, the toplevel *is* mapped</message>
<message time='20131209T19:49:26' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: So I think you are actually probably wrong about shaded windows being an issue</message>
<message time='20131209T19:53:32' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, OK, so you think removing meta_compositor_add_window is fine?</message>
<message time='20131209T19:53:52' id='owen' name='owen' token='' isuser='false' type='normal'>And since we only have live hidden windows now (not originially), we probably do in fact only map/unmap windows at creation destruction</message>
<message time='20131209T19:54:21' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Is it going to be clearer if you repurpose add/remove window and remove map/unmap window?</message>
<message time='20131209T19:54:58' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, yeah, I noticed a few comments about &quot;live_hidden_windows&quot; - I assume that was an old preference?</message>
<message time='20131209T19:55:08' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, map/unmap have an effect argument, add/remove do not</message>
<message time='20131209T19:55:19' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Yes (until fairly recently, you probably were in on it&apos;s removal)</message>
<message time='20131209T19:55:22' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, just felt it would be easier everywhere.</message>
<message time='20131209T19:55:28' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: OK, no real objection</message>
<message time='20131209T19:58:18' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, OK.</message>
<message time='20131209T19:58:53' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, and while you&apos;re around, review on https://bugzilla.gnome.org/show_bug.cgi?id=720106 would be appreciated</message>
<message time='20131209T19:58:54' id='services' name='Services' token='' isuser='false' type='normal'>Bug 720106: normal, Normal, ---, mutter-maint, UNCONFIRMED, Simplify the _NET_WM_WINDOW_OPACITY handling</message>
<message time='20131209T20:08:41' id='owen' name='owen' token='' isuser='false' type='normal'>Jasper: Done</message>
<message time='20131209T20:20:26' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: man, I tried to cherry pick your ClutterEvent porting patches to master bug failed miserably :-(</message>
<message time='20131209T20:20:39' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, yeah, that&apos;s not going to work</message>
<message time='20131209T20:21:00' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: so, instead, can I push http://paste.fedoraproject.org/60279/38662041/ so that Alt+Tab works ?</message>
<message time='20131209T20:21:21' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, yeah, I&apos;d say that&apos;s fine for now</message>
<message time='20131209T20:21:29' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, did you try rearranging the order on both branches?</message>
<message time='20131209T20:22:10' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: no, because I figured that would make it even harder to merge the code later</message>
<message time='20131209T20:22:27' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, why?</message>
<message time='20131209T20:22:46' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, keep in mind we&apos;re not going to merge</message>
<message time='20131209T20:23:30' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>oh, you mean that at some point wayland will just become master ?</message>
<message time='20131209T20:23:35' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>owen: is https://bugzilla.gnome.org/show_bug.cgi?id=719669 needed for 3.10 (or 3.8) as well ?</message>
<message time='20131209T20:23:36' id='services' name='Services' token='' isuser='false' type='normal'>Bug 719669: normal, Normal, ---, mutter-maint, RESOLVED FIXED, lingering shadows</message>
<message time='20131209T20:24:11' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>I assume it is needed for 3.10 (because I am seeing those lingering shadows on f20)</message>
<message time='20131209T20:26:10' id='owen' name='owen' token='' isuser='false' type='normal'>mclasen: It&apos;s needed for 3.10 - 3.8 probably only if the clutter patch to avoid queueing redraws is applied, otherwise, hiding members of the popup window group will redraw the whole screen anyways</message>
<message time='20131209T20:26:36' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, yes</message>
<message time='20131209T20:26:41' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>could you backport it ? it doesn&apos;t apply cleanly on either 3.10 or 3.8</message>
<message time='20131209T20:26:47' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, besides translations, since translators don&apos;t commit to wayland very often</message>
<message time='20131209T20:27:47' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: ok, that makes a lot of sense. Just this handful of patches I tried was already a nightmare</message>
<message time='20131209T20:28:47' id='owen' name='owen' token='' isuser='false' type='normal'>mclasen: Cherry picks onto both branches fine for me, maybe gits benig a bit smarter about context than patch</message>
<message time='20131209T20:29:00' id='rtcm' name='rtcm' token='' isuser='false' type='normal'>Jasper: but anyway, swapping the args is a lot of churn for no gain since the JS code won&apos;t use the event argument anyway</message>
<message time='20131209T20:29:02' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>ok, I&apos;ll try that - but maybe you want to push it to those branches ?</message>
<message time='20131209T20:29:03' id='owen' name='owen' token='' isuser='false' type='normal'>mclasen: I can push</message>
<message time='20131209T20:29:25' id='commits' name='Commits' token='' isuser='false' type='normal'>otaylor gnome-3-8 16629c2 mutter src/compositor/meta-window-group.c * MetaWindowGroup: fix paint volume * https://git.gnome.org/browse/mutter/commit/?id=16629c2</message>
<message time='20131209T20:29:32' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, I guess</message>
<message time='20131209T20:29:43' id='commits' name='Commits' token='' isuser='false' type='normal'>otaylor gnome-3-10 01e0eaf mutter src/compositor/meta-window-group.c * MetaWindowGroup: fix paint volume * https://git.gnome.org/browse/mutter/commit/?id=01e0eaf</message>
<message time='20131209T20:29:50' id='owen' name='owen' token='' isuser='false' type='normal'>mclasen: Done</message>
<message time='20131209T20:30:10' id='mclasen' name='mclasen' token='' isuser='false' type='normal'>thanks, I&apos;ll add mutter builds to those updates then</message>
<message time='20131209T20:38:02' id='commits' name='Commits' token='' isuser='false' type='normal'>tiagomatos wayland bad48ea mutter src/meta/prefs.h * introspection: Make MetaKeyHandlerFunc compatible with master * https://git.gnome.org/browse/mutter/commit/?id=bad48ea</message>
<message time='20131209T20:51:19' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 93a8933 mutter src/compositor/ compositor-private.h compositor.c * compositor: Remove atom_x_root_pixmap * https://git.gnome.org/browse/mutter/commit/?id=93a8933</message>
<message time='20131209T20:51:19' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre master 1db95bc mutter src/ (8 files in 3 dirs) * Move _NET_WM_WINDOW_OPACITY handling to the standard window-props interface * https://git.gnome.org/browse/mutter/commit/?id=1db95bc</message>
<message time='20131209T20:53:37' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland f29241d mutter src/compositor/ compositor-private.h compositor.c * compositor: Remove atom_x_root_pixmap * https://git.gnome.org/browse/mutter/commit/?id=f29241d</message>
<message time='20131209T20:53:37' id='commits' name='Commits' token='' isuser='false' type='normal'>jstpierre wayland 8131f34 mutter src/ (8 files in 3 dirs) * Move _NET_WM_WINDOW_OPACITY handling to the standard window-props interface * https://git.gnome.org/browse/mutter/commit/?id=8131f34</message>
<message time='20131209T21:19:41' id='jasper' name='Jasper' token='' isuser='false' type='normal'>owen, hm, even that doesn&apos;t work, since we need to wait for the MapNotify to guarantee that we know the window ID at that point, and doing that just wrecks everything...</message>
<message time='20131209T21:20:01' id='jasper' name='Jasper' token='' isuser='false' type='normal'>unless we want the mainloop to be reentrant, ugh</message>
<message time='20131209T21:47:09' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Hey! Sorry, I was AFK.</message>
<message time='20131209T21:48:37' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Personally whenever someone says &quot;modify X app into Y&quot;, where X and Y have very different UI/UX but use the same underlying layers it boils to:</message>
<message time='20131209T21:49:28' id='rishi' name='rishi' token='' isuser='false' type='normal'>(1) Is it worth the pain to endure the flames from existing users of X, and to.</message>
<message time='20131209T21:50:12' id='rishi' name='rishi' token='' isuser='false' type='normal'>(2) Is it really a win to try and modify an existing app instead of writing the UI from scratch when the primary maintainers of the old application are not doing the heavy-lifting?</message>
<message time='20131209T21:50:32' id='rishi' name='rishi' token='' isuser='false' type='normal'>I think the answer is &quot;no&quot; and &quot;no&quot;.</message>
<message time='20131209T21:51:25' id='rishi' name='rishi' token='' isuser='false' type='normal'>That said, if cassidy or xclaesse or anyone is interested in turning Empathy into Chat, I will happily let them do it (and maybe delete or hand over gnome-chat.git to them) and carry on with life.</message>
<message time='20131209T21:51:50' id='rishi' name='rishi' token='' isuser='false' type='normal'>But honestly, the designs have been up there for a few years now, and no has really done anything with them.</message>
<message time='20131209T21:53:52' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>methinks it&apos;s a case of not lack of manpower/time on their end etc, just a wild guess; so you may be right in your approach</message>
<message time='20131209T21:55:05' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Don&apos;t get me wrong, I do not want to be antagonistic to the Empathy guys about this, even though I can see that it can be interpreted that way.</message>
<message time='20131209T21:55:20' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: And I do appreciate your interest / questions. :-)</message>
<message time='20131209T21:56:00' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Plus, I was under pressure from some quarters that we should dump TP as a whole and jump to libpurple or pidgin because our IM experience sucked so bad.</message>
<message time='20131209T21:56:10' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>you could say my questioning was along the lines of a sanity check</message>
<message time='20131209T21:56:19' id='rishi' name='rishi' token='' isuser='false' type='normal'>Sure, I get that. :-)</message>
<message time='20131209T21:57:12' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>I&apos;m not sure what to think about telepathy vs libpurple after all these years indeed</message>
<message time='20131209T21:57:30' id='rishi' name='rishi' token='' isuser='false' type='normal'>Obviously I do not agree with that, but just giving you the context. :-)</message>
<message time='20131209T21:57:47' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: And at that time TP was a bit neglected due to the maintainers being busy with other things. So there was that.</message>
<message time='20131209T21:58:53' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: I did talk to ramcq about this at that time in private.</message>
<message time='20131209T21:59:16' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>I mean I know nothing at all about libpurple&apos;s technical quality (vs telepathy), community and development processes, potential etc.</message>
<message time='20131209T21:59:43' id='rishi' name='rishi' token='' isuser='false' type='normal'>Because I did not want to put my neck on the line by supporting TP, and then see its maintainers abandon it.</message>
<message time='20131209T21:59:44' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>(and I don&apos;t know much about telepathy beyond the user-visible surface)</message>
<message time='20131209T22:00:03' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Well, TP has its issues but I do not think libpurple will magically solve everything.</message>
<message time='20131209T22:00:14' id='rishi' name='rishi' token='' isuser='false' type='normal'>It is mostly a matter of grass being greener on the other side.</message>
<message time='20131209T22:00:41' id='rishi' name='rishi' token='' isuser='false' type='normal'>Also, I do not want to work with an upstream (read &quot;pidgin&quot;) who are clearly hostile to GNOME.</message>
<message time='20131209T22:01:43' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>are they? guess I haven&apos;t gone anywhere near gaim/pidgin for the past decade (gosh...)</message>
<message time='20131209T22:02:00' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Well, pidgin is GTK2 last time I checked.</message>
<message time='20131209T22:02:35' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>but yeah I agree with the general sentiment of &quot;dumping telepathy in favor of libpurple is probably just swapping a set of technical issues for another&quot;</message>
<message time='20131209T22:02:56' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: Plus I spent a lot of time with barisione and aday integrating TP with GOA.</message>
<message time='20131209T22:02:57' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, so, I have no idea how XWayland was working before</message>
<message time='20131209T22:03:38' id='jasper' name='Jasper' token='' isuser='false' type='normal'>rtcm, one of the random restrictions it has is that the window must be redirected before mapping, and I can&apos;t see any path we would have done that on...</message>
<message time='20131209T22:06:06' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: But anyway, unless cassidy or xclaesse is not doing the heavylifting, I do not see how changing empathy into gnome-chat (or shotwell -&gt; gnome-photos) would be any better than writing a new app.</message>
<message time='20131209T22:06:47' id='rishi' name='rishi' token='' isuser='false' type='normal'>I mean it is basically the UI code that we are talking about. All the underlying layers -- folks, TP, etc. are the same.</message>
<message time='20131209T22:07:16' id='rishi' name='rishi' token='' isuser='false' type='normal'>And I *really* do not want to deal with the shitstorm -- &quot;empathy could do this,  gnome-chat can not&quot;.</message>
<message time='20131209T22:07:30' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>rishi, I&apos;m just used to the &quot;you&apos;re going to hit problems that were previously solved&quot; mentality, which I know can be wrong :)</message>
<message time='20131209T22:07:39' id='rishi' name='rishi' token='' isuser='false' type='normal'>I would rather sit in a corner writing my crappy new app in silence than dealing with that madness.</message>
<message time='20131209T22:07:46' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>I see what you mean</message>
<message time='20131209T22:08:15' id='rishi' name='rishi' token='' isuser='false' type='normal'>Well, that can be solved under the cover by copying code from empathy.git to gnome-chat.git.</message>
<message time='20131209T22:08:39' id='rishi' name='rishi' token='' isuser='false' type='normal'>Plus it is the same toolkit, same protocol implementation, etc.. :)</message>
<message time='20131209T22:09:18' id='rishi' name='rishi' token='' isuser='false' type='normal'>Ofcourse this is under the assumption cassidy or xclaesse do not have time for Chat.</message>
<message time='20131209T22:09:34' id='rishi' name='rishi' token='' isuser='false' type='normal'>Everything changes if they want to do the heavy-lifting.</message>
<message time='20131209T22:11:00' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: And I did talk about this with ramcq in private, as I said before. But I am not sure how much of that conversation he shared with the Empathy folks.</message>
<message time='20131209T22:11:38' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>if I get a chance to grab em for a discussion I&apos;ll see where they stand on that, in the meantime and until proven otherwise I think you are making correct/safe assumptions</message>
<message time='20131209T22:12:31' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: I came to learn that cassidy was a bit sad that I did not consult him.</message>
<message time='20131209T22:12:46' id='rishi' name='rishi' token='' isuser='false' type='normal'>nekohayo: I had assumed that ramcq had spoken to him in some sense.</message>
<message time='20131209T22:12:55' id='rishi' name='rishi' token='' isuser='false' type='normal'>I guess it was just miscommunication.</message>
<message time='20131209T22:12:56' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>well</message>
<message time='20131209T22:13:00' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>maybe they were both using Empathy</message>
<message time='20131209T22:13:03' id='nekohayo' name='nekohayo' token='' isuser='false' type='action'>ducks</message>
<message time='20131209T22:13:10' id='rishi' name='rishi' token='' isuser='false' type='normal'>:)</message>
<message time='20131209T22:13:44' id='rishi' name='rishi' token='' isuser='false' type='normal'>But then, as you can see, gnome-chat is a bit of a side project and I have my hands full with something else at the moment.</message>
<message time='20131209T22:13:58' id='rishi' name='rishi' token='' isuser='false' type='normal'>So if someone wants to do it, I am happy to let them.</message>
<message time='20131209T22:14:24' id='rishi' name='rishi' token='' isuser='false' type='normal'>But then it has been a few years that we have waiting for Chat, so unless someone else steps up, I will continue to hack it in my spare time.</message>
<message time='20131209T22:14:33' id='rishi' name='rishi' token='' isuser='false' type='normal'>*waited</message>
<message time='20131209T22:15:30' id='nekohayo' name='nekohayo' token='' isuser='false' type='normal'>that famous moment where you think &quot;how hard can it be really?&quot; :P</message>
<message time='20131209T22:15:41' id='rishi' name='rishi' token='' isuser='false' type='normal'>:-)</message>
</log>
