Re: hotlist: now with edit
Hi, Please report your experience. Please also share your ideas on these issues: 1. Hotkeys of entries may obscure the hotkeys of the buttons in the bottom of the list. Do we need to: block conflicting hotkeys from being entered, or warn the user, or disable button hotkeys? As for me, I'd rather have the hotkeys assigned to the entries. Maybe, the buttons should be reorganized so the most used would be easy reachable when jumping form list to buttonset with tab, e.g. 'New Entry' should be first. 2. Do we need to check for duplicate hotkeys in one group? Hm, if we allow more entries assingned to one hotkey, then pressing the key should cycle-jump through entries. bye Dave ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
As for me, I'd rather have the hotkeys assigned to the entries. Me too. So I think the options are: 1. Warn the user if a new hotkey conflicts with that of a button, but perform no further action. 2. (I'd prefer this one) Just remove all hotkeys from the buttons, to aviod any confusion. This is reasonable because the buttons are accessible not only via Tab, but by other keys (that cannot be entry hotkeys anyway): Change to = Enter Edit = F4 (not yet, but I think it's a good idea) Up = Left-arrow Remove = Del New entry = Insert New group = ? (any suggestions?) Hm, if we allow more entries assingned to one hotkey, then pressing the key should cycle-jump through entries. That's too inconsistent. A hotkey's action is to activate an item immediately. It may be utterly confusing when you hit a key but the expected action is not fired only because there's another item with the same hotkey. So I think it's best to prevent duplicate hotkeys from being entered. -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
Hello! 2. (I'd prefer this one) Just remove all hotkeys from the buttons, to aviod any confusion. This is reasonable because the buttons are accessible not only via Tab, but by other keys (that cannot be entry hotkeys anyway): I think that would be inconsistent with other dialogs. I'm afraid there is no simple solution to this problem. There is no list of currently supported keys and there is no way to test at runtime which hotkeys are active. Maybe the dialog hotkeys of the dialog should be disabled if they conflict with the user entries? If this happens, the hotkey on the button should not be shown. Change to = Enter Edit = F4 (not yet, but I think it's a good idea) Up = Left-arrow Remove = Del I remember reading somewhere that OK and Cancel should not have hotkeys because they are always bound to Enter and Escape respectively. I don't remember where I read that, but the GNOME and KDE programs that come with Red Hat 8.0 don't seen to follow this rule (I checked gedit and kedit). On the other hand, Mozilla and qtconfig (Qt configuration) follow this convention. I think that all other buttons should have the hotkeys. Hm, if we allow more entries assigned to one hotkey, then pressing the key should cycle-jump through entries. That's too inconsistent. A hotkey's action is to activate an item immediately. It may be utterly confusing when you hit a key but the expected action is not fired only because there's another item with the same hotkey. So I think it's best to prevent duplicate hotkeys from being entered. I think it's the right thing to do. There are duplicates even in the English menus. For example, F9-C-E can be Free VFSs now or Edit extension file. Either the second item should not have its hotkey highlighted or the hotkey should move between entries without activating them. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
RE: Much better now! (was RE: configure problem)
On Mon, 3 Feb 2003, [EMAIL PROTECTED] wrote: By the way, I get the same warnings on Slackware 8.1 configure.in:11: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst configure.in:605: warning: do not use m4_regexp: use regexp or m4_bregexp This must be a warning from Autoconf about some macros from Automake. I don't see this with Autoconf 2.57 and Automake 1.7.2. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
2. (I'd prefer this one) Just remove all hotkeys from the buttons, to aviod any confusion. This is reasonable because the buttons are accessible not only via Tab, but by other keys (that cannot be entry hotkeys anyway): I think that would be inconsistent with other dialogs. Yes, but can we find a solution that would be perfect? I think this inconsistency is better than the drawbacks of other approaches. I'm afraid there is no simple solution to this problem. There is no list of currently supported keys and there is no way to test at runtime which hotkeys are active. The letter hotkeys have an advantage of being visible (highlighted). But then, we can made other keys that activate the buttons visible too, e.g.: [ Edit F4 ] [ New entry Ins ] [ Delete Del ] What would you say? Again this is inconsistent with other dialogs but at least it's convenient. Maybe the dialog hotkeys of the dialog should be disabled if they conflict with the user entries? If this happens, the hotkey on the button should not be shown. I thought about this and I think it's a bad idea. Not only it is difficult to implement (redrawing the dialog on each add/delete entry and on each going into a subgroup), it may be very very confusing when (from the user's viewpoint) button hotkeys appear and disappear seemingly randomly without any warning or explanation. I think most people will consider this a bug. That's too inconsistent. A hotkey's action is to activate an item immediately. It may be utterly confusing when you hit a key but the expected action is not fired only because there's another item with the same hotkey. So I think it's best to prevent duplicate hotkeys from being entered. I think it's the right thing to do. There are duplicates even in the English menus. For example, F9-C-E can be Free VFSs now or Edit extension file. Either the second item should not have its hotkey highlighted or the hotkey should move between entries without activating them. OK I'll implement hotkey search so that a duplicate hotkey cannot be entered. If it is read in from the file (manually edited), a duplicate hotkey is not displayed (perhaps with a warning?). -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mouse behavior discussion
Hello, Mike! I wonder amongst mc-users, what should the mousewheel do in the panels? For your information, mc-users live at [EMAIL PROTECTED] Anyway, your question is relevant here. Right now, for me, it scrolls by a page every time, and moves the selected along with it. This behavior I do not like, and is always the first patch I apply to fresh cvs. I remember that there was an attempt to fix it by allowing the cursor to be off-screen, but I didn't like that patch, so it was dropped. I have two questions: 1. Should mousewheel scroll_by_pages or scroll_by_line? (IMHO that's what that artifact panel_scroll_pages was originally for, although I don't know for sure.) I'm not against scrolling by lines if somebody comes with an idea (better yet - working implementation) how to make it in an intuitive way. panel_scroll_pages only affect the behavior of mc when the scrolling is done by lines and the cursor reaches either boundary of the displayed part of the list. 2. Behavior of panel-selected: In editor the traditional way is to have cursor follow mousewheel to avoid typing in wrong area of file after scrolling with mouse, but in a file listing (in all other file managers I've used), it stays in place while only the listing scrolls. I don't see any question here. The adjustments are simple, but I'm not sure if others like what it does now, and if so, why. There was only one person concerned enough to make a patch, yet the patch was wrong. Older versions, including 4.5.55, don't support mouse scrolling at all, and I don't remember any complaints. Maybe nobody uses mousewheel? They are so common where I live I throw 2 button mice in garbage :) Not everybody uses mouse when working with text interface. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
