Suggestion: Zoom in on pointed-to area

[anderpainter]

When you point to a particular place in an image and zoom in, P.n (usually? sometimes?) keeps that place from going offscreen.

 

However, it'd be very useful if we could hold a certain key combination (e.g. Ctrl+Alt) while zooming, so P.n treated the pointer's location as the center of the zoom—assuming we'd pointed to the place where we wanted to examine and/or edit something and wanted to keep as much of that area visible as possible.

 

To do this, as it zoomed in, P.n would gradually move the pointed-to place toward the center of the editing area:

 

 

 

 

Eventually that place would be centered, and further zooming would zoom in on the center of the editing area.

 

Programmatically, this would require P.n to determine:

 

• When the pointed-to place should become centered (e.g. a fixed percentage of the range between the present view and maximum zoom)
• The incremental amounts of horizontal and vertical shift, by dividing the distances between the pointer's x and y coordinates by the amount of zoom increments until the pointed-to location is centered.

 

Not only would this ability keep the pointed-to area as visible as possible, it'd avoid obscuring it with open palettes*—which currently requires us to manually scroll the image away from them, or drag the palettes out of the way, to see what we're doing.

 

* Assuming the user didn't leave a palette in the center of the editing area, of course... If they did, they'd have only themselves to blame.  :?)

 

[BoltBait]

Did you try holding down the Ctrl key while using the mouse scroll wheel?

[anderpainter]

On 9/25/2016 at 3:08 PM, BoltBait said:

Did you try holding down the Ctrl key while using the mouse scroll wheel?

 

Yes; that's what I was referring to in my first sentence. If you zoom in without holding Ctrl, P.n just zooms on the center of the current view, which I suppose it should.

 

However, if you've just opened a dialog box to adjust image properties or apply an effect—and it's appeared smack in the middle of the editing area, as it does every... time... you... open... it, rather than where you left it the last time you used it (even during the same session, because we're obviously much too simpleminded to realize we've opened something if it doesn't appear right in front of us)—zoom is disabled. So you can't even zoom in so the dialog box you just opened obscures even more of your image.

 

Okay, I know I'm engaging in topic drift here. But the always-centered-dialog-box thing is so '90s, I never pass up a chance to kvetch about it. (You can't see me, but I'm also shaking my head in continued bafflement at the developers's apparent apathy about such a pointlessly annoying flaw in such an otherwise excellent program.)

 

 

Edited September 27, 2016 by anderpainter

[BoltBait]

43 minutes ago, anderpainter said:

Okay, I know I'm engaging in topic drift here. But the always-centered-dialog-box thing is so '90s, I never pass up a chance to kvetch about it. (You can't see me, but I'm also shaking my head in continued bafflement at the developers's apparent apathy about such a pointlessly annoying flaw in such an otherwise excellent program.)

 

I wouldn't exactly call this a flaw.  Opening a child window programmatically, Windows offers several options:

 

• Windows Default - Windows determines where the window opens.  It never opens in the same place. Windows generally open in a cascade (overlapping) style.  Under some circumstances the child window could open in a different screen as the application that opened it.  Do you really trust Windows to choose the proper place to open your child window?  I don't.  Handled with one line of code.
• Center Screen -  The window opens centered within the screen regardless of where the parent window is located.  The window may open far away from where the parent window is located. Handled with one line of code.
• Center Parent -  Generally preferred. The window opens centered within the parent window. Handled with one line of code.
• Manual - Window opens in a specific position.  This can be relative to the screen coordinates or the parent window coordinates. The user has to write LOTS of code to manage this.  You have to handle the case where the window will show up off the screen because the main window moved, or the screen resolution has changed, etc.  You also need to store the location in the registry so it will persist from run to run.  And, you better handle Large Fonts Mode...

 

No matter which method Rick chooses, someone is going to hate it.  SO, he can choose to write 1 line of code or a TON of code that needs testing under various conditions and operating systems.... and some people will hate it.

 

As a developer, I think he's made the right choice.   (And, yes, I move the dialog boxes out of the way all the time.)

[anderpainter]

On 9/25/2016 at 3:08 PM, BoltBait said:

[what you said]

 

 

The first three window-opening behaviours you described are just pre-defined for convenience. I can't think of anyone (anyone else, that is) who'd bother using them in this kind of app, where you're continually opening and using many small dialog boxes as part of your actual work, rather than just opening them now and then to change settings.

 

People who work with graphics like to set up their own workspaces to accommodate how they work best. This includes arranging the positions of palettes and dialog boxes. For this reason, maintaining last-opened form positions is the absolute norm in all kinds of apps involving image manipulation.

 

Besides, P.n's palettes already "remember" where you positioned them. So obviously Rick knows how to record form positions during and between sessions, and to perform a rudimentary check (and it really is simple; I've coded it myself) to be sure the user's screen resolution no longer accommodates a saved form position. This is not a matter of "writing LOTS of code"—all Rick need do is copy and paste some of his own code and apply it to the dialog boxes, too.

 

I'm not even asking that persistent form positions be the default behaviour (although it is, almost universally, elsewhere). The default can still be "Always open every darn dialog box right in the middle of the screen, every time, so you always have to drag it out of the way." That's great—a charming P.n tradition or whatever. Just please add the option to make the dialog boxes behave like the palettes, that's all I ask. This doesn't seem unreasonable. It seems more like an appeal for normalcy.

Edited September 28, 2016 by anderpainter

[anderpainter]

If P.n were open source, I'd add the code myself. As mom would've said, "It isn't rocket surgery."

 

[BoltBait]

13 minutes ago, anderpainter said:

I'm not even asking that persistent form positions be the default behaviour

 

Now, you want two different behaviors?!  That's even MORE code!

 

You're right that Rick has written a bunch of this code... but, you know what? Sometimes those windows get lost!

[BoltBait]

8 minutes ago, anderpainter said:

If P.n were open source, I'd add the code myself. As mom would've said, "It isn't rocket surgery."

 

 

Many plugins ARE open source.  You are free to recompile them for yourself and add in the necessary code to open the window where ever you want.

 

In fact, HERE is the source code to my Hue/Sat+ plugin.  Feel free to start there.  Post the source code when you're done so that everyone can benefit.

 

[anderpainter]

3 minutes ago, BoltBait said:

 

 

This forum has a rather draconian quoting style, so I'm going to wing it here. (Hey, we're creative types, right?)

 

BoltBait > Now, you want two different behaviors?!  That's even MORE code!

 

My pointer-centered zoom request is new. I've been carping about P.n's always-in-your-face dialog boxes for years now. I don't have much hope that'll ever be fixed. But P.n is still my favourite graphics editor, and I must cope with that frustration each time I use it—so I say something about it every few months or so. And since I was posting here anyway...

 

Ironically, neither of these changes are major modifications. As I've pointed out, Rick has already coded P.n's palettes to behave this way. And like persistent form positions, pointer-centric zooming has been default graphics-app behaviour for many, many years; you can probably just copy and paste that code from any number of programming resources.

 

BoltBait > You're right that Rick has written a bunch of this code... but, you know what? Sometimes those windows get lost!

 

Then why don't the palettes "get lost"? I've haven't seen that happen yet, have you? We're talking about the exact same functionality. Why Rick thinks one is worthwhile and not the other is beyond me.

 

BoltBait > Many plugins ARE open source.  You are free to recompile them for yourself and add in the necessary code to open the window where ever you want.

 

Really? I thought plugins just added extra functions. You're saying you can use them to affect P.n's default behaviours? That seems like an entirely different thing. You've written plugins, though (I've used and enjoyed many of them, thanks!)—so if you say it's possible, it must be.

 

