Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Activate Sub-View before closing files #40

Closed
Yaron10 opened this issue Apr 8, 2016 · 11 comments
Closed

Activate Sub-View before closing files #40

Yaron10 opened this issue Apr 8, 2016 · 11 comments
Labels

Comments

@Yaron10
Copy link

Yaron10 commented Apr 8, 2016

Hello Pavel,

If you Compare when multiple files are open in Single-View mode, the original view's ID affects the following behavior:
If it's MAIN_VIEW most of the files are in the top view.
If it's SUB_VIEW most of the files are in the bottom view.

Most users don't know how NPP's "Move to Other View" is handled and might wonder about this inconsistency.
I think we should do whatever possible not to change the default view's ID in Single-View mode.

Currently after closing matched files, the view's ID is SUB_VIEW.

And therefore I think we should replace

                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_FILE_CLOSE);
                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_VIEW_SWITCHTO_OTHER_VIEW);
                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_FILE_CLOSE);
                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_VIEW_SWITCHTO_OTHER_VIEW);

with

                HWND focusedView = ::GetFocus();
                ::SetFocus(nppData._scintillaSecondHandle);

                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_FILE_CLOSE);
                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_VIEW_SWITCHTO_OTHER_VIEW);
                ::SendMessage(nppData._nppHandle, NPPM_MENUCOMMAND, 0, IDM_FILE_CLOSE);

                if (IsWindowVisible(focusedView))
                    ::SetFocus(focusedView);

Thank you.

BR

@pnedev
Copy link
Owner

pnedev commented Apr 9, 2016

Hello Yaron,

I'm really curious what is it that bothers you so much with those views :))

My opinion is that the Compare plugin is not Notepad++'s view manager. It's job is to compare and leave the things as close as possible to the state they were before the compare. The user should be aware of the views and how to handle them if he gets to a point where his single view is actually the sub-view. This would mean that he deliberately had moved files to that view and should expect them to remain there after the compare. If he never moves files and uses compare (which is now totally possible with the "Select first" command) he wouldn't bother about views at all.

This is why I don't consider this an issue, just on the contrary - the other behavior might seem as an issue to an experienced user that knows what he's doing.
Do you agree? :)

Thanks.
BR

@Yaron10
Copy link
Author

Yaron10 commented Apr 10, 2016

Hello Pavel,

This would mean that he deliberately had moved files to that view and should expect them to remain there after the compare.

That's the point.
The user has not moved any files, but we have changed the default view from 0 to 1.

STR:

Start NPP.
Open two files and compare.
Files match. Close? - Yes.

Result:
The view is 1.
Why should we do that?

Thank you.
BR

@pnedev pnedev added the bug label Apr 11, 2016
@pnedev
Copy link
Owner

pnedev commented Apr 11, 2016

Hello Yaron,

This definitely needs fixing then. Thanks.

BR

@Yaron10
Copy link
Author

Yaron10 commented Apr 12, 2016

Hello Pavel,

Thank you. I appreciate it.

BR

@pnedev
Copy link
Owner

pnedev commented Apr 12, 2016

Fixed in master branch.

BR

@pnedev pnedev closed this as completed Apr 12, 2016
@Yaron10
Copy link
Author

Yaron10 commented Apr 13, 2016

Hello Pavel,

Thank you very much.

Two related questions:


Start NPP.
Open two matched files.
Move to Other View.
Compare.
Files match. Close? - Yes.

Result:

The view is 1.

Start NPP.
Open two matched files.
Move to Other View.
Activate the file at top.
Compare.
Files match. Close? - Yes.

Result:

The view is 0.

Should the result depend on the currently focused view?
Wouldn't it make more sense to return to MAIN_VIEW in both cases?
You can argue that we don't have a "Restore Point" (i.e. we can't be sure of the view's ID before the Two-Views mode), so why return to MAIN_VIEW?
Well, the user wants to return to Single-View and MAIN_VIEW is default.


Two matched files; Single-View; SUB_VIEW.
Compare.
Files match. Close? - Yes.

Result:

The view is 0.

Shouldn't we restore the original SUB_VIEW?
Is the experienced user so sophisticated and knows we return to MAIN_VIEW because it's the active view when he presses "Yes"? :)

This question is relevant to the code I suggested as well.


Best regards.

@pnedev
Copy link
Owner

pnedev commented Apr 13, 2016

Hello Yaron,

You are right. It seems there is some inconsistency there. I'll check that, thanks for reporting this.

BR

@pnedev pnedev reopened this Apr 13, 2016
@Yaron10
Copy link
Author

Yaron10 commented Apr 13, 2016

Hello Pavel,

Thank you very much.

BR

@pnedev
Copy link
Owner

pnedev commented Apr 18, 2016

Hello Yaron,

Now if equal files are closed (and there are no other files open) the view will always be the main one (0).
Thanks.

BR

@pnedev pnedev closed this as completed Apr 18, 2016
@Yaron10
Copy link
Author

Yaron10 commented Apr 18, 2016

Hello Pavel,

Now if equal files are closed (and there are no other files open) the view will always be the main one (0).

Even if the original view was 1 (which is fine).

Thank you.
BR

@pnedev
Copy link
Owner

pnedev commented Apr 18, 2016

Even if the original view was 1 (which is fine).

Exactly. :)

BR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants