Text cursor not in correct spot on Mac OSX Mavericks.
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
Menu
▾
▴
#1204 Text cursor not in correct spot on Mac OSX Mavericks.
When editing a node or the associated comment, occasionally, the text cursor seems like it's offset from the actual text entry point such that any newly typed text appears in the wrong spot and/or is not visible until additional characters are typed.
When this happens, it's very difficult to edit the node, because added/removed text does not appear where one would expect given the cursor position. Unfortunately, I haven't yet determined a reliable set of conditions under which to reproduce the failure. It happens frequently, but not always. Exiting and restarting Freemind seems to have no impact.
I am using Freemind 1.0.1 on Mac OSX version 10.9.3 with Java(TM) SE Runtime Environment (build 1.8.0_05-b13).
I have the same issue with the same versions except JRE 1.6.0_65-b14 (system default). But I've noticed the same with previous versions of Freemind.
I noticed this with a font size of 12. I'm wondering if it goes away with a font size of 10. It seems to help for me. Was the default 10?
This bug makes Freemind really difficult to use. Frustrating.
I had this problem. I changed the zoom to 100%. No more problem.
(I'm on Ubuntu 14.04, 64-bit. FreeMind version 0.9.0)
I'm using 100% zoom and I still have this problem. Today the cursor is so off FM is almost unusable. Maybe I should try a different font.
I tried a Courier New font which seemed promising but it still had the same problem. It seems it works at first but after edits it can crop-up. I notice it in a non-trival map.
It's more than just a node. Even the menu items from the menu bar respond to the same offset. The first press of the mouse is fine, any movement afterwards while the button is still pressed is skewed, sometimes to a significant amount, sometimes just a little bit.
Changing the window size and/or position effects the offset. It seems enlarging the program upwards increases the offset by the same amount. Then decreasing it back to it's original position fixes it. Sometimes moving the window after it's been resized fixes it.
I'm on LMDE and saw this effect on both 0.9 and 1.01 with Java 1.7 64bit. The problem is on both an empty map and a non-trival one.
Last edit: dpk3062 2014-10-23
I have the same issue. Zooming to 150% seems to have helped but it's certainly detracts from the usability of the mind map. When I'm zoomed in at 100% or less the cursor is in the wrong location and when I try to highlight a word the characters end up all jumbled as as result.
I just noticed that I don't have this problem any more.
I played with a bunch of settings but I think the only useful change was to Monaco 12 font. (I don't think that is the default.)
I'm using 100%.
The only significant bug is sometimes text entry stops. I have to press enter to complete the entry then edit again. Irritating but not too bad.
What is the default FM font?
Scratch my last post - issue has come back with 150% zoom - seems to be a really, "off and on" bug. I believe the default font is SanSerif.
I've attached a screenshot of what I see when I hightlight (note the cut off text around "French") - is this what others are seeing?
Also very frustrated with this bug. Would LOVE to hear of a solution
Hi,
please attach a log file.
TIA, Chris
I've encountered this with Freemind 1.0.1 on Mac OS X 10.10.4.
Screen capture and logfile are attached.
Regards,
Greg
Last edit: Uncle Zhou 2015-07-06
Hi Uncle Zhou,
this is a different issue. Java has problems to calculate the exact width of a text, and some parts are cut off.
In the bug, it is spoken of an editing issue.
Br, Chris
Well, OK, the screen capture I attached doesn't display the editing scenario, but I couldn't get U/I in exactly that state when I took the screen shot because the text field lost the cursor focus.
I'm encountering problems with the editing and display of leaf nodes.
It seems that the root cause for both the display and editing scenarios is the same as what you mentioned: the Java runtime isn't calculating the text width properly causing the text to be cut off when displayed and the text edit cursor to be in the wrong place when the field is open for editing.
Notes:
1) It's only a problem for 'leaf' nodes; there's no problem editing/displaying the text of non-leaf nodes.
2) As a workaround, I've installed the "MAC OS X 10.6.8" "All-inclusive version". The editing of leaf nodes is usable, but the overall quality of the graphical rendering is noticeably inferior.
Last edit: Uncle Zhou 2015-07-12
Same issue here with OSX 10.10.5 (Yosemite) and version 1.1.0 beta 2. Cursor positions are better now when editing a node directly (only very slightly mispositioned).
When editing a node in the "Edit long node" dialog, its still broken based on which of the two (?) dialogs is used for editing:
The dialog that displays the "Layout view" and "Html code view" Tabs (along with the text formatting options) is still broken.
The second "Edit long node" dialog (the one that lacks the tabs and does not supply any editing options) seems to work well - although the cursor position is still slighty misplaced by a few pixels short before the text breaks into a new line.
Still having this problem. It's 2019, is anyone working on this anymore? Freemind is almost unusable for me on Mac because of this issue.
Freemind is for the most part working fine for me still after having this problem. Did you try my set-up in my last post?
It goes away with Monaco font, I think, but I don't like that font at all. It behaves differently with diffferent fonts, and even depends on the specific letters typed. I typed an entire line in Sans Serif with no problem, changed the leading character from "L" to "O", and it was totally out-of-sync when I moved to the end of the line. It's as if the font spacing is off. The longer I type, the more out-of-sync it gets, until the cursor is over a character behind where it should be. It would actually be better not to have a cursor at all.
This is not a problem on Windows, so why should it be a problem with Mac? I've been coding in Java for more than 2 decades, and have never seen this problem before.
I suspect the problem is with a proportional font vs. a monospaced font (like Monaco). It is possible switching to any monospaced font will work-around this problem.
Also, I don't think there is any active work on Freemind anymore. It is a wonderful program (if working for you) but as a free program it was a labor of love. Maybe someone could inherit the project and carry the torch.
The FreePlane fork can import FreeMind files and is being actively maintained.