Program doesn't remember grid size

[ReFreezed]

Version: 1.18.0
OS: Windows 7, 64-bit

Closing the program and opening it again resets the grid size to 0. I'm guessing this value is supposed to be saved per file, but it doesn't seem to be saved in any way at the moment.

[juzzlin]

It's not saved by design, because the grid size is not a property of the mind map - just a drawing aid. One can change the grid size setting multiple times while making a mind map. I'm not sure how this should be done. Maybe Heimer could still remember the latest value..?

[ReFreezed]

When I started the program for the first time I wanted the placed nodes to be ordered on a nice grid, so I chose an appropriate grid size, not intending to ever change it again as that would ruin the existing grid. I think it's weird that every other property (i.e. those listed next to the grid size) is remembered but not the grid size.

Anyway, making the program remember the last value sounds good to me at least.

[juzzlin]

Yes, I see.

The grid size is some kind of a meta property, because it's not directly visible in the mind map like corner radius. Also the possibly existing nodes are not forced to any grid size when the grid size changes. An automatic snap-to-grid wouldn't always behave like expected or desired.

Nice to have some opinions on this as I have been struggling with the implementation of this setting from the beginning :)

[ReFreezed]

I would argue that the grid size IS directly visible in the map. If the nodes visually look like they're on a grid of a certain size, then there's probably an underlying grid of that certain size that the author intended to be there, you know?

Additionally, I'm not sure why you would change the grid size while working in the same file. Isn't the purpose of the grid to make things look aligned? If you change the grid size then new/newly moved nodes won't be aligned to the existing ones.

[juzzlin]

I would argue that the grid size IS directly visible in the map. If the nodes visually look like they're on a grid of a certain size, then there's probably an underlying grid of that certain size that the author intended to be there, you know?

I understand your point of view, yes. But then again there are no grid sizes saved to SVG or JPEG when you use Gimp or InkScape, right?

Additionally, I'm not sure why you would change the grid size while working in the same file. Isn't the purpose of the grid to make things look aligned? If you change the grid size then new/newly moved nodes won't be aligned to the existing ones.

Well, someone might like to apply the grid only on some specific portion of the design. I have done that myself. Anyway, my point is more from software engineer's perspective and I want to avoid things that are not well-defined or could be confusing. The thing is that now you CAN change the grid size as many times as you wish. You can do this with every drawing tool I know. That leads to an obvious logical problem if we want to save only one grid size in the actual mind map file.

Remembering - but not saving to the file - the latest setting would be (in my opinion) a feasible solution for now.

[ReFreezed]

Well, I'm often using the grid setting in Photoshop when creating art for games and I think it's a flaw that the grid size isn't saved per file as I want different values for different things I'm drawing (e.g. a tileset for a pixel art game, or a set of GUI icons of the same size). What's "well-defined" in this case isn't helpful when I'm trying to do actual work on many different things (I now have to constantly change the grid size). Not that I think it should matter that much what other programs are doing as Heimer is not Gimp or whatever, and the savefiles are of a unique format - not SVG/JPEG.

Also, I feel there's an assumption here that the people who use this program are the same people who use Gimp etc. which I don't know how true that is. Heimer should focus on mind map things, not general raster/vector graphics editing software things, in my humble opinion.

I do think the program remembering the last value is good enough though.

[juzzlin]

Fixed in 340530b. Thanks for reporting!