Version: (using KDE 4.2.0) Installed from: SuSE RPMs "Open recent (document)" menu it for opening recently edited documents, it is not for showing currently opened documents. For that purpose Kate already has other means. In other words: this menu should list opened & closed documents, if the document is currently edited (opened) it should be ruled out of that list (and there are good reasons for that, I skip this, because they are quite obvious, if there is any doubt, I'll explain). "Open recent" != "recently opened". How to reproduce this bug: * start fresh kate * check the "open recent" menu -- it should be empty * open any document * check the "open recent" menu -- now it contains "recently opened" document
IMHO you're wrong. If I open a file I expect it to be listed under the "recently opened files". And this is how it works in all other apps in kde (IIRC). Apart from that there would be bugreports from people complaining about the open-recent menu not being updated when they opened a file and kate then crashed. I'll leave the decision to the kate people though.
> If I open a file I expect it to be listed under the > "recently opened files". Me too, but there is no such menu. There is only "open recent" (as I said "open recent" != "recently opened", this is exactly that difference), And you cannot open a file which is already opened. Besides, such "feature" just kills session saving. There is no single purpose for listing currently edited files, there is distinct pane for that. > And this is how it works in all other apps in kde (IIRC). Many of them uses kate :-) > Apart from that there would be bugreports from people complaining about the > open-recent menu not being updated when they opened a file and kate then > crashed. We don't understand each other. Recent file is this one which was opened and closed, otherwise is not recent, but current. Closed -- directly, by closing session, by quitting kate or by crashing. So, for example: a) you open file A, it is registered, but not listed "open recent" b) kate crashes c) you run kate again d.1) complete session is restored, with A, still A is not listed in open recent or d.2) you start default session (because of the settings), so A is not reopened, A is listed then in "open recent" Even if I were wrong, other features of Kate makes current implementation of "open recent" useless, partly because of duplication, party because of the session saving. And I think it is better to have useful feature, i.e. open recent.
(In reply to comment #2) > > If I open a file I expect it to be listed under the > > "recently opened files". > > Me too, but there is no such menu. There is only "open recent" (as I said "open > recent" != "recently opened", this is exactly that difference), And you cannot > open a file which is already opened. Ok, so its actually about the text in the menu, right? If so I can adjust the description of this bugreport and re-assign it to kdelibs, because the "Open Recent" text comes from kdeui. > And this is how it works in all other apps in kde (IIRC). > > Many of them uses kate :-) That action is not part of katepart, hence no app that embeds katepart will get such an action from katepart. Obviously any app using KStandardAction::openRecent does get this string, unless it adjusts the actions text after getting it from kdelibs code. So I was partly wrong :) I'm not sure thouse what a better text would be, as "Recently Opened" is not quite right either as it doesn't tell the user what the individual items in this submenu do when they're activated. In that regard "Open Recent" is a little bit better. Maybe "Open recently opened file" would be better for kate, but its not general enough for usage in kdelibs standard text for a "recently-opened" action. > > Apart from that there would be bugreports from people complaining about the > > open-recent menu not being updated when they opened a file and kate then > > crashed. > > We don't understand each other. I do understand you, I just think that the problem is actually not that the menu "does the wrong thing" or is populated the wrong way, but just that the text for the menu is wrong. Because the intention of that action/menu is simply to have a list of files that have recently been opened. Andreas
> Because the intention of that action/menu is simply > to have a list of files that have recently been opened. Then the reasons of the bug would be still valid: a) they should list recently opened files, not currently opened b) if they should list also currently opened files, what would be the purpose of duplication (of file list pane)? c) what would be result of choosing already opened file from list of "currently opened files" d) immediately there would be a need (in case of b) for "open recent" feature, because only such feature does not interfere with sessions Such feature as today could be some help for app which does not have sessions and file list already, but kate has them.
I believe this bug is basically the same as the one I was about to report: The 'Open Recent' menu contains: a) Currently open files - this is technically redundant since there is another menu for that, and I believe that's what the reporter is saying. b) Files opened and closed this session. It doesn't contain anything else, so when Kate is closed and restarted, the menu is empty. This is the only time I ever use a recent files menu entry, so I assumed this was a bug. I'd like to clarify though: is it intended that the recent files list is lost across sessions? If so, I'll file a wishlist about it because that behaviour is useless to me.
About the session, do you refer to files that are included in session? 1) no -- this would be a bug, but separate from this one 2) yes -- is session restored? 2.a) yes -- in light of this report this would intended behaviour and valid 2.b) no -- this would be a bug, but separate from this one
(In reply to comment #5) > I believe this bug is basically the same as the one I was about to report: > > The 'Open Recent' menu contains: > a) Currently open files - this is technically redundant since there is another > menu for that, and I believe that's what the reporter is saying. It might be redundant as long as you have those files open. But once you close them its not. The problem with filling this menu on file-closing is that then you don't get it updated in cases of crashes. So when kate crashes, the user cannot access the files he had last opened before that crash in an easy and convenient manner. > b) Files opened and closed this session. Opening is enough, not sure wether this information is stored on a per-session basis or globally across all sessions. > It doesn't contain anything else, so when Kate is closed and restarted, the > menu is empty. This would only be the case if the list is stored on a per-session basis and you've selected to always start with an empty session. And in that case the behaviour would be correct. If that is the case I would assume that the kate devs had a good reason to do that, but of course you may file a wishlist report for changing that (storing the list of recently opened files globally not per session) Andreas
I've filed a feature request which should hopefully explain the behaviour I was expecting. With any luck one of the Kate developers will be able to explain what their position is, as the current behaviour does seem confusing to me.
> The problem with filling this menu on file-closing is that then > you don't get it updated in cases of crashes. You assume you have to show everything you get, but it is not true. You can store everything on open like now, but before showing, filter out all currently opened files.
That would probably be kinda confusing, the list would change depending on which files you have open or which you closed. Say you want to open two files you've worked before, you open the menu, choose the first. It gets opened and hence removed from that menu. Now you open the menu again and first have to search for the second file because its position changed. Also IIRC our HIG says that menu items should be as static as possible, in particular we shouldn't add/remove items all the time but instead enable/disable them. Oh and last but not least: The recent-files action itself doesn't know anything about such extra logic, so you'd have to code it in every app. YAY for code duplication ;)
> That would probably be kinda confusing, the list would > change depending on which files you have open or which you closed. This is intended and very useful. Use-case: * you open 10 files * you close one of them * you check the "open recent" -- the just closed document is listed on top So it is very easy to undo-close. OOffice does not behave like this and it is really tiresome to check all the files, to find out the latest one. > Say you want to open two files you've worked before, you open the > menu, choose the first. It gets opened and hence removed from that > menu. Now you open the menu again and first have to search for the > second file because its position changed. ? The list: ABCDEFGHIJ you open D --> ABCEFGHIJ the position is maintained, there is no resorting. But when you close D. The list will be: DABCEFGHIJ > Also IIRC our HIG says that menu items should be as static as > possible, in particular we shouldn't add/remove items all the time > but instead enable/disable them. For some features it cannot be done -- bookmarks, undo entry, recent files. > Oh and last but not least: The recent-files action itself doesn't > know anything about such extra logic, so you'd have to code it in > every app. YAY for code duplication ;) Nah :-), this is intended behaviour for every app, for Kate it is just more important and more visible because Kate has sessions.
moving to kdelibs as the functionality for recent-menu is there and thats the place where such logic should be added.
Hello, this wish is almost 10 years old and shows no recent activity. Is it still valid or should it be closed?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!