Some notes from smspillaz on how it might be implemented, for whoever (not smspillaz) would be doing the implementation: 12:33:10 How possible would it be for compiz (or possibly something else in the graphics stack) to keep a picture of an app's window around for a bit after that app crashes? 12:33:35 perfectly possible 12:33:55 well, compiz would be able to 12:34:15 it just might get a bit weird though because you're managing a window that doesn't exist 12:34:19 so, if an app crashes (and thus the process exits), compiz could continue to show its window as though it had not crashed (although obviously that window would not be interactive) 12:34:24 so I can forsee running into lots of really small problems 12:34:38 yeah, this is why I'm asking you about it :0 12:34:42 I had this idea, you see: 12:34:43 it would be able to show its window, I don't think we'd be able to handle things like raising it and lowering it from it scurrent position in the stack sanely 12:34:56 it would have to stay at the top 12:35:02 when an app crashes, apport kicks in and five seconds later you get the apport crash dialog 12:35:37 what I'd *like* to happen is that an app crashes, its window goes grey (or maybe, I don't know, red or something) and then apport draws the crash dialog into the crashed window 12:35:54 oh ok, the drawing into the crashed window bit is where you're going to run into trouble 12:36:11 so the crash dialog isn't saying "that app that was running five seconds ago crashed", and it's not even saying "that app over there crashed", it's saying "this app right here crashed". 12:36:22 right I see what you mean 12:36:57 you'd have to have some kind of apport plugin for compiz to handle that case though 12:37:07 I had this thought: app crashes, compiz says "aha, a crashed app, I will continue to display its window for a bit", apport starts up, apport creates its *own* window at the same size and position, compiz says "here is the texture from the crashed app", apport displays that, compiz forgets about the texture 12:37:33 so there's a brief time window (in between app segv and apport creating a window) in whcih compiz is managing a window for no app, but it's short 12:37:47 and then after that it's all apport and compiz can forget about it 12:37:58 right, so its doable but there are three parts about this that are decidedly nontrivial 12:39:18 okay so the first one is that there's a race between getting the notification that the application crashed as opposed to the window recieving a DestroyNotify from the server 12:39:31 if the latter happens first compiz will just play the close animation 12:39:49 we'd need some kind of synchronization there 12:40:14 the server doesn't tell you why a window was destroyed 12:40:19 it just tells you that its destroyed 12:41:15 I mean what you could do 12:42:00 is have a plugin that specifically inhibits all close animations until we check with apport as to why the window was destroyed, and hopefully by then it would have known by way of kernel events why the application died 12:42:17 this of course requires matching process ID's to windows which is another whole can of worms 12:42:32 because there's no facility for doing that in the protocol 12:42:52 so you'd only get it from applications that are EWMH compliant (which is probably about 99%) 12:44:51 although most applications will export that data on their windows now 12:45:33 problem 2 is "keeping the window around" - you can keep the window around, but its difficult to do so in a sane manner unless you want more stacking bugs 12:46:05 you have the same problem when animating out minimized and closed windows, we "estimate" where they need to go in the stack and put them there when painting them 12:46:16 but you can't for example raise or lower a destroyed or unmapped window 12:46:36 so you'd get some weirdness there but hopefully it won't be too long 12:46:37 because compiz doesn't actually raise and lower things, it just passes on mouse clicks and then the app itself says "raise me" and compiz responds... but now there's no app to receive the clicks? 12:46:50 actually compiz raises and lowers things server side 12:47:11 it captures the click on the window and then issues the raise request (which is how you're supposed to do it) 12:47:30 yeah, having a window unable to change its position in the stack would be odd and weird, but ideally it would be seconds at most before apport appears and the "fake window" becomes a real proper window again 12:48:29 I suppose what we could do is throw up an input only window when we know the actual application is dead and paint the "crashed" window in the same part of the stack as the input only window 12:48:42 or a real window at that 12:48:48 there are ways to handle this case 12:48:56 its just tricky 12:49:08 and then I guess the third is getting the window texture into apport 12:49:40 the important part is that the window doesn't disappear and then reappear a second later; it just greys out. Whether that's actually because the same window hangs around or because a new window is created which looks identical and is atomically swapped for the previous one doesn't matter, of course 12:51:12 I think you could probably grab the window texture, given that most texture from pixmap implementations involve a copy from pixmap memory to texture memory 12:51:19 it would just be hard