[patch #1042] hotkeys and other improvements in hotlist
Follow-up Comment #14, patch #1042 (project mc): Sure, please feel free to use a different dotdot patch. I'm not saying mine is the best. I just want this functionality to be in. As for my patch, I wasn't such an experienced programmer back then (three years ago!). I just reworked that entire file and made a diff. I was not sure it will be accepted, and in fact it was indeed ignored for years. I can do better patches now, if I know they have a good chance to be accepted. By the way, currently I still run my own patched version of pre-4.6.0, because my patches are more important for me than the progress in the main codebase. If this patch is accepted or at least used so that the functionality is in, I may consider submitting other patches from my own version for including. And if they are accepted too I will be able to move to using the latest CVS, and therefore participate in the development more actively. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=1042 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #1042] hotkeys and other improvements in hotlist
Follow-up Comment #11, patch #1042 (project mc): Done. Note that it's very old and probably won't apply to current codebase without extensive tweaking. Please let me know if you have any problems. ___ Additional Item Attachment: File name: hotlist.diff Size:38 KB patch resubmitted without quot; http://savannah.gnu.org/patch/download.php?item_id=1042item_file_id=5852 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=1042 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
hotlist: hotkey duplicates control; patch submitted
A new version of the hotlist patch with hotkey duplicates control is uploaded: http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521 * in new/edit entry/group, an error message is displayed, and the dialog is redisplayed so that the user can change the hotkey * when reading in from the hotlist file, duplicate hotkeys are ignored, a warning (at most one) is displayed, and the hotlist is written back without the duplicates This is the last feature I planned for the hotlist, so the patch is ready. Of course it can be improved, if anyone will have time to go through the new code critically and/or suggest new features, but for now, from my perspective, it is finished. I'm eagerly waiting for it to become part of a next version of mc. -- __ 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
hotlist: buttons redesigned
A new version of the hotlist patch: http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521 More fixes and cleanup: * all declarations moved to block starts * no highlighted letter hotkeys in buttons, but access keys specified * reordered buttons so that most frequently used ones are in the first row * removed Up - confusing (What does that do?) and redundant now with .. in subgroups * Change to became Go to (easier to understand I think) * in movelist: removed Change to and renamed Append and Insert to Insert before (DEFPUSH_BUTTON) and Insert after correspondingly Now, if anyone can give me a clue of how to mark keys in button labels with a highlight color, similar to the way hotkeys were marked, then I think it would look much better. The same question applies to hotkeys in the entries - they would be nice to highlight too. -- __ 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
contrib directory badly needed
Maybe we need a directory for contributed changes that don't integrate well into the main codebase. YES! I browsed this list's archives and found lots of proposed patches that were never included into mc. I think we need to go through them once again and sort them into those that must be finally merged (e.g. the file coloring patch which I will take care of after I finish the hotlist) and those that should be at least kept in the contrib section. Also, some things that are merged are not documented. For example until recently I did not know about the wonderful --with-charset option. It's not in the man page or even in the FAQ! And by the way, why is it disabled by default? Note that the main strength of FAR, even though it is closed source, is its community of plugin writers and plugin web sites. This allows many people to contribute to FAR even without the main author's approval. With mc, if your patch was not accepted, you get zero visibility at all: the only place where your patch still lingers is the mailing list archives that are notoriously inconvenient to search. This must be changed. Is it too difficult to provide a section on the web page for storing patches and other useful things, with short author-supplied descriptions? -- __ 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: contrib directory badly needed
Now there is a Patches section on the mc BTS, so the situation is a lot better. I don't think so - it has a different purpose. Savannah account is a temporary storage for patches that are to be discussed and eventually either applied or rejected. What is needed, however, is a permanent storage for things that are not in mc but live their own parallel life. Supplying patches with official source is not a good thing - it would look like we support them I do not suggest to include them in the distribution. Just give them a prominent and permanent space to live on the mc web site (or linked from it). Moreover when somebody wants to publish his patch - he could do this on his homepage. Not everyone has one, and it's nearly impossible to find something specific if the storage is not centralized (unless you know exactly the name of the thing you're looking for). However 'contrib' dir would be a great thing for add-ons like mc-burner or some special vfses. Yes. -- __ 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
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: contrib directory badly needed
Good idea. Moreover mc homepage should be more informative. If nobody protests, I could improve the mc homepage when I have more time, or even rebuild it from scratch. I develop some commercial sites (http://www.rpg-portal.pl http://www.nostromorpg.pl), so you could be sure I know how things work in web design. I think that would be fantastic! -- __ 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
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
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
hotlist: now with edit
An updated hotlist patch uploaded: http://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_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
hotkeys in hotlist patch submitted
I just submitted a big patch for hotlist.c to savannah.gnu.org: https://savannah.gnu.org/patch/index.php?func=detailpatchpatch_id=1042group_id=3521 It's against pre3 but not for inclusion in 4.6.0 release, maybe a next version. Please test it and report your experience. It works for me but I'm not sure I did not mess something up. -- __ 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
