compare-plugin
compare-plugin copied to clipboard
jsleroy
Implement short help
Hello Pavel,
Continued from https://github.com/pnedev/compare-plugin/issues/10#issuecomment-206513371.
If I understand "Select first" correctly, you want to give the user another option besides "Compare current to previous". This can be very useful if you have multiple files open in Single-View mode. Great!
So why not implement it as "Compare current to last active" instead of "Select first" which is less intuitive and clear? (No offense please :) ).
Compare: Compare current to previous (Single-View) or Compare current to the active file in the other view. Compare current to last active: should only be available in Single-View mode.
What do you think?
Anyway, I think you should add a Help item opening a window (a long message box) briefly describing the various options.
Thank you.
Best regards.
Hello Yaron,
Thanks for the suggestion but I prefer to keep it this way. This gives much more freedom, you can use this in Two views mode as well and it resembles the other stand-alone compare programs out there (they integrate in the right click shell context menu 'Select first to compare' command that does the same thing).
The help might be a good idea at a later stage. I'll keep this issue open as a reminder for this. Thanks again.
BR
Hello Pavel,
You're the boss. :) Yet - we both want Compare Plugin to be best - allow me to further explore the issue.
This gives much more freedom, you can use this in Two views mode as well
This is a good point. Rethinking about it, "Compare current to last active" can also be relevant to Two-Views mode.
and it resembles the other stand-alone compare programs
Can those applications implement "Compare current to last active" in the shell context menu? Also - if you implement it in a better way, they will eventually "steal" it and change their approach. :)
Another point: with "Compare current to last active" you get the files compared with less clicks/actions, and it's more intuitive and clear.
Another option worth considering is a preference which can be saved. Some users might actually prefer "Compare current to last active" as the default behavior.
So you only have one Compare command and then "Compare Mode: Compare current to last active" checked/unchecked.
Thank you.
Best regards.
Hello Yaron,
As a matter of fact my initial idea behind "Select first..." was to start compare (with "Select first") and then immediately after switching to the other doc the compare between the two files is triggered. Interestingly enough it is close to your idea about "Compare current to last active". I decided not to do it because it doesn't seem that intuitive to me (neither does the current "Compare" in single view mode). Maybe it's because personally I like to be more explicit about things.
Can those applications implement "Compare current to last active" in the shell context menu?
Good point :) but I mentioned it because it makes the approach well known among the users of compare programs in general. Thus I don't think it will be something new and vague for the users.
One of the things I like about the current implementation is the freedom - for example I can re-select the first file without problem, I can abort the second step and give-up comparing without problem, I can even workaround this issue :)
The other concern I have is that I don't want to overuse the N++ notifications. The approach you are suggesting would require automatic re-selection of the first file every time the user changes the document. I agree it is not much of an overhead but it is not something vitally needed. When not using the plugin I'd like to keep N++ as close as possible to it's state if the plugin is not there at all (unless it is absolutely necessary from functional point of view).
Thanks for the suggestion anyway.
BR
Hello Pavel,
Thanks for the explanation.
I can even workaround https://github.com/pnedev/compare-plugin/issues/34 issue :)
Could you elaborate please?
The other concern I have is that I don't want to overuse the N++ notifications. The approach you are suggesting would require automatic re-selection of the first file every time the user changes the document. I agree it is not much of an overhead but it is not something vitally needed. When not using the plugin I'd like to keep N++ as close as possible to it's state if the plugin is not there at all (unless it is absolutely necessary from functional point of view).
You got me there. I didn't think about it.
Some minor points: Should "Select first" be the first item? Why? Can you change it to "Select current as first"? Isn't it the convention that a menu command with an ellipsis opens a new window? (Which reminds me that "Options" and "About" should have it :) ). Alt+F might open a menu in some locals.
Best regards.
Isn't it the convention that a menu command with an ellipsis opens a new window?
Yes, and without the ellipsis it would be obvious that "Select first" acts on the currently focused file (like "File > Save" and many others).
Hello Pavel and xylographe,
@pnedev,
If the user presses "Select first", switches to another tab, closes the previously selected tab and then Compare - you would compare current to previous. Is that correct?
Thank you.
@xylographe,
You are right. Thanks.
"Select as first to Compare" would be a bit clearer ("Compare" with a capital C).
Best regards.
Hello @Yaron10 and @xylographe,
Thanks for the feedback. I have changed the discussed plugin commands names to "Set as first to Compare", "Options..." and "About...".
Yaron,
Regarding this:
I can even workaround #34 issue :) Could you elaborate please?
- You have files A and B in view 1
- You have files C and D in view 2
- A and C are currently compared
- You want to compare B to D
Even if the bug from #34 is present you can now do:
- Select (activate) file B in view 1. Set as first to compare.
- Try to select file D from view 2 -> the bug triggers -> you have file C active in view 2 and A in view 1 and the active view is 2
- Switch to file D in view 2
- Compare -> B and D are compared regardless of the transitional switch to file C.
If the user presses "Select first", switches to another tab, closes the previously selected tab and then Compare - you would compare current to previous. Is that correct?
Yes, that is correct.
Should "Select first" be the first item? Why?
I think yes -> this is where the compare operation normally starts. The automatic "compare to previous" is more of a useful addition as I see things. It isn't obvious to the user and it shouldn't be the "normal" usage flow.
Alt+F might open a menu in some locals.
@Yaron10 and @xylographe , what default shortcut would you suggest for "Set as first to Compare"? Thanks.
BR
@pnedev I think the current shortcut (Alt+F) is ideal. :sweat_smile:
Hello Pavel,
Thank you very much. I appreciate it.
Should "Select first" be the first item? Why?
I think yes -> this is where the compare operation normally starts. The automatic "compare to previous" is more of a useful addition as I see things. It isn't obvious to the user and it shouldn't be the "normal" usage flow.
Again, allow me to suggest a different view: I often have some 40 pairs of files to compare. I open one pair at a time, compare, do my work and close the files. IMO the current order might confuse the users and make them think they have to use "Set as first to Compare".
Alt+F might open a menu in some locals.
After posting I remembered that other Compare commands use Alt+... I do believe those shortcuts might present a problem in some locals and should be changed. What do you think?
Best regards.
It could be difficult (if not impossible) to get it right for every locale (~500 in the CLDR). Fortunately, the NPP shortcut mapper also supports plug-in shortcuts.
It could be difficult (if not impossible) to get it right for every locale
But we don't have to use Alt which opens a menu.
Hello guys,
I'm not quite aware of locales and what 'Alt' has to do with them but we don't have much options for shortcuts left as there are a lot of already occupied ones (either by the Scintilla, N++ itself, macro or other plugins). I would normally leave a plugin with no predefined shortcuts to avoid possible conflicts and leave it to the user to make his own mappings but since Compare is around for a pretty long time it is better to keep what it already has.
@Yaron10 ,
Since we are already using 'Alt' for the other commands Alt-F shouldn't be a problem, correct?
I'll leave it to you both to decide what is the best shortcut for the new command, thank you.
@xylographe ,
Would you please give your opinion on the commands menu order? I prefer "Set as first.."to be the first followed by "Compare" while Yaron seems to prefer those swapped. Thanks.
BR
@Yaron10 No, Alt by itself doesn't open a menu. It underlines the keyboard accelerators in the menu bar. For example, if you choose Afrikaans, the F of "Formaat" will be underlined. You have to release Alt and press F to open the "Formaat" menu. (Perhaps, you were thinking of keyboard accelerators in buttons?)
Pressing Alt+F (simultaneously) will work as expected ("Select first" from CP).
@pnedev Both are acceptable to me. However, I do have a slight preference:
- Select first
- Compare
- Clear Compare
It looks better when "Compare" and "Clear Compare" are not separated by "Select first".
we don't have much options for shortcuts left as there are a lot of already occupied once
Exactly! To avoid conflicts with NPP & Scintilla it is better not to use Ctrl shortcuts.
Hello gentlemen,
On windows pressing Alt moves the focus to the menu and underlines its keyboard accelerators (as xylographe has mentioned). Pressing Alt+F opens the File menu (in English, no need to test in other locals :) ).
Here is the interesting part: If the application doesn't have Alt+F assigned, the File menu opens whether you press those keys simultaneously or Alt - release - F. If, however, the application does have Alt+F assigned, the File menu opens only on Alt - release - F; pressing them simultaneously executes the application's command.
So, on the bottom line xylographe is right and Alt+F is OK.
Pavel,
Regarding the order: well, our new supreme judge has ruled. :)
Thank you.
Best regards.
OK, I'll keep things as they are then. I'm leaving this issue open as a reminder about the Help implementation enhancement.
Thanks guys.
BR
@Yaron10
You're absolutely right! To anyone who is used to open a menu with Alt+F (Afrikaans/English) or with Alt+D (Dutch) the CP shortcuts are undesirable. Switching to Alt - F / Alt - D to open the menus is not really an option for those users, as old habits die hard.
Ultimately, this makes it impossible to use any Alt shortcut, because there will most likely always be at least one locale that is already using that key as a keyboard accelerator, and at least one user who prefers to open that menu with Alt+X i/o Alt - X.
On the other hand, most plain Ctrl shortcuts (w/o Alt and/or Shift) have already been assigned, and chances are that others will be taken by NPP in future releases. Add to that the fact that NPP is also using plain Alt shortcuts (Alt+C and Alt+H), as well as the fact that CP users are accustomed to Alt+D.
All in all it would appear that “keeping things as they are” might be the lesser of two evils—to most users at least.