Bug 267356 - Kate closes without asking, losing session
Summary: Kate closes without asking, losing session
Status: RESOLVED DUPLICATE of bug 165035
Alias: None
Product: kate
Classification: Applications
Component: sessions (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-01 02:23 UTC by SasQ
Modified: 2011-06-13 13:02 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SasQ 2011-03-01 02:23:36 UTC
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

When clicking the main close ("X") button on the title bar, Kate doesn't ask what to do with opened files, but closes immediately.
After opening some other file, the list of previously opened files is lost. I have to reopen them all manually.

Reproducible: Always

Steps to Reproduce:
1. Open a bunch of files in one session.
2. Click the main close button ("x") on the title bar.
Application closes without asking what to do with opened files.
3. Open some file with Kate (by double-clicking the file to open it in Kate by file associations, or in some other way).
You'll see only that one file in the list. All previously opened files are lost from the list. You have to reopen them manually.

Actual Results:  
Application closes without asking what to do with opened files.
After opening some other file, you'll see only that one file in the list. All previously opened files are lost from the list. You have to reopen them manually.

Expected Results:  
When clicking the close button ("x") on the title bar, Kate should ask what to do with opened files. Even if they're all saved to disk. It shouldn't allow to loose the list of opened files but store them in the session.
Comment 1 Pedro Morgan 2011-03-14 00:19:36 UTC
I've been caught out with this one a few times so would be high on my priority list.
Comment 2 xejakig884 2011-04-17 13:45:39 UTC
Using Kubuntu 11.04 (KDE4.62) I can't confirm this.

I started editing five files and tried to close kate using the close button. I was prompted to save them. Repeatable three times.
Comment 3 Dominik Haumann 2011-04-19 17:33:56 UTC
If you want your session to be restored, please save it explicitely. Otherwise the list of opened files in the "unnamed" session gets longer and longer over time, which obviously isn't optimal either.

Asking every time blocks the user in the work flow whenever he uses Kate.
Comment 4 Pedro Morgan 2011-04-19 19:38:34 UTC
I love you view Dominik.. Three users here find it a problem.. and you say "stuff it.. I dont like the idea".

Well thank you ;-(
Comment 5 SasQ 2011-04-19 20:10:38 UTC
(In reply to comment #3)
> If you want your session to be restored, please save it explicitely.

It's just like saying:
"If you want your text to be restored next time, please save the file explicitely." List of opened files in the session is user's data, just like the data he typed in in an empty file. Users HATE to loose their data, you know. When I, as a user, have some opened files, NO MATTER IF SESSION WAS ALREADY SAVED AND NAMED, and I click the close button of the main window, I expect from a properly-written program to at least ASK ME what to do with these data (unnamed list of opened files) instead of simply LOSING it.

> Otherwise the list of opened files in the "unnamed" session gets longer
> and longer over time, which obviously isn't optimal either.

No, if the user will close some of them next time.
In my opinion, the unnamed list of opened files should be treated in the same manner as unnamed text file. It won't be "getting longer and longer over time", because the user has two options:
1. SAVE this session under some name he likes (so it won't be "unnamed" any longer).
2. Drop this list at all and forget it.
In both cases the list isn't growing as "unnamed".

> Asking every time blocks the user in the work flow whenever he uses Kate.

With all due respect, what workflow are you talking when the user closes the application? It's the end of any workflow with Kate however.
Comment 6 Pedro Morgan 2011-04-28 02:00:17 UTC
Thanks SasQ.. it makes complete sense.. I agree that my comment was over reacted to IT not being solved yet..

I Would at least ask Dominik to Point me in "where the problem is" as its clearly one he/she does not:
1) understand or
2) How to solve
3) I want to colve the problem.. its pretty simple it just will take time..

A few hints would be accepted so I as A NON c++ coder can learn a little bit to try and solve..


BTW  dominik..Dont wipe out a request.. unless u experience IT.. so go and humble yourself.. ok./. I still love u ..But if your solved IT.. So tell me where to go for..
Comment 7 Dominik Haumann 2011-04-28 09:04:14 UTC
What about an option in the sessions config page
[ ] Restore document list when not using a session on startup
Comment 8 SasQ 2011-04-28 10:45:46 UTC
(In reply to comment #7)
> What about an option in the sessions config page
> [ ] Restore document list when not using a session on startup

Why NOT the way I described earlier in comment #5?
Let the user decide on close what to do with the CURRENT session. It gives more freedom than deciding once for ALL sessions in general. Some of them she would like to save and name, some of them she won't.
Comment 9 Tomas Trnka 2011-04-28 11:12:31 UTC
(In reply to comment #8)
> Why NOT the way I described earlier in comment #5?
> Let the user decide on close what to do with the CURRENT session. It gives more
> freedom than deciding once for ALL sessions in general. Some of them she would
> like to save and name, some of them she won't.

I would personally hate a blocking (modal) dialog asking what to do with an unnamed session on close (and I imagine the majority of Kate users having the same opinion, given only two users complained through the whole KDE 4 era). Not having a named session opens means the user doesn't care much about what happens with the settings (e.g. when using Kate for one-shot editing via "kate somerandomscript.sh", users probably do not even know that there's some session stuff behind).

And having to click "Do not save" explicitly on every Kate shutdown (that includes every logout or system shutdown!) is going to drive the users insane! (It's OK to block the logout because of an unsaved ten-page document, but it's certainly not OK to do that just because of the unnamed session thing - if it was important, the user would have saved it explicitly).

This problem you're describing has a simple workaround, too: Just create a session "my default session" and use it for all the random files :-)

Either way, this is certainly not a "severity:major" bug. "Major" means "important functionality is unusable" and that's not the case here. This bug screams "wishlist" all over the place instead.
Comment 10 SasQ 2011-04-28 12:20:04 UTC
> and I imagine the majority of Kate users having the
same opinion
I'd rather ask the users than imagine what they could want.

> Not having a named session opens means the user doesn't care much about what
happens with the settings
No. It means only that he didn't savet it. It could mean that he forgot to save, or didn't save yet equally well.
Please don't speculate unless you're a clairvoyant or mind reader.

> And having to click "Do not save" explicitly on every Kate shutdown (that
includes every logout or system shutdown!) is going to drive the users insane!
Oh really? I hadn't seen so far any user driven insane by asking him/her to save her precious data. But I saw them very insane when they loose their data.
Your argumentation should equally well be applied to saving unnamed file. You can clearly see that it don't.

Why not to copy a very good sample of how web browsers do that with their sessions of open tabs? Take look on Firefox or Opera how they store their sessions. They don't loose user's data (opened tabs). As far as I remember, Firefox even ask the user if she wants to restore her tabs next time he opens the browser.

As to the "severity:major": For me it's major bug when I lose my data.
Comment 11 Erlend Hamberg 2011-04-28 13:53:56 UTC
I agree with Thomas: I would find a modal dialogue at exit very annoying.

So, the bottom line is: no solution will make everyone happy, and the hyperbole here is just muddling the discussion.

Dominik's suggestion was very reasonable and will allow users to never lose their session. But quite frankly: if your usage pattern includes opening the same [sets of] files often, you should consider using explicit sessions.

Perhaps the options should be

☐ Ask if session should be saved at exit if the list of files is changed

or something?

And, SasQ: Please, try to keep a friendly and neutral tone. Your suggestion may very well be valid, but screaming and using hyperbole is not helping. It only results in that people want to avoid the discussion.
Comment 12 SasQ 2011-04-28 14:33:31 UTC
Don't confuse disagreement with unfriendly or non-neutral tone. I thought I'm simply giving you logical arguments and it's strange that you are taking them to yourselves as personal. Sounds like some Ego stuff is going on here.

It's your arguments which are "personal", because you're talking about your opinions and personal beliefs about user experience, ignoring the user's experience just described by me (I'm a user). Remember that you don't write this app solely for yourselves and only yourselves. There are users out there, losing their data.

If you worry more about users annoyed by some modal dialog at closing than annoyed users by data loss, then I gave you many examples where sessions are dealt with better, without annoying users. Firefox & Opera do it very well with their tabs; I've never lost any tab in these apps and nothing annoyed me in their session management, so I think it's a good source to learn usability from. It's not necessary to reinvent the wheel or inventing some strange configuration options. It's all there.
Comment 13 Pedro Morgan 2011-04-28 18:57:29 UTC
I am 200% with SasQ and he has explained the problem very well.

It REALLY annoying when kate closed and I have a named session open and it does not save or prompt me on exit.

Indeed if it just periodically saved the session would be useful as kate crashes sometimes.!!

Also Erlend.. I didn't read SasQ's tone as unfriendly.. indeed I think others users attitude of simply avoiding the issue is much more unfriendly, including yours imho.
Comment 14 Dominik Haumann 2011-04-28 22:16:30 UTC
I think there is not much to discuss here. The arguments for this wish were given, although I (still) don't really agree. If you are NOT using sessions, why should Kate ask what to do? Anyway. We can add an option like I proposed. We can ask at the first exit and ask the user what to do (along with a "don't ask again" checkbox).

Tomas and Erlend provided very good arguments as well. And I (personally) very much agree with what Tomas said in comment #9.

Usually I try to stay calm on the matters of bashing in bug reports. But still, I'd like to point out that it's sometimes not easy to interpret what's written in reports. In this context, I'm talking about
> I love you view Dominik.. Three users here find it a problem..
> and you say "stuff it.. I dont like the idea". Well thank you ;-(
Is this sarcasm? To be honest, I don't know what to make of this.
First, SasQ and you see a problem. Paul in comment #2 does NOT confirm this issue (read carefully). So it's just 2 users. Further, I NEVER said stuff like what you said I did. This is probably exactly what Erlend meant by "keeping a friendly and neutral tone".
Comment 15 SasQ 2011-04-28 23:05:48 UTC
> We can ask at the first exit and ask the user what to do
> (along with a "don't ask again" checkbox).
This kind of checkboxes can cause problems with usability when user forget that long time ago he checked that checkbox. So it's a form of sweeping under the rug, because the problem will emerge sooner or later again in the same form: loosing session data. The only winner is the developer, who now can tell the user: "You've got what you've asked for".
And even when the user will remember himself that he asked for not showing the dialog box again, now he don't know how to restore this dialog back, since it's hidden. And the option to restore it back is at a whole different place.

I think that someone familiar with usability patterns should take a look on this problem and give some advices if the ones I gave previously (especialy those session-storing patterns from Opera & Firefox) are not enough for you.
Comment 16 Petr Viktorin 2011-04-29 00:14:31 UTC
While I certainly don't agree with SasQ's tone, I think the report is a valid one.

> Otherwise the list of opened files in the "unnamed" session gets longer
> and longer over time, which obviously isn't optimal either.

With “Close All” in the menu, this is not really an issue.

Personally, I always use named sessions. I haven't thought about it lately, but I probably started doing this a few years back because of this issue.
I clear my default session when it grows too much; I don't have any problems with it.

Saving the session continuously, so it survives power outages/X meltdowns/Kate crashes, is a particularly good idea. It would be especially useful for named sessions. And it probably deserves its own bug.
Comment 17 Kevin Adler 2011-04-29 00:16:45 UTC
(In reply to comment #15)
> > We can ask at the first exit and ask the user what to do
> > (along with a "don't ask again" checkbox).
> This kind of checkboxes can cause problems with usability when user forget that
> long time ago he checked that checkbox. 

The Firefox example refutes some of your objections to Dominik's solution. In
Firefox, by default it will ask you if you if you would like to save the list
of tabs and open it next time, with a check box to remember your answer. When
doing this modifies two options in the config:
- Sets "When Firefox starts" to "Show my windows and tabs from last time"
- Unchecks "Warn me when closing multiple tabs"

This seems to be similar to what Dominik is suggesting.

Personally, just as in Tomas's case, I'd be annoyed by the behavior you are
requesting (but would be OK with Dominik's comprimise). 

One thing that would be good to copy from Firefox is to automatically open
previously opened files in the event of a crash, but should probably get a
separate wish item.
Comment 18 SasQ 2011-04-29 00:59:22 UTC
> The Firefox example refutes some of your objections to Dominik's solution.
That's why I wrote that it "can" cause problems.
The Firefox example is not the best, but better than losing data and quite well resolved. The example of Opera might be better here - it stores the recently opened tabs by default, and additionaly allows to save it under a name. It starts with a dialog which allow to choose from saved sessions, last session or blank session.

And what about somehow reusing the dialog which appears for changed files? But instead of saying "This is a list of files which changed", it could say: "This is a list of files which has been opened previously. Do you want to restore them or use a fresh session?" - a message appearing when starting Kate.

This way when a user will close Kate, he won't be "annoyed" by asking whether to save the session. The window will simply close. But the session will be stored temporarily for the next time.
When the user will open Kate again, the dialog mentioned could appear if there were any files in the previous session. And the user could be able to decide if he want to restore it or drop it an get a fresh one.

But the worst scenario [the one which bring me to this bug] is when the user opens some file by clicking on its icon and Kate is starting in result. Because then he most probably wants to edit that file. So if there was any previous session, he shouldn't lost neither of them: neither the previous session nor the file he tries to open. That's why I think that it's better to save on close than trying to restore on next opening. The sooner the better.

I agree that there could be better options than this one. But I strongly disagree with any kind of losing data "just because" and throwing the fault to the user ("if he wanted his data safe, he should have to save them himself"), or unnecessarily limiting elasticity or specificity of user's choices.

As to my "tone": It's simply a tone of a free man who doesn't care about authorities. If something is not OK, I'm speaking about it freely because I think it's better to be specific than polite. My goal is not to fight with anyone's Ego, but to try to find a solution.
Comment 19 sml 2011-04-29 02:57:02 UTC
I really like the Firefox 4 solution to this issue: Silently save the session on exit, and when you restart the app just have a menu item in the Sessions menu called "Restore Previous Session".

This avoids any need for configuration or modal dialogue boxes and just does the right thing in the background without any user intervention.
Comment 20 Benny 2011-04-29 10:08:21 UTC
I use KDE for more than 10 years. I did not know kate had sessions. I have been thinking for the last year from time to time: I need to open a bug with kubuntu that kate has nothing in my 'Open recent files' list. 
I took the habit of never closing kate, so it opens up with my last used files. 

Conclusion: people _don't_ go hunt for features, people expect the program to work in the most optimal way. The most optimal way is opening my last used files, and have the recent file list always populated. Only when users want to use sessions should the other behavior kick in. Even then, there should be a _no_session_session, that keeps track of everything done outside of a session.

Disclaimer: I did not look yet at the session management in kate, and I don't care for a session management. I can remember everything I do and my sessions would become like my bookmarks: ununderstandable organization. So I just need a way to use kate nicely without sessions.
Comment 21 Sebastian Sauer 2011-04-29 12:48:06 UTC
I absolute agree with comment #19 .

Just save the session without reasking. Make it similar to Konqueror/Opera/Firefox's "Recently closed tabs" but s/tabs/sessions and then allow to either have them permanent (in the sessions-menu) or just throw them away after a while.

This way users are able to restore the last sessions even at a later time. They are not forced to decide yet if they may need the session later, they don't need to spend additional time clicking modal dialogs blocking there workflow away and still can do what this report asks for.
Comment 22 Malte Dik 2011-04-29 13:22:17 UTC
Current behavior is acceptable, menu-option for restoring sessions would be nice, just don't ask me (I'm even slightly annoyed when I doodle around and the app on closing asks me if I'd like to ask the doodle; why would I?).

Sasq, please calm down. We see why you're angry. It all happened to all of us more than once, but I really don't get why people don't learn to be more considerate and save their files/settings/sessions when they are important to them.
Comment 23 argonel 2011-04-30 03:00:35 UTC
I also agree with comment #19 - along with adding the "implicit" session to the session manager so that it can be selected on startup when "Manually choose a session" is enabled.
Comment 24 Pedro Morgan 2011-04-30 04:41:58 UTC
Can we try and deal with this logically, with some case examples..

1) I have just opened a file in kate.. its something , and I can close

In this instance not required is a Session, this is just a read cat command..
But if I change something, then kate will warn me about unsaved file, and thats probably mandatory.

2) its a project I just downloaded and I'm using kate to edit some configs, or an svn/git snap or anything..

In this case I want to use the "file browser" to navigate the project.. and a few files open.. and change I need to again agree to loose things.

3) Like above its a directory I'm navigating and I decide that .. wow.. I need to get onto this and hack..

At this point I will "create" a "Session".. ie where I can come back to later..

The idea of a Session is to maintain "state" where you were before.. the last time you were there..

A good example of this is a browser, which if it crashes, the modern ones at least give you and option to "recover" open pages.. indeed sometimes the ones you dont want.. or wanted is missing..

This is the "flaw" in kate, as what I wish is..

+) I am working in a session, and I want it to save all the state I am in currently.. now.. and come back here.. later.. tabs same color and order.

