show the current zoom

Alan Kilborn

@Snabel42 said in show the current zoom:

I was also considering the previously mentioned feature of allowing zoom to be synced between multiple tabs shown side-by-side. Side-by-side comparison views of multiple tabs is one scenario where I’d normally find myself wanting to “see” the zoom. I can usually sync up the zoom manually, but usually by overshooting the zoom in one of the tabs, then adjusting back to match the second tab.

Here’s a script that will keep the zoom levels for both views the same. I call the script ZoomLevelKeepBothViewsSynched.py.

# -*- coding: utf-8 -*-
from __future__ import print_function

#########################################
#
#  ZoomLevelKeepBothViewsSynched (ZLKBVS)
#
#########################################

# references:
#  https://community.notepad-plus-plus.org/topic/25844
#  for newbie info on PythonScripts, see https://community.notepad-plus-plus.org/topic/23039/faq-desk-how-to-install-and-run-a-script-in-pythonscript

#-------------------------------------------------------------------------------

from Npp import *

#-------------------------------------------------------------------------------

try:
    editor1.hwnd
except AttributeError:
    # running PS2
    import ctypes
    user32 = ctypes.WinDLL('user32')
    notepad.hwnd = user32.FindWindowW(u'Notepad++', None)
    editor1.hwnd = user32.FindWindowExW(notepad.hwnd, None, u'Scintilla', None)

assert editor1.hwnd

#-------------------------------------------------------------------------------

class ZLKBVS(object):

    def __init__(self):
        editor.callback(self.zoom_callback, [SCINTILLANOTIFICATION.ZOOM])
        self.zoom_callback( { 'hwndFrom' : editor } )

    def zoom_callback(self, args):
        if not notepad.isSingleView():
            other_editor = editor2 if args['hwndFrom'] == editor1.hwnd else editor1
            this_editor = editor2 if other_editor == editor1 else editor1
            other_editor.setZoom(this_editor.getZoom())

#-------------------------------------------------------------------------------

# to run via another file, e.g., (user) startup.py, put these lines (uncommented and unindented) in that file:
#  import ZoomLevelKeepBothViewsSynched
#  zlkbvs = ZoomLevelKeepBothViewsSynched.ZLKBVS()
# also note: need to make sure that "Initialisation" for "Python Script Configuration" is set to "ATSTARTUP" and not "LAZY".

if __name__ == '__main__':
    try:
        zlkbvs
    except NameError:
        zlkbvs = ZLKBVS()

Andi Kiissel

@Alan-Kilborn said in show the current zoom:

Here’s a script that will keep the zoom levels for both views the same.

These five rows in startup.py do the same thing for me:

def syncZoomLevel(args):
    level = editor.getZoom()
    editor1.setZoom(level)
    editor2.setZoom(level)
editor.callback(syncZoomLevel, [SCINTILLANOTIFICATION.ZOOM])

PeterJones

@Andi-Kiissel ,

Your super-simple script assumes that the last tab you clicked in (editor) is the same editor you are zooming. But it is possible to click in View1 and zoom in View2, because it will zoom whichever tab the mouse pointer is hovering over when you use Ctrl+Scrollwheel, even if you haven’t clicked in that view

And because of that, Alan had to add some checks to see which view was actually being zoomed (not which has the last click), and that process is hampered by PythonScript 2 not including the .hwnd, whereas PythonScript 3 has the .hwnd already. (Update 3: … hence needing the ctypes and hwnd-grabber at the beginning)

And as we regulars often do, he wrapped it in a class, so that function and variable names in his script won’t clobber the function and variable names from other scripts.

Thus, as often happens: when you just try to “get it done”, it’s pretty simple and can be a few lines of code; but when you then try making it good enough for publishing, to cover edge cases, the code becomes more complicated. This Is The Way.

----

Update 1: Yep, I just confirmed: when I ran your script, clicked in View1, and tried to scrollwheel-zoom while the mouse cursor was still over View1, it correctly zoomed both Views. But if I move the mouse cursor over view2 – without clicking, so view1 is still active – then when I try to scroll-zoom, view2 briefly shows up as zoomed, but then jumps back to no-zoom.

