Version: (using KDE 4.2.0) Installed from: SuSE RPMs Inconsistent UI = bug. How to observe the issue, run fresh, new kate. Look at redo and open recent buttons (menu items as well). There is no history for redo, there is no history of recent files. The first one is disabled, the second one is enabled (with submenu informing it is disabled). In such case "open recent" should be simply disabled.
SVN commit 964121 by cfeck: Disable empty "open recent" menu I kept the hide/show "No Entries" action logic for styles/platforms that expand disabled sub menus. BUG: 185312 M +4 -0 krecentfilesaction.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=964121
How about applications that include the Open Recent button in the toolbar instead of Open? It means that when the application is run for the first time it will show a disabled Open Recent button with the same icon usually used for the Open action. Should the icon be changed? Should this behaviour be kept? Shouldn't applications use Open Recent instead of Open in the toolbar?
SVN commit 969366 by rkcosta: Commit 964121 disables the Open Recent menu when it's empty. Since we use the Open Recent button in the toolbar instead of the Open button, Ark would show a disable Open button in the toolbar while the real Open action would be enabled in the menu. For now, we just enable the open recent action when setting up the actions. CCBUG: 185312 M +2 -0 mainwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=969366
I am a bit puzzled with those questions: Open recent != Open Those are two actions, it is not that "open recent" is better version of "open". So for example such text I don't understand really: " Since we use the Open Recent button in the toolbar instead of the Open button, Ark would show a disable Open button in the toolbar " Why it is used _instead_? It shouldn't be? Why disabling "open recent" causes disabling "open"?
Sorry if I wasn't clear. (In reply to comment #4) > So for example such text I don't understand really: > " > Since we use the Open Recent button in the toolbar instead of the Open > button, Ark would show a disable Open button in the toolbar > " > > Why it is used _instead_? It shouldn't be? Why disabling "open recent" causes > disabling "open"? By default, we use the Open Recent button in the toolbar (which happens to have the same icon as the Open button) in order to both open new files and open recent files quickly. So if the user has not opened any file yet the button that looks like the open button is disabled in the toolbar, while an item in the menu with the same icon is enabled. This is confusing, so that's why I asked in comment #2 if it's an icon problem or if it's simply a matter of always using Open.
> By default, we use the Open Recent button in the toolbar (which happens to > have the same icon as the Open button) in order to both open new files and > open recent files quickly. This is bad. You have distinct "open" and "open recent" menu entries and toolbar should reflect this. So it app should not make such mix and "shortcuts" -- UI should be straightforward. So apart from this there is no problem -- open in menu and menu entry is always enabled, open recent in menu and toolbar is enabled only for non-empty list.
Raphael, if you use "Open Recent" action in toolbar, what is gained by enabling it when there are no recent files? Do you abuse the button to be a combined "Open"/"Open Recent" action? I just checked KWrite, it has separate actions/toolbuttons for those. I agree that the icons should not be the same, but that is a different issue to be solved.
SVN commit 969828 by rkcosta: Use Open instead of Open Recent in the default toolbar layout after some discussion in the CC'ed bug report. Even though Open Recent is more convenient sometimes, it is a different action. CCBUG: 185312 M +1 -1 arkui.rc WebSVN link: http://websvn.kde.org/?view=rev&revision=969828
Thanks for your comments. Open Recent and Open are two different actions and, even though the old Open Recent behaviour felt quite convenient, I'm now using Open as most other applications do. Personally, sometimes I even think Open should be dropped and Open Recent be made the only option.
Raphael, I also think "open recent" is useful -- the thing is they can both reside in toolbar as in menu -- open AND open recent. Kate for example has both as default.
Yes, however IMHO it would be better if they could just be merged into one button/action.
The only ways that come my mind are: a) make the portion of open button trigger "open recent" b) press&hold (some time) to get "open recent" (like in Kate3, though it is not merged) Both are accessibility abuse. However interesting idea for me would be populating open dialog with recent file list per each app.
(In reply to comment #12) > The only ways that come my mind are: > a) make the portion of open button trigger "open recent" > b) press&hold (some time) to get "open recent" (like in Kate3, though it is not > merged) > > Both are accessibility abuse. Sorry, I don't understand what you mean by accessibility abuse. > However interesting idea for me would be populating open dialog with recent > file list per each app. I don't understand this either :)
a11y abuse -- UI cannot be constructed in such way, that handicapped users are placed as worse than "regular" users. UI should be for everyone -- on equal rights. Populating open dialog with recent files. I am sorry, it is already done :-)) Not every app does it right though, time to fill bug reports.
(In reply to comment #14) > a11y abuse -- UI cannot be constructed in such way, that handicapped users are > placed as worse than "regular" users. UI should be for everyone -- on equal > rights. I'm sorry, I don't understand why this would happen if both buttons were merged. > Populating open dialog with recent files. I am sorry, it is already done :-)) I still don't understand this. Where do recent files show up in the open dialog? Can you give me an example of a program that does that?
Buttons merge -- maybe I ask you how you would merge them? One button -- now, how user can trigger "open" and how "open recent" using the same button. > Where do recent files show up in the open > dialog? Can you give me an example of a program that does that? Sure, okular, kate for example. File -> Open -> click on the filename dropdown list. It is buggy though, I posted already report about it.
(In reply to comment #16) > Buttons merge -- maybe I ask you how you would merge them? One button -- now, > how user can trigger "open" and how "open recent" using the same button. I'm thinking of the behaviour you described in comment 12 - click the button and the Open dialog pops up, hold the button and the recent files are shown below the button (though I can't think of what would happen in the menu...). What I don't understand is how this would make it difficult accessibility-wise. > > Where do recent files show up in the open > > dialog? Can you give me an example of a program that does that? > Sure, okular, kate for example. File -> Open -> click on the filename dropdown > list. It is buggy though, I posted already report about it. I see. This buggy behaviour made it almost unrecognizable ;)
Such UI simply means you end up having such clicks: a) short click b) long click c) double click d) two clicks with possibility of (d) being really: * two short clicks * two long clicks * two short & long click * two long & short click For disabled person measuring time of how long to hold a button is difficult. She/he releases it too quick, gets action A, too late, gets action B. This is too frustrating, not mentioning that you don't have any feedback of time passing. Except for the games, UI should be not based on time -- and it has nothing to do with setting bigger time interval. KDE already goes in the right direction allowing to get rid of double click. And from my experience it is relief for users. Now, divining single click into short and long click would be just opposite of this progress.