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
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
> - hotkey for "new group"? Yep > - items alligned in a mc-way: > >.. >-> ftp >samba > > not >.. >-> 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 looks bad. > - only 2 chars left on the left side for hotkey (like in mc user > menu), not nearly 10, like it is in your patch 2 is too few I think. I now made the separator 3 chars wide. > a space before "Entry label", "Directory path" and "Hotkey" would make > it more pretty imo. Done. I also applied your patch to always start in the root group; if anyone complains we can revert that or make it optional. -- __ 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: - 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
> I think we should leave users the choice and allow button hotkeys > duplication (hotlist hotkeys shoud take precedence). If one doesn't > want to have his button hotkey obscured - he will choose another > hotkey for his entry. Hotkeys that are displayed but do not work are a usability error. We must not make users wonder "why the highlighted letters stopped working." So for now I removed all button hotkeys in my patch - please try it out. > 2. Do we need to check for duplicate hotkeys in one group? > As Pavel said there are duplicates even in the menu. We should leave > the decision to user and the first entry should take precedence. This > will be convinient with the rest of mc. I think duplicate hotkeys are an error, both in menu and in a list. The second one does not work and this can be very confusing. So I don't think we must be "consistent" in perpetuating such errors. Let someone else fix the menu; I will make sure no such problems occur in the hotlist. > I would prefer standard approach like: > "My &favourite directory" > where 'f' will be a hotkey. As was discussed here some time ago, this would not allow you to use letters that are not in the label, which is inconvenient. And anyway, I don't know if it's possible to highlight arbitrary chars in a list, so I cannot implement your suggestion now. Also, I think it's much easier to use when all hotkeys are in a column. -- __ 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
> 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
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
On Mon, Feb 03, 2003 at 02:37:50PM -0500, bulia byak wrote: > An updated hotlist patch uploaded: It is still broken as I told you in private mail. I'll test it when it will compile. > Since nobody complained, I removed insert/append buttons; now it's > one button saying "add" for "new entry/group" and "done" for Wise. When I started using hotlist I was confused what all those buttons really mean. > 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 I think we should leave users the choice and allow button hotkeys duplication (hotlist hotkeys shoud take precedence). If one doesn't want to have his button hotkey obscured - he will choose another hotkey for his entry. > 2. Do we need to check for duplicate hotkeys in one group? As Pavel said there are duplicates even in the menu. We should leave the decision to user and the first entry should take precedence. This will be convinient with the rest of mc. > 3. Does anyone know how to make a one-char-wide field for the > hotkey? I would prefer standard approach like: "My &favourite directory" where 'f' will be a hotkey. -- _.|._ |_ _.: 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
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
> > 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 ] [ New entry ] [ Delete ] 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: 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
> 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
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
hotlist: now with edit
An updated hotlist patch uploaded:
http://savannah.gnu.org/patch/index.php?func=detailpatch&patch_id=1042&group_id=3521
Since nobody complained, I removed insert/append buttons; now it's
one button saying "add" for "new entry/group" and "done" for
"edit entry/group".
I also removed "add current" as redundant ("new entry" does the
same with default values).
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?
2. Do we need to check for duplicate hotkeys in one group?
3. Does anyone know how to make a one-char-wide field for the
hotkey?
4. Does anyone know how to display part of the line in a list
differently, e.g. to highlight the hotkey in each line of the
list?
--
__
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
