On Monday 25 March 2002 21:12, Christoph Cullmann wrote: > Hi, > nice mail about usability of kate/kwrite and possible problems, open for > disccusion ;) > My name is Irwin Kwan and I'm writing to you from the KDE Usability Group. > > I have noticed some differences between Kate and KWrite especially dealing > with the Menu Settings. I have written up a draft document with proposed > usability changes for the two applications to make them more consistent. This is indeed a very nice analysis. Thank you very much for giving attention to Kate/Kwrite! I have a few comments, and I will add them here, with aprts of the documents from Irwin above each comment. > TOOLBARS: > ~~~~~~~~~ > KWrite has two extra buttons to increase the font size after the 'find' > button. I think they are there to facilitate the browser extension. Imho they should be removed from kwrite and only be displayed in the browser extension - or maybe not at all? > *General KDE Note: the Find icon looks much too similar to a 'zoom' > button. Potentially misleading; perhaps forward suggestion to KDE-Look > to consider alternatives Agreed;) > Kate has five extra buttons, all dealing with Window-splitting or > file-browsing. > > Back (back arrow): View previous document > Forward (forward arrow): View next document > Split Vertically (window with vertical line): Opens the same file in the > same window, vertically > Split Horizontally (window with horizontal line): Opens the same file in > the same window, horizontally > Close Current Panel (single panel): Closes the current window panel. > > *Criticism: The Close Current tooltip is 'Close Current' , which might > be confused with 'Close' (for close file). A better tooltip might be > 'Close Current View'. Yes, or even "Frame", as a "View" represents a single document, whereas the frame may contain instances of several documents. > *Criticism: The Close Current icon is a single white square. I > recommend that it be changed to a white square with a red slash or > similar to let the user know that it is a 'Cancel' action. The icons for the splitting handling are from Konqueror, and was of cause chosen because they look familliar. The function in Kate is a bit different though, as a frame may contain more than one document. (snip) > General Observations: > ~~~~~~~~~~~~~~~~~~~~~ > > > KATE: > -In Kate, you cannot drag the file-list sidebar smaller if your file > names are too long. You cand make the file selector smaller than the tool buttons demand. I am working on that, but it means a whole new toolbar-like widget, as KToolBar cannot be used in a widget with reasobable functionality. The file selector btw does have a issue with the loaction combo: the listbox is resized to the width of the combo, hiding most of long paths. As this is done by KComboBox, it is not easy to avoid, I am trying... > -Your View settings are not saved on shutdown. Well, that is a configuration issue. You can check the "Restore View Configuration" option, which will do that. When closed by the session manager this should work, but i can't test it as i have a bug with splitting views (we are working on it, but it is not trivial...) (snip) --------- > MENU ORDER > ~~ > > I recommend the following order for menus in Kate. > > File Edit View Bookmarks Tools Document Settings Help > > I recommend the following order for menus in KWrite. > > File Edit Bookmarks Tools Document Settings Help > > -Why? > This keeps the first five items in the identical order, and the last > two in > identical order. > 'View' is Kate specific and is added in the middle. > 'Document' added to KWrite for overall consistency. > I can agree to the principles. Here is what I think: Generally, I look for the menus I use the most at the left of the menu bar - after considering conventions (file, edit ---- help). And there is a cross-desktop for the Document menu to be to the left I think. How ever, I would like to see "Tools" next to "Edit" in Kate/Kwrite, as most of the commands there are moved to make the edit menu smaller, and avoid bad logic. However, on my system (running HEAD, with slightly changed menus) I do have the suggested menu order, including the "Tools" menu, allthough not all commands that you recommend moved there have been (yet). I thought theese changes had made it to KDE 3 - if not I apologize. > * Up For Discussion: The top-level menu order (should we put Document before > or after settings, etc.). Before. It is more often used, and relates to the documents rather than the application. > * Up For Discussion: Where to put some options such as Panel-splitting and > File lists: perhaps in a new Menu named 'Window'? I have had a similar thought. There is some confiusion as to how this works atm, actually. If for example both the file list and file selector are open, and you activate the Settings->show (the one active) it will close down. This is becase of the dock system, and needs work. I believe we should have commands to "show" and - whenever a docked window is in a tabbed stack at least - focus each docked tool window. There is currently no way of focusing the tool windows using the keyboard, so that is really a missing feature. > * Up For Discussion: The naming of some of the menu items: Document - > Window? View -> Window? I think we sould use the words "Document", "View" and "Frame", which i guess is most familliar to users. A document is the contents of a file, which have one or more Views, each positioned inside a Frame. (snip) > *Find in Files... should not appear in KWrite. > (Question: What is 'Editing Command'?) Read the manual:) > Changes in Both: > -Editing Command should have an ellipsis (...) because it brings up a > separate > dialog. Agreed. > Changes from Kate: > -Removal of a number of items to make the menu smaller. (Most of them > will be > relocated to the Tools menu). > -Some reordering. (Go To Line... for example was moved closer to the > top.) As I stated above, I have partly done that;) --- (snip) > Up for Discussion: > "Toggle Bookmark" is an awkward term and perhaps should be renamed to > Add Bookmark'. If you want to delete a bookmark, perhaps add an 'Edit > Bookmarks' style dialog. > Call it 'Add Bookmark' if you don't have a bookmark there. If you do, > grey it out. > Add another item called 'Delete Bookmark'. If your cursor is on a line > with no bookmark, then grey it out. If your cursor is on a line WITH a > bookmark, activate this item. NO!! PLEASE!! Splitting this would greatly confuse, and make usability worse - would have to remember two commands rather than one, and it would eat a precious shortcut. Imo the them "Bookmark" is wrong - this is traditionally known as a "mark". This is very confusing inside konqueror, which allready has a "Bookmarks" menu, and soemone even at a point changed the kwrite browserextension menu to add the it's "Bookmarks" menu in the menubar, next to konquerors own (my original place when I made the marks feature available to the browser extension was to in edit->marks - neither very good, but better imho). "Toggle Mark" is exactly what is beeing done, and thus the correct term. You can see it if you use the icon border, click on a line to toggle the mark. Deniying me the opiton to remove a mark with the keyboard without launching a dialog would probably make me dump kate. The only alternative I can think of, is changing the text of the action to reflect the current line when the menu is launched, so that it would say "Set Mark" if the line had no mark, and "Remove Mark" if it did. But commands with changing labels are tricky, and should be used with care. > DOCUMENT MENU > ~~ > > Document Menu: To manipulate document settings for one specific > document. > > Document > Back* > Forward* > -- > KDE Scripts > > Convert file text to lowercase > Test Shell Script > Highlight Mode > > Normal > Sources > > Markup > > Scripts > > End of Line > > Unix > Windows/Dos > Macintosh > -- > Show Icon Border > Show Line Numbers > -- > (Document List)* > > *Not in KWrite > > Changes from KWrite: > -I moved a lot of the options such as 'End of Line' and 'Highlight Mode' > to this > menu because they make more sense to apply to a 'document' rather than > as a > setting. Settings implies global whereas these options apply only to > the > current document. I agree to this. > -I moved 'Show Icon Border' and 'Show Line Numbers' because they apply > only to a > specific document and not to the global settings. Well, they apply to the View, not the Document. Currently, if you split a frame the settings aren't even copied. See below. > *Comment: 'Show Icon Border' and 'Show Line Numbers' cannot be set to be > displayed on default when you open a new file. These options should be > added > to the "Configure " dialogs to state "Display Line > Numbers". That is on my TODO. I add options for line numbers to be on by default, and for icon border to be on, off or auto, where auto would display the border when there is one or more marks in the Document. > Using the 'Document' menu they can toggle the Numbers on and off for > one > document. Well, that does not happen just because you move the command to another menu;) To achieve that, the property should be moved to Document, rather than View where it resides now - anything else would be ugly. Alternatively it could be an option to have settings even, that is if a new view is added for a document, the state of line/icon borders are copied. But I personally agree, I would like to move that setting to document. > Changes from Kate: > -Moved the 'Show Icon Border' and 'Show Line Numbers' from View to > Document. > The settings do not apply to the View, but instead to the Document. > (Try > opening a couple files, then setting one to 'Show Line Numbers'. Click > on the > other document. Then click back to the original document.) ??? If I do that, things works as expected: the View for which I displayed line numbers shows them, others not. > > ~~ > VIEW MENU > ~~ > > View Menu: Change viewing options (This does not appear in KWrite). > Operations > apply to the Kate window. > > View > Split Horizontal > Split Vertical > -- > Show File List > Show File Selector > Show Terminal Emulator > -- > Close Current > Go > > Next View > Previous View > > Changes from Kate: > -I moved 'Show Terminal Emulator' from 'Settings' to 'View' because the > Terminal > opens in a new View. Showing the Terminal Emulator is not a setting. > (Fascinating facts: The command for this in Konqueror is called 'Open > Terminal > and appears under the Tools menu. Another command called 'Show > Terminal > Emulator' is under the 'Window' menu.) Well, the term "View" in Kate reffers to a visual representation of a document. What you suggest is a microsoftish interpretion of the "view" menu, which is one mistake that KDE didn't (at least on a global level) duplicate: In KDE those settings are usually in the Settings menu. > Up for discussion: > -Where to put 'Show File List' and 'Show File Selector': Under > 'Settings' or > 'View'? They are within a view-style window, but are not the same as > an > Editing View. I put them under 'View' because I believe it is more > natural for > people to look here than under 'Settings'. However, See above. In KDE they belongs under "settings". The dockable interface is problematic here though, as focusing and opening/closing a docked window is not (nessecarily) the same. > Up for discussion: > -Rename 'View' to 'Window' to be more consistent with Konqueror. > My personal take? I like 'View' a lot better, and I think makes more > sense > than 'Window' does. Absolutely. Again, "View" refers to a representation of a document. > -Maybe move the Documents List under 'View'. > 'Documents' applies to one document. Why put them under the > 'Documents' > section then? > But the Documents list isn't a View-style operation. IMO the document menu of Kate is exactly what it should be. There is some confusing with the file menu. When I originally added the "open with" option for example, I wanted to put it under "Document" as it is an action corresponding to the "current document". The same could be said for other commands. It was moved because of the convention, which tends to win over logics quite often - at least for something as traditional as the file menu;) > ~~ > SETTINGS MENU > ~~ > > Settings Menu: Settings for the global application, such as displays and > behaviour. > > Kate Menu: > Settings > Show Toolbar > Show Statusbar > Show Path > -- > Configure Shortcuts... > Configure Toolbars... > Configure Kate... > > Changes: > -Removed 'Show Terminal Emulator', "Show File List", "Show File > Selector" for > reasons discussed under 'View'. > -Added 'Show Statusbar'. (This should be on by default). This is an > option in > KWrite that is not in Kate. > -Added 'Show Path'. This is an option in KWrite that is not in Kate. This option was removed from the kate settings menu on request. It is in the kwrite menu, because kwrite does not have a settings dialog of it's own, since kwrite just a wrapper around katepart, ont a real application of its own. The reason for removing it was that it is a rarely used option, most people will set it once and never again, so having it in a menu is considered overkill and polution of the menu system. (snip) Well, that was my comments. Again, thanks for the input. I hope we can make the best of this discussion, apart from making kate and kwrite more consistent, it raises some important discussions for kate, which is a complex application, and deserves carefull design of the command interface. -anders _______________________________________________ kwrite-devel mailing list kwrite-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/kwrite-devel