edgar

Seems to work great! Many thanks!

Many of the tools use the <ENTER> key as shortcut to "Finish" the tool's action. The Text tool has such a "Finish" button and it's pop up suggests that the <ENTER> key be used to "Finish" processing keyboard input as text. There's a collision here - the Text tool accepts the <ENTER> key as a "new line" so that multi-line text may be (appropriately) left justified. It seems that it is impossible for non-mouse (keyboard) users to escape the Text tool. I understand that for continuity it would be nice that "Finish" be implemented via the <ENTER> key, but in the case of the Text tool the value of its use for multi-line text far surpasses the value of such continuity. Since the user has no method to modify keyboard shortcuts, I propose that for this special case, the Text tool's "Finish" button get a non-printing shortcut (<ESCAPE>, <F#> etc.) and that the tooltip reflect this.

On the status bar, just to the right of the drawing dimensions, is a readout (constantly updating) displaying the drawing-relative location of the mouse pointer. The numeric display reads something like: d, d or -d, dd; where the X and/or Y value might be anywhere from -ddddd (imagine a six monitor 4K ultra HD system with all six monitors in a row or column) to d. If the overall display string gets more than dd, dd (-d, ddd etc.) characters in length little icon gets partially or completely overdrawn. I suspect that this might be sensitive based on some user-modified OS default.

4.0.13 fixed this issue for a number of dialogs but others remain broken (e.g. the color palette "Colors" as well as various built-in Adjustment & Effect dialogs).

Subscribing to topic…

On my 1920 X 1080 monitor the various cursors are so small as to be almost invisible. Even higher resolution monitors are becoming quite common. I could not find any .cur files in my Paint.net folder. Are they embedded in the executable?

Exactly - I have changed the menu font (family and size) for readability. Changing the DPI messes up many other programs and negates the benefits of my 65" 1920X1080 monitors. You said "For now" - does that mean you hope to make your dialogs font sensitive? I have reverted to 4.0.10 (which seems to ignore the OS specified fonts). BTW, I am a programmer and technical document editor/author; years ago I worked on Microsoft's Accessibility Team where (among other things) I worked on application font sensitivity - especially where it impacted folks with low visual acuity. I have had a couple of patches applied on the wxWidgets code and done extensive work on the code and technical documentation of Audacity. I use paint.net a lot (probably average 2-3 hours per day) and would really enjoy being able to help you with your code and, to a lesser extent, documentation.

Note that the widgets in the dialog overlap making some Illegible and others inaccessible. The previous version (4.0.10? - I might have missed 4.0.11 if it was only out for a couple of days) did not exhibit this behavior.

The problem persists after quite a few reboots; see previous post for workaround. Diagnostics: Application paint.net 4.0.3 (Final 4.3.5316.40022) Build Date Tuesday, July 22, 2014 Hardware accelerated rendering (GPU) True Animations True DPI 96.00 (1.00x scale) Language en-US OS Windows 7 Service Pack 1 (6.1.7601.65536) .NET Runtime 4.0.30319.18444 Physical Memory 8,191 MB CPU Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz Architecture x64 (64-bit) Process Mode 64-bit Speed ~3005 MHz Cores / Threads 4 Features DEP, SSE, SSE2, SSE3, SSSE3, SSE4_1, XSAVE Video Card AMD Radeon HD 6700 Series Dedicated Video RAM 1,013 MB Dedicated System RAM 0 MB Shared System RAM 3,839 MB Vendor ID 0x1002 Device ID 0x68BA Subsystem ID 0xE144174B Revision 0 LUID 0x0000C456 Flags None Outputs 2 Interesting question "what language". I use Dragon NaturallySpeaking Professional's scripting language to control almost all aspects of my computer interaction. I have medical issues which limit (but not preclude) the use of keyboard & mouse. To be on the safe side, before posting originally, I made sure to try direct keyboard input completely bypassing any scripting, the results were the same in either case.

This was enough of a hint for me to figure out a (at least currently) successful workaround. From what I can determine the problem is a collision between the Tool floating-dialog-style toolbar & the toolbar-in-the-menu-area-style. To conserve screen real estate I keep the dialog-style turned off and almost exclusively use keyboard shortcuts; when I (rarely) need one of the tools for which I do not recall keyboard shortcut I use the new toolbar. After a while of launching and exiting numerous times during the day it appears that the keyboard shortcuts are forgotten. By opening the dialog-style toolbar the keyboard shortcuts are remembered and I can close the dialog-style toolbar and they continue to be remembered (at least for a while).

I used to be able to press the <z> key to activate the zoom tool, similarly <e> to activate the eraser tool etc. The shortcuts no longer show up in the tooltips. Is this a known issue (and if so is it fixed in the current beta) or is it likely to be a problem with my setup?