! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
mousepad: add session integration to handle unsaved documents
Status:
RESOLVED: DUPLICATE
Severity:
enhancement
Product:
Mousepad
Component:
General

Comments

Description Ikonta 2015-11-10 15:06:06 CET
Not long ago, trying to turn off my Linux box with paused games-puzzle/gottet I find poweroff request ignored until game was resumed.

But mousepad, together with almost all applications doesn't care about unsaved user's data.
That it not right.

I suggest to create optional session integration, in XFce starting with mousepad text editor.
If built without this option, mousepad should just show hardcodedly off option named like "handle document state".
When built with session support, this option should became available for user changes with default "on" and, after receiving poweroff command with unsaved text file, it should prevent system from it's handling before document would be saved or reset by user.

The only question is about the best way to do so.
games-puzzle/gottet echoes confirmation window on the same workspace with main one. That is not clear when sending poweroff command from another workspace.
Maybe it will be better to extend xfce-extra/xfce4-taskmanager, invoking it on active workspace with ordered by application list of unsaved documents?

P.S. I've seen bug #5401, but it is about another question.
Comment 1 Dimitar Zhekov 2015-11-10 19:28:24 CET
Mousepad (and the other xfce programs) have some session integration, though it may be incomplete, as in bug #5401.

But what you describe can not happen. No program has the right to *prevent* a shutdown forever. What if the computer needs to stop because the UPS is depleted, or due to some hardware error? A Mousepad will prevent it from shutting down gracefully?

The session managers usually have a period, for example 1 minute, in which the user must answer all interactive questions about unsaved files, or cancel the shutdown. IIRC, it was actually more complex: the first phase handles interactivity, after that the shutdown becomes unstoppable, and all session-aware programs are notified that they now have a few seconds for any final thoughts.

(It's not necessarily a shutdown - may be a logout or restart.)
Comment 2 Ikonta 2015-11-11 15:50:59 CET
(In reply to Dimitar Zhekov from comment #1)
> But what you describe can not happen. No program has the right to *prevent*
> a shutdown forever. What if the computer needs to stop because the UPS is
> depleted, or due to some hardware error? A Mousepad will prevent it from
> shutting down gracefully?
But it happens.
Although I'll re-check games-puzzle/gottet and I agree with you: this result is the thing that should not be.
The actual result means something wrong or missed in xfce-base/xfce4-session.
After confirmation I'll report it.

> The session managers usually have a period, for example 1 minute, in which
> the user must answer all interactive questions about unsaved files, or
> cancel the shutdown. IIRC, it was actually more complex: the first phase
> handles interactivity, after that the shutdown becomes unstoppable, and all
> session-aware programs are notified that they now have a few seconds for any
> final thoughts.
> 
> (It's not necessarily a shutdown - may be a logout or restart.)

My initial idea was just incomplete:
The initial check period, when nothing is stopped, session manager just checks readiness to stop without data loss. At this time applications should ask user about unsaved documents and user should either save, or cancel them. The timeout value should be changeable in session's settings in some reasonable range (for example for 20 seconds up to 4 minutes), allowing cancel shutdown request.
If nothing to do (no unsaved documents), this phase should be passed immediately, without any delay.
After handling all unsaved documents or on timeout shutdown should became unstoppable as it works now.

P.S. Maybe, in similiar way with unsaved documents we should handle some other user's tasks, for example, opened ssh sessions.
Comment 3 Dimitar Zhekov 2015-11-11 20:16:00 CET
(In reply to Ikonta from comment #2)
> (In reply to Dimitar Zhekov from comment #1)
> > But what you describe can not happen. No program has the right to *prevent*
>
> But it happens.

I used a wrong expression, sorry. The situation you described can of course happen. It is the option you described:

> If built without this option, mousepad should just show
> hardcodedly off option named like "handle document state".
> [...]

that can not be implemented, because it's not part of the XSMP standard. Xfce does not have any authority to change the standard, and a xfce-specific option will not be supported by any developers.

> The initial check period, when nothing is stopped, session manager just
> checks readiness to stop without data loss.
> At this time applications should ask user about unsaved documents and
> user should either save, or cancel them.

It does that already, but many applications are not session-compliant.

> The timeout value should be changeable in session's settings in some
> reasonable range (for example for 20 seconds up to 4 minutes), allowing
> cancel shutdown request.

If I remember correctly, xfce used a fixed period of about 30 seconds.
Making the period configurable is certainly a good idea, and should not be hard to implement.

> If nothing to do (no unsaved documents), this phase should be passed
> immediately, without any delay.

The applications may be unable to respond immediately. For example, if an application is in a File Open dialog, it may receive the save-yourself request after the dialog is closed - and when that happens depends by the user. It may be better for xfce to wait the entire period - just to be sure.

Note that I'm not a xfce developer (only helped a few times), and am not even using xfce any more. So you'd better check what the current 4.12 version does, and clarify your suggestion if needed.
Comment 4 Ikonta 2015-11-16 15:20:07 CET
(In reply to Dimitar Zhekov from comment #3)
> The situation you described can of course happen.
I've re-checked.
It really happens. paused gottet completely interrupts poweroff process.
And this probably is a bug of xfce-base/xfce4-session

> It is the option you described:
> 
> > If built without this option, mousepad should just show
> > hardcodedly off option named like "handle document state".
> > [...]
> 
> that can not be implemented, because it's not part of the XSMP standard.
So, I first should ask about extension of standard?

> > The initial check period, when nothing is stopped, session manager just
> > checks readiness to stop without data loss.
> > At this time applications should ask user about unsaved documents and
> > user should either save, or cancel them.
> It does that already, but many applications are not session-compliant.
Or it already could be done on application-side?

> > The timeout value should be changeable in session's settings in some
> > reasonable range (for example for 20 seconds up to 4 minutes), allowing
> > cancel shutdown request.
> If I remember correctly, xfce used a fixed period of about 30 seconds.
> Making the period configurable is certainly a good idea, and should not be
> hard to implement.
This should be splitted into separate Feature Request, or mentioning in this bug is enough?


> Note that I'm not a xfce developer (only helped a few times), and am not
> even using xfce any more. So you'd better check what the current 4.12
> version does, and clarify your suggestion if needed.
I already use xfce-base/xfce4-meta-4.12.
And can guess, that you isn't active xfce developer ☺
Comment 5 Theo Linkspfeifer editbugs 2020-05-22 14:20:55 CEST
Closing in favor of bug 15956.

*** This bug has been marked as a duplicate of bug 15956 ***

Bug #12300

Reported by:
Ikonta
Reported on: 2015-11-10
Last modified on: 2020-05-22

People

Assignee:
Matthew Brush
CC List:
2 users

Version

Version:
Unspecified
Target Milestone:
Mousepad 0.2.x

Attachments

Additional information