Of course we can't actually undo closing a window, so this would have to actually be implemented as "just hide the window when the user clicks (X), and then actually close it when leaving the overview". But then if the app puts up a confirmation dialog before closing, we'd get that when leaving the overview rather than when closing the window. There's no way we can know if it's going to put up a confirmation window without actually trying to close the window, and if we close it and the app doesn't put up a confirmation window, then there's no way to get it back...

Also, why only in the overview? Users will most likely close more windows outside the overview than in, so...

(In reply to comment #1)
> Of course we can't actually undo closing a window, so this would have to
> actually be implemented as "just hide the window when the user clicks (X), and
> then actually close it when leaving the overview".

Alternatively, we can close the window and relaunch the app in the hope that we end up "close enough". I'll attach a patch, but for that feature to be useful, it has to work properly in slightly more than (estimated) 2% ...

Created attachment 153007 [details] [review]
[Overview] Add undo support for closing windows

Add an undo option to the info bar when closing windows in the overview.
Due to the lack of an actual "unclose" operation, the corresponding
application is relaunched, in the hope that it will behave sanely.

Note that I am not at all sure whether it's a good idea to do this - rationale follows - so at least for the time being the patch is intended for discussion only.


(In reply to comment #0)
> One of the more potentially destructive actions in the overview is the ability
> to close a window directly using the "x" button overlay in the window picker.

Yeah, "potentially destructive" is dead-on. Fortunately, most users should be aware of that ...


> We can't really be responsible for application data because one of the
> following should occur:
>  a) the application should automatically save its state
>  b) it should prompt for confirmation on close
> 
> But even in these cases (particularly a) we should try to offer the option to
> undo closing a window.

Sure, we can _try_ to offer an undo option - question is: Is that good enough? While b) should be pretty much a given when closing would result in "real" data loss, I'd consider a) a rare exception - quite frankly, Firefox apart, I can't think of any application doing it (and in the case of Firefox, it will only work for the _last_ window). So, will we really help users by replacing a "potentially destructive action" with a "potentially destructive action which may possibly be undone, but then, maybe not"?

For most applications it might not even make sense to save/restore state unconditionally. Obviously, some improvements are possible - we might e.g.:

- include the actual command line in the app info of running applications
- extend desktop files with a restore key
- make it easy for apps to support some standard --restore option
- resolve bug 79285 (ha ha ha, just serious)

In my opinion, right now the feature does more harm than good - if we cannot get it to work in significantly more cases, it'd be better to skip it altogether.

I think if an undo option is there, it should be reliable. Having an unreliable undo a) makes the system look flimsy b) if the user gets used to undo'ing app close, because it does work, and then it doesn't that could be frustrating.

Also we are talking window close not app quit. I think ideally we'd expect that Quit should be a strict inverse to launching the app. But closing a window is mot quitting the app.

Basically, this is not going to work reliably in any forseeable timeframe, and I wouldn't even have a recommendation to somebody about how to go about working on a reliable way of implementing this in a reliable fashion. You can say "create a protocol with applications to implement this feature and modify all applications", but that's a lot of work for everybody, and a lot of extra burden on application maintainers.

I'm going to close this, alternatively we could create a "Blue sky" milestone for stuff we'd like to work but don't have have an immediate direction on.

(In reply to comment #4)
> I'm going to close this, alternatively we could create a "Blue sky" milestone
> for stuff we'd like to work but don't have have an immediate direction on.

Fine.  Let's do that then.  This is something we want to continue to discuss I think.  It is pretty easy to slip and accidentally close a window there.  Even if we only describe what happened in an infobar that is something.  Better than just poof.

(In reply to comment #5)
> (In reply to comment #4)
> > I'm going to close this, alternatively we could create a "Blue sky" milestone
> > for stuff we'd like to work but don't have have an immediate direction on.
> 
> Fine.  Let's do that then.  This is something we want to continue to discuss I
> think.  It is pretty easy to slip and accidentally close a window there.  Even
> if we only describe what happened in an infobar that is something.  Better than
> just poof.

Is this something you did? I don't think I've come close to hitting the (x) in the overview on accident.

Notification in the info bar that a window was closed is very different in terms of difficulty of implementation than undo; that should be feasible if it's something we want. (It's not entirely trivial, since you don't want to do it when the user hits the X, you want to remember that the user hit the X, and then if window is closed within a short period of time, and the notification. Doing it when the user hits the X will make things confusing with confirmation dialogs.)

Let's not focus too much on a strict definition of undo.  However, I do think that we can actually do that if we really want to.  We also can detect if the window close resulted in the application quitting and offer to relaunch the app.

It has only happened once and it was because I was being sloppy with mousing and the close button came up under my mouse.  I think eventually I'd like to experiment with using click and drag to slide the workspaces and that complicates things a bit.  Even if we don't do that new feature - we do have two unrelated functions in nearly the same place here and that certainly increases the probability of slipping.  Also I'm expecting that use on touch screens will also raise the probability of these types of slips.

I don't think this is a high priority right now or anything.  I should probably come up with a more concrete proposal.

(In reply to comment #6)
> It's not entirely trivial, since you don't want to do
> it when the user hits the X, you want to remember that the user hit the X, and
> then if window is closed within a short period of time, and the notification.

IMHO that part is handled reasonably well by the patch, it's the "undo" which will probably never work properly. Displaying the message alone, while feasible, does not make too much sense though - either the user actually wanted to close the window, or the message adds insult to injury ...


(In reply to comment #7)
> We also can detect if the window close resulted in the application quitting 
> and offer to relaunch the app.

That sounds much more realistic - relaunch does not imply recovering a previous state more or less exactly as undo does.

Comment on attachment 153007 [details] [review]
[Overview] Add undo support for closing windows

Marking rejected based on comment 4

(In reply to comment #8)
> (In reply to comment #6)
> > It's not entirely trivial, since you don't want to do
> > it when the user hits the X, you want to remember that the user hit the X, and
> > then if window is closed within a short period of time, and the notification.
> 
> IMHO that part is handled reasonably well by the patch, it's the "undo" which
> will probably never work properly. Displaying the message alone, while
> feasible, does not make too much sense though - either the user actually wanted
> to close the window, or the message adds insult to injury ...

I agree with that.
 
> (In reply to comment #7)
> > We also can detect if the window close resulted in the application quitting 
> > and offer to relaunch the app.
> 
> That sounds much more realistic - relaunch does not imply recovering a previous
> state more or less exactly as undo does.

Do we want to do that short term?

Interesting idea here, but it's an old bug and I don't see it doing anything useful. Marking as needinfo, in case someone wants to take it up. Otherwise we should probably close it.

Can we have a RESOLVED: ITSCOMPLIATED status?