[prev] [thread] [next] [lurker] [Date index for 2006/07/20]
Phil Pennock writes: > On 2006-07-20 at 13:14 +0100, Smylers wrote: > > > Surely if you've inadvertently selected 'Cut' then the recently > > disappeared item is in the clipboard; can't you right-click on a > > blank bit of the bookmark toolbar and choose 'Paste'? > > I went to the Edit menu to get "Undo", saw it greyed out, saw "Paste" > greyed out too and decided not. But upon checking, Paste is context > sensitive. Fair enough. I never thought about trying the main 'Edit' menu, but now you mention it I can't think of any occasion on which I've ever used it. If I did choose 'Paste' I'd be unsure of to where to expect the pasted thing to appear. In, say, a text editor, it makes sense that the main menu's 'Paste' refers to the current text document being edited. But in a web browser there isn't really one UI item which trumps the others for being pasted into. It could depend where the cursor is; but I don't think it's possible to focus the bookmark toolbar so I don't see how it could ever apply to that. But in an app such as a text editor with an unambiguous main edity thing into which to paste I'd always expect the main 'Paste' to paste there; it would be confusing if different kinds of things pasted in different places, such as on a toolbar. So regardless of the app I'd expect only to be able to paste onto a toolbar with a menu on that toolbar. > > So you're saying that because T is the standard access key for 'Cut' > > that it should never be used for anything else, even on menus that > > don't have a 'Cut' item and are nothing to do with editing? > > I said nothing of the sort, please don't put words in my mouth to > attack a straw man. Sorry. You appeared to be complaining that in some menu Firefox was using T for 'Cut' when elsewhere it had used that same access key for something else. > I'm wondering WTF "cut" is an option when right-clicking on a toolbar; > do people really cut&paste shortcuts dynamically, except when pasting > back an accidental removal? For a Bookmarks Manager, yes. But the > regular bookmarks toolbar shouldn't be a manager. There's a manager? Coo. I add things to the bookmarks toolbar by dragging them there. Sometimes I drag them to re-arrange them. Sometimes I right-click and delete one of them. Why would I need a manager? But anyway ... I agree with you that cut, copy, and paste seem overkill here; they seem unusual operations to do on bookmarks. And if they're going to have them then > I'm wondering why, if there are a few standard sub-sets of items that > can appear on a menu (open(in..), cut/copy/paste) they don't either > have non-overlapping shortcuts for those common sets, or at least > non-overlapping if the sub-menus can appear together. Sounds reasonable, though it kind-of involves seeing into the future, or being prepared to break backwards compatibility. Suppose that when tabs were added to a browser bookmarks weren't right-click-able. So somebody adds 'Open Link in Tab' to the menu browser area right-click menu; at that point he has to predict that at some point in the future somebody else might want to add this same menu item to a different menu, one which will also have the standard edit options in it and already be using the T access key, and therefore a different access key should be chosen right now? In general making those kind of predictions is awkward. Alternatively at the point where the second menu is added the access keys get re-arranged on the first one, which is hateful for those who've got used to the old ones. > > If different menus didn't re-use access keys then there would only > > be 26 or so actions in the entire application with access keys. > > It's not the reuse of access keys; it's the different bindings of > access keys for one feature when it's present in different contexts, Fair enough. Right-clicking on a link in the main browser area gives a context menu which includes: Open Link in New [W]indow Open Link in New [T]ab and N is not used as an access key for any item. The right-click menu on bookmark items includes: Open in [N]ew Window Open in Ne[w] Tab Cu[t] Given that it's arbitrary which letter of "new" gets used for which item there it seems particularly hateful that between those two menus W switches between 'window' and 'tab'. Using 'W' for 'window' and 'N' for 'tab' on both menus would be consistent and possible while leaving everything else the same, and would've avoided you inadvertently cutting bookmarks. It doesn't seem to offer any disadvantage over the current state, except for incompatibility. > ... with the replacement binding being rather destructive ... I still think you're overstating the case there. It was hateful when in Windows 95 Microsoft changed Shift+Del from being the relatively safe 'Cut# of Windows 3 to the very destructive 'hard delete without the wastebasket'. But in that case one meaning definitely did replace another. Here the fact that you see 'Cut' as replacing 'New Tab' as the meaning of T is only because you happened to learn one menu before the other. And given that T is the standard access key for 'Cut' it seems reasonable to expect T to mean 'Cut' where that item appears in a menu; the fact that you've previously encountered a 'Cut'-less menu somewhere in the application which uses T for something else doesn't really change that. > ... and the recovery not being clear except perhaps in retrospect. If you've just used 'Cut' on a context menu then it seems reasonable to look for 'Paste' on the same menu. Definitely things could be more consistent, and that would be better. SmylersThere's stuff above here
Generated at 17:01 on 26 Jul 2006 by mariachi 0.52