Update 2: Yep, when I instead run Alan’s, whether my scrollwheel-zoom is over view1 or view2, both views correctly scroll as expected

mpheath

@PeterJones Any name can be clobbered. Minimal names in the global namespace is a good idea. So I guess no names is the least to be clobbered. Once the name has been used to register the object with the callback then the name is not needed anymore unless it is wanted to unregister the callback which is probably not often done.

Classes can have multiple methods which is why I consider that many users choose to use them. Functions also can be suitable for this task as it is not that complex. Functions can be as useful as classes and each has their role. So I am posting a function so please do not clobber me for choosing a function.

This function can sync the zoom levels and can be done without .hwnd so can be compatible with PythonScript 2 and PythonScript 3. Keeping track of the zoom levels and adjusting the levels is how it operates.

from Npp import editor, editor2, SCINTILLANOTIFICATION

def _():
    zoomLevels = [editor1.getZoom(), editor2.getZoom()]

    def zoomLevel(args):
        if editor1.getZoom() != zoomLevels[0]:
            level = editor1.getZoom()
            editor2.setZoom(level)
            zoomLevels[0] = level
        elif editor2.getZoom() != zoomLevels[1]:
            level = editor2.getZoom()
            editor1.setZoom(level)
            zoomLevels[1] = level

    return zoomLevel

editor.callback(_(), [SCINTILLANOTIFICATION.ZOOM])
del _

This is basically a nameless enclosure function as _ is usually treated as a temporary name. Enclosed to keep zoomLevels available to only the inner nested function zoomLevel. The _ name is deleted after registering the callback so the global namespace has no additional names. This code can be added to the startup script and that is what I would insert it as that is where I have tested it.

Alan Kilborn

@mpheath said:

I guess no names is the least to be clobbered.

But it is probably considered “extreme” to go to that length.
It isn’t a terrible thing to introduce one or two new names per script, if the names are reasonably unique (as mine tend to be).
Confession: My script directly above also introduces a user32 name. This is to support PythonScript v2, which, since I don’t use that, was a last minute add-on concession.

…and can be done without .hwnd so can be compatible with PythonScript 2 and PythonScript 3

I write exclusively in PS3 these days. Often I make the concession to publish a script so that it is compatible with both, but I don’t think in terms of “how do I make this the most efficient” in order to provide this support.

Probably, at some point, I will not bother to provide PS2 compatible code in scripts I publish.

Functions also can be suitable for this task as it is not that complex.

When I’m scripting, I don’t start out by judging: “Is this task complex enough to deserve a class wrapper?” or equivalently “Is this task simple enough to just be a function?”. As I have a script that generates a new script’s skeleton, I just go with it and everything gets a class.

I am posting a function so please do not clobber me for choosing a function.

Not clobbering, just commenting. :-)

PeterJones

@mpheath ,

I am posting a function so please do not clobber me for choosing a function.

Apparently, I did not communicate very clearly, since you think that was what I was saying. Sorry.

My point about “clobbering” was the least important point in my message (and the point least supported by data). It was meant more as an observational example of why one might wrap things in a class: but your reason (multiple functions) and Alan’s reason (templated code) are both better justifications for it than my <theThing>it’s not clobbering time</theThing> semi-reason. :-)

I come from Perl’s TIMTOWTDI philosophy, so I very much encourage and appreciate different approaches. And I like your solution for avoiding the need for .hwnd – tracking the state, so you can tell which was changed and thus which to replicate to the other, is a great idea.

and @Alan-Kilborn said,

I write exclusively in PS3 these days.

I just wish PS3 would stop calling itself “alpha” and release to Plugins Admin, to make it easier for everyone to make that transition.

mpheath

@PeterJones said in show the current zoom:

Apparently, I did not communicate very clearly, since you think that was what I was saying. Sorry.

My point about “clobbering” was the least important point in my message (and the point least supported by data)…