Ideally I want it to just "autosave" the current open files and window sizes..




Before I open the other one, which is a completely dirrerent session somewhere else, or even in the same "tree"..

In my work as a paid coder I use kate daily in all these modes and quirks. its still the best tool I found, after a lot of suffering with others and am thankful for that.
Comment 25 Pedro Morgan 2011-04-30 04:42:23 UTC
Can we try and deal with this logically, with some case examples..

1) I have just opened a file in kate.. its something , and I can close

In this instance not required is a Session, this is just a read cat command..
But if I change something, then kate will warn me about unsaved file, and thats probably mandatory.

2) its a project I just downloaded and I'm using kate to edit some configs, or an svn/git snap or anything..

In this case I want to use the "file browser" to navigate the project.. and a few files open.. and change I need to again agree to loose things.

3) Like above its a directory I'm navigating and I decide that .. wow.. I need to get onto this and hack..

At this point I will "create" a "Session".. ie where I can come back to later..

The idea of a Session is to maintain "state" where you were before.. the last time you were there..

A good example of this is a browser, which if it crashes, the modern ones at least give you and option to "recover" open pages.. indeed sometimes the ones you dont want.. or wanted is missing..

This is the "flaw" in kate, as what I wish is..

+) I am working in a session, and I want it to save all the state I am in currently.. now.. and come back here.. later.. tabs same color and order.