[BoltBait]

2 minutes ago, anderpainter said:

Then why don't the palettes "get lost"? I've haven't seen that happen yet, have you? We're talking about the exact same functionality. Why Rick thinks one is worthwhile and not the other is beyond me.

 

I've never had the docker windows get lost.  But, I've seen tons of posts from people that have lost them.  Until recently, it was a pain to get them back (you had to use regedit).

 

I could rewrite my plugins to always show up where you left them, but WHAT A PAIN!  If you want that functionality, like I said, my source code is posted above, go for it!

[BoltBait]

29 minutes ago, anderpainter said:

This forum has a rather draconian quoting style

 

Actually, the quoting system is pretty cool.  All you need to do is select the part of my message you want to quote and a little bubble shows up. Click the bubble and the quote happens.

 

 

By repeating this action, you can get multiple quotes in the reply box.

 

[toe_head2001]

42 minutes ago, anderpainter said:

You're saying you can use them to affect P.n's default behaviours?

No, you misunderstood what BoltBait said. What he was saying is that you could modify a plugin so that it (that specific plugin, and that specific plugin only) opens its dialog in a different location.

 

For clarification, plugins can only add FileTypes, and modify pixels on the canvas/selection. No changing the behavior of paint.net.

[anderpainter]

BoltBait > I've never had the docker windows get lost.  But, I've seen tons of posts from people that have lost them.  Until recently, it was a pain to get them back (you had to use regedit)... I could rewrite my plugins to always show up where you left them, but WHAT A PAIN! ...

 

With all due respect, the process is pretty straightforward:

 

1. When user closes a dialog box, record its x and y positions.

 

2. When the user opens a dialog box, check the user's current screen resolution (people do change them) and the box's dimensions, as reported by your IDE (which should automatically reflect its size in the current resolution) and see if placing the at the recorded coordinates would cause any or all of it to appear off-screen. If it would, decrease the box's x and/or y coordinates to accommodate its width and/or height. If it wouldn't, just restore the box.

 

In other words, before you open a dialog box, be sure you're not placing any of it off-screen. As long as the user hasn't set their screen resolution smaller than the dialog box itself, there shouldn't be any problems.  :?)

 

BoltBait > Actually, the quoting system is pretty cool.  All you need to do is select the part of my message you want to quote and a little bubble shows up. Click the bubble and the quote happens.

 

Hey, that is cool! I'll have to try it next time.

 

anderpainter > You're saying you can use them to affect P.n's default behaviours?

 

toe_head2001 > No, you misunderstood what BoltBait said. What he was saying is that you could modify a plugin so that it (that specific plugin, and that specific plugin only) opens its dialog in a different location.

 

Yes, I'd assume the plugin language would let you determine where your forms opened—but unfortunately, that doesn't address el problema aquí—unless you're suggesting I write my own versions of all of P.n's features. I'm a bit short on time to take on something like that.

Edited September 28, 2016 by anderpainter

[anderpainter]

My teenage son's wondering if it's possible to write a plugin that'll make P.n do celebrity impressions.

[Eli]

3 hours ago, anderpainter said:

My teenage son's wondering if it's possible to write a plugin that'll make P.n do celebrity impressions.

What is a celebrity impression? Do you mean interchanging faces as I have seen people do with their selfies on the phone? That would be fun.!