Re: hotlist: now with edit
There is one thing I just hate about hotlist. Let me explain on a example. I run and close and run mc again quite often in many xterms, and I don't remember whether I used hotlist in current session before. I have my favourite ftp-sites in 'ftp' group in hotlist. I run mc. I press Ctrl-\, Enter to go to my 'ftp' hotlist Then I chose site I want to connect with Enter Then I do some work, forget that I used hotlist before I press Ctrl-\, Enter and... MC CONNECTS to the first site when I just wanted to see sites list as before, Ctrl-C, Ctrl-C, Ctrl-C This is totally non-intuitive and drives me mad. The fix is simple: --- hotlist.c 21 Dec 2002 08:43:15 - 1.44 +++ hotlist.c 5 Feb 2003 15:38:44 - @@ -1079,6 +1079,7 @@ } hotlist_done (); +current_group = hotlist; return target; } It would be great if it could be applied to 4.6.0 Regards -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
Hello! +current_group = hotlist; Well, I understand you want to start with the top-level group every time. I don't use groups, so it's hard for me to judge, but I think that some users may want the current behavior. For example, somebody may want to visit every directory in the group because they have similar information, e.g. Apache logs. Then it's more convenient to start with the latest group. Even such trivial thing as removing .. in the root directory caused some protests. It would be great if it could be applied to 4.6.0 It would be great if I was sure that everybody would like this change. Since I'm not sure, I'll rather do it after the release. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
Well, I understand you want to start with the top-level group every time. I think both behavior can be useful, so this can be made a configuration setting. Now with hotkeys, the hotlist is even more convenient to always start with the root group, because it's easier to press ctrl-\ and a sequence of keys to go to some sub-sub-group item without even looking at the screen. On the other hand, to go through all items in a group, the old behavior may be better. But in this case it must be improved: it must remember not only the current group but also the pointer position. All in all, if no one complains, then I'd be happy with the always-display-root behavior. Otherwise I'd vote for a configuration setting. -- __ 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
On Wed, Feb 05, 2003 at 01:17:53PM -0500, bulia byak wrote: so I cannot implement your suggestion now. Also, I think it's much easier to use when all hotkeys are in a column. Now I could test your patch (after you have fixed errors I reported), and I understand you use hotkeys like User menu (hotkey before the label), not like mc Menu (hotkey highlighted inside the label). I have to admit this approach is a lot more usable. Few suggestions: - F7 hotkey for new group? - items alligned in a mc-way: .. - ftp samba not .. - ftp samba - only 2 chars left on the left side for hotkey (like in mc user menu), not nearly 10, like it is in your patch - one more silly thing, now new entry dialog looks like: l New hotlist entry qk xEntry label x /home/alpha a space before Entry label, Directory path and Hotkey would make it more pretty imo. -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
On Wed, Feb 05, 2003 at 02:58:17PM -0500, bulia byak wrote: .. - ftp samba I think it's easier to spot subgroups as you quickly scan through the empty column and see - there. Labels should be aligned with labels; when some other mark intrudes into labels I think it Ok, but imo you should treat '..' like a label and align it with other labels (to conform with the filesystem metaphor). -- _.|._ |_ _.: Adam Byrtek, alpha@(irc.pl|debian.org) (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |: jid alpha.pl(at)jabber.org ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: hotlist: now with edit
Ok, but imo you should treat '..' like a label and align it with other labels (to conform with the filesystem metaphor). Done, plus fixed a movelist bug -- __ 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
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: 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