Ideally I want it to just "autosave" the current open files and window sizes..




Before I open the other one, which is a completely dirrerent session somewhere else, or even in the same "tree"..

In my work as a paid coder I use kate daily in all these modes and quirks. its still the best tool I found, after a lot of suffering with others and am thankful for that.
Comment 26 missive 2011-05-02 01:31:16 UTC
Related to (possibly duplicate of) Bug 165035.
Comment 27 werner 2011-05-03 09:23:06 UTC
Personally, I believe this report is more about default session creation that Kate's closing behaviour. Also let's not forget that, although everything is handled as sessions (either named, opened, or unnamed), some comments might actually refer to behaviour previously handled by our old friend, the "Recently Opened Files" (ROP) list.

If it was all up to me, I'd address the problem (from a pure UI perspective) in one of the following two ways:

1) Make ROP lists based on automatically-created sessions. Make these lists (sessions) multi-dimentional, indexed (session named) by date. E.g. the "File" > "Open Recent" menu has parent items, e.g. one such parent is titled "2011/04/03 09:09" which contains a submenu of all files opened that time. The first item in the child file list is titled "Open All Files". Settings determine how many automatic ROP entries are saved.

That way, you've got your temporary file lists covered without messing directly with sessions. Kinda. :)

Under the hood, these ROP lists are actually just be auto-named sessions (named according to date or whatever), so you can rename one of them to make it a "permanent session". 