@Andi-Kiissel had only one name and yet was warned about clobbering. I tried for less as changing the name to _ was quite easy. Thanks for apologizing and clarifying your intentions.

I come from Perl’s TIMTOWTDI philosophy, so I very much encourage and appreciate different approaches. And I like your solution for avoiding the need for .hwnd – tracking the state, so you can tell which was changed and thus which to replicate to the other, is a great idea.

I see here https://perl.fandom.com/wiki/TIMTOWTDI about “only one option for not equals operator”. Well, Python 2 vs Python 3 compatiibility is usually more of a concern than the single != operator IMO.

I just wish PS3 would stop calling itself “alpha” and release to Plugins Admin, to make it easier for everyone to make that transition.

Absolutely. I cater for PS2 as it is the Plugin Admin default. The Plugin Admin could offer both versions to keep everyone happy. Python 2 is backwards for me as I started with early Python 3 and so I do minor hacks to make PS3 code work for the PS2 users.

@Alan-Kilborn said in show the current zoom:

But it is probably considered “extreme” to go to that length.

To be open minded about everything is to include the “extreme”. So thanks for the complement.

As for “show the current zoom”, I like the KISS concept. Too much stuff to view which can make you can miss what is important. I am sure there are others who would prefer Notepad++ to look like a cockpit of a 747 jumbo jet. I am usually busy doing something so viewing the zoom level is not a concern for me. Synchronizing zoom with 2 panes is a tedious task so I saw value with another script to choose from that might help.

Alan Kilborn

@mpheath said in show the current zoom:

I am sure there are others who would prefer Notepad++ to look like a cockpit of a 747 jumbo jet.

Such a statement always reminds me of this ISSUE, maybe because of this COMMENT from that issue. :-)

PeterJones

Unimportant aside:

@mpheath said in show the current zoom:

I see here https://perl.fandom.com/wiki/TIMTOWTDI about “only one option for not equals operator”.

Ugh, that page does an awful job of describing the TIMTOWTDI philosophy – it makes it seem like it’s a petty reactionism to Python, but that philosophy was actually baked into Perl from the beginning, without any thought to Python (which was introduced a couple years after Perl was initially released). Given that it had two sentences about TIMTOWTDI, two sentences about how “unreadable” Perl is, and a whole paragraph describing Python as the antithesis, I get the feeling that the author of that article may have been a critic, not a fan, of Perl.

And I didn’t make either my original TIMTOWTDI comment, nor this response paragraph, to try to start a language-war with the proponents of Python. I personally use Perl more than I do Python (because PythonScript is my only use of Python, whereas I’ve been doing hobbiest projects in Perl since the 90s) – but it’s not because I think Perl is “better” than Python – they are different, and each have their pros and cons – it’s just that I’m more familiar and comfortable with Perl. I actually brought up TIMTOWTDI to say that I actually appreciate different perspectives and design choices in coding, and I usually learn something by seeing how someone else would approach a problem differently than I would.

Alan Kilborn

@PeterJones said in show the current zoom:

try to start a language-war with the proponents of Python

No saber-rattling detected…or intended with the following:

My history is Perl first, then Python – standalone, not PythonScript.
And both were for text processing type things; for other things I’ve always been a C/C++ person (mainly C).
The old command-line guy in me really liked Perl’s quirkiness, perhaps readers know what I mean … command.com’s interpreter really had/has a bunch of quirks.

However, as much as I liked Perl at the time, I found that if I “put it down” for a while, it was really hard to come back to it (due to ever-advancing age perhaps). With Python, I found it just sort of flows from the fingertips, so to say, and was easy to come back to after some time off. Aside from maintenance of some large scripts I wrote and still use, I haven’t done any new Perl in many years (perhaps a decade?).

I was rather pleased when I discovered Notepad++ and saw that its most popular scripting plugin was Python-based. (This might be the only sentence in the post that is on-topic).

But overall, I see no need for “language wars”.
I’m reminded of the quote from the Lord of the Rings (movies): “Go off and die in whatever manner most suits you” (or something like that).
In this case, “Go off and use whatever language most suits you, as long as it gets your job done”.