Problem Summary: Cursor rendering in text nodes is inconsistently offset from the real location of the cursor.
Problem Description: The cursor in a text node will render in various locations relative to its real location. The variance ranges from being rendered on top of a character to appearing to be to the left or right of the character. In most cases (say, 90%+), the actual cursor location will be offset to the left by 1-2 characters from the rendered location.
This bug makes FreeMind unusable. Entering and editing text is now a maddening process, because it's never clear which character will be deleted, or where characters will be inserted.
FreeMind Version 1: 1.0.1 JRE bundle installed from FreeMind_1.0.1.dmg.
FreeMind Version 2: 1.0.1 JRE unbundled version. The unbundled version was run with Apple's JRE version 1.6 installed from JavaForOSX2014-001.dmg:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
HW: MacBook Pro (Retina, 15-inch, Mid 2014, AKA MacBookPro11,2), Core i7 2.2GHz, 16 GB RAM, Intel Iris Pro 1536 MB
OS/SW: OS X Yosemite 10.10.3
Please let me know if you need any additional information, or if I can assist with debugging.
Thanks.
-Rob
I tested FreeMind 0.9.0 on the same system described in the ticket. The cursor works properly with both versions of FreeMind 0.9.0. However, new node insertion via the TAB key does not work when running the standalone version of FreeMind 0.9.0 with the OS X version of Java 1.6.0_65 supplied by Apple.
Tests
FreeMind 0.9.0 with bundled JRE
FreeMind 0.9.0 with no bundled JRE
Last edit: Rob 2015-04-23
This problem is still occurring on the following HW/OS combination:
FreeMind Version 1: 1.0.1 JRE bundle installed from FreeMind_1.0.1.dmg
HW: MacBook Pro (Retina, 15-inch, Mid 2015, AKA MacBookPro11,5), Core i7 2.8GHz, 16 GB RAM, AMD Radeon R9 M370X + Intel Iris Pro 1536 MB)
OS/SW: OS X El Capitan 10.11.6
I can confirm that Martin Llofriu's workaround works for my problem, too.
My Original Setting: Tools -> Preferences -> Appearance: Default
Workaround 1 (Martin's workaround): Tools -> Preferences -> Appearance: Metal
Result 1: Better cursor display behavior, look and feel changes, and FreeMind menu moves to the FreeMind window.
EDITED TO ADD: Workaround 2 is not a consistent workaound. See next comment
Workaround 2: Tools -> Preferences -> Appearance: Mac OS X
Result 2: Better cursor display behavior, look and feel remains OS X, and FreeMind menu remains in the standard OS X location (can't recall the UI element name; sorry).
Thanks to Martin for the workaround!
Last edit: Rob 2017-02-03
Update: Workaround 2 as described above is not a consistent workaround.
Workaround 2: Tools -> Preferences -> Appearance: Mac OS X
Result 2: Inconsistent results. Initial use after change and restart showed better cursor display behavior, but subsequent restarts showed the field rendering problem had returned.
This happens for me only when editing a long node. This has been a pain over the last few years, and I still haven't found a mind-mapping solution better than freemind. I'm willing to pay $150 to the developer that pushes the code that fixes this bug, by paypal or bitcoin.
Last edit: Jacob Lyles 2017-11-01
Increasing bug bounty to $250.
If you're still interested, it isn't a fix so there's no bounty. That said, I just recently went to a new iMac 27" with a retina display and have experienced the same garbage as you. I tried the "Appearance" idea and it didn't work. While I prefer the default font, I switched to Monaco as my new default font, and it seems to work fine. I have both simple and complicated mind maps, and they seem to look fine. Cursor position is correct whether in creation or in long edit. It's not a great font, but it works.
On MacOs, editing Info.plist as described here fixed it: https://sourceforge.net/p/freemind/bugs/1249/#a62b. Now using latest Java8 jdk.
Last edit: FXG 2018-03-19
I believe the following helps to understand when the problem started on osx, and how to make the workaround work:
- problem unknown with osx High Sierra and before
- problem does occur with Mojave and later
- the proposed workaround (switching to the Monaco font does help IF
a) you use Monaco, with size of 12 pts. AND do never use ZOOM
b) select Monaco as your default font in all physical styles
c) this is done via menu > format > phys. styles > manage patterns ...
The last step is needed since the FM preferences do not allow to select a default font.
I haven't tried the solution which requires changing the JAVA RE on my mac, which may be a better solution if it works.