To summarize, there could be these "User Defined" sessions on the one hand, and "Automatically Created" sessions on the other hand.

Doing things that way won't meddle with existing sessions and won't completely discard opened file lists if you want to access it later. The only "effort" you have to go to is to (re)name on of those auto-created-sessions if you want to make it permanent (to keep if from automatically being replaced by a more recent auto-session in future).

2) Learn from KDevelop's "Working Sets". 

Man... Working Sets are the coolest, most intuitive, most every-day-efficient thing I've ever seen in this regard, and I have fallen madly in love with it. 

The UI implementation of Working Sets gives it additional quality. I like the idea that random icons are used to "identify" sets, so you don't even need to name them. Zero effort. Brilliant! 

Using the browser tab "parable" mentioned in these comments, it's like having "tab groups" (now standard in Firefox 4) but you only see their icons.

Working sets are a-w-e-s-o-m-e, and should do well to solve many of the (potential!) problems mentioned here, with the (potential) effort of a single click. Single click = hit the "New" working set icon if you want to group all open files as a new Working set. (See KDevelop for a demo, lol). Actually it's a pity that Working Sets are (still) not nicely documented for Kdevelop (last time I checked).

Well, that's my 2 cents, either way you go, Kate is awesome anyways.
Comment 28 Kåre Särs 2011-05-18 08:35:42 UTC
Hi,

I have not read all of the latest post, but there is a simple way to get close to the wanted behavior of the original poster: "start kate with a dedicated default named session". This is done by adding "-s <session name>" to the command line. 

example:
kate -s myDefaultSession file_to_edit.txt

This will open file_to_edit.txt in the myDefaultSession session and that saves the opened files information on close. 

bash:
make an alias that appends the -s parameter to kate.

GUI (dolphin/konqueror):
Open "KDE Menu Editor"
add "-s myDefaultSession" to the command of Kate

If there could be an option to either open a default session or the unnamed session is another question. 

I would definitely be annoyed by having to click trough an extra dialog every time I close kate after just peeking in a file or two.

/Kåre
Comment 29 Dominik Haumann 2011-06-13 13:02:56 UTC

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