TreeThing

[Ramah]

Actually, getCanonicalPath and getPath in this respect work the same for me. The problem was as you say, extracting the path from the filename irrespective of what I used to get it. getParent() works great though for returning the path alone. In conjunction with a "/" when stitching them back together it should now hopefully work ok on a mac.

Edit: Heh. Just went through the rest of the program to adjust all the other file saving and reading that goes on from the Windows standard and it turns out that in all other places I had used "/", hence the program only falling over on the mac in that one place.... So... D'oh! for doing that particular one like that. :s

[Ramah]

Ok then, another fixed version. This one should work.

EDIT: Removed file. Newer version later in thread

[jfrazierjr]

The f.getName without the substring removal doesn't return the base name... well, it does but if the user enters ".png" on the end then the filename would end up as: forest_Trees.png.png which is a bit crap. But you are right to question why it does it for .png as someone may be as likely to add .jpg on the end I guess. Changing it to a substring up to firstIndexOf "." would make more sense.

Not necessarily. It is typically common place in *nix for files to have multiple "dot"(.) in the filename, BUT since you already test for endsWith(".png") anyway, you should already be safe. Sorry..I thought you were trying to do something else AND I was also confusing java with a perl module( that does all of that fiddly breaking down crap for you).


Also, on a side note, you might want to look into using the FileNameFilter so you can have it just show .png files to begin with and let the OS deal with the whole (is it showing file extensions or not). Typically, even if someone types in "forest_Trees.png" in a file save dialog, IF there is a file filter, you will always get back EXACTLY "forest_Trees.png", at least in my experience. Now... there is one BIG caveat to this, and that is that if the user actually types in "forest_Trees.png" into the dialog box AND also puts quotes around it, in which case it takes the literal input string and then adds the FileNameFilter to the end. Of course, if someone REALLY wants to do that, then they should know what they are doing anyway since it's far beyond be realm of what a "normal" person would do.

I hope that makes sense.

[Ramah]

It already uses a filefilter to only show png's. This is just the save option where it is attempting to keep the filename entered reasonably clean. Anyway, it seems ok at the moment. Hopefully it works on the mac too.

[paulbhartzog]

Thanks guys.
Odd that you cannot change directories or anything Paul. On mine, I have no problem changing directories but for some reason (it might be to do with changing it to an openDialog) I cannot create a new directory until I've changed direcory at least once. The option is greyed out. After changing to Desktop or whatever it works fine.

I've found one annoying bug though whilst checking this out that slipped through today due to messing with the saving code. I've noticed that if you don't have the layers switched on when you save the layers the files it spits out for those layers are blank. I cannot see from your screenshot paul what layers you have active (do the jToggleButtons work correctly on the mac?). I can see from your forest that you only have the brush layer active but the brush button at the top doesn't appear selected. Have you tried saving the layers after making sure that all four layers are active?

Thanks for the effort. Good eye!

I have tested the latest version (TreeThing_962).
The screenshot remains the same, but you may have identified the problem. YES, the JToggle buttons are darkened when all the layers are visible, BUT as soon as the Save dialog pops up, they go light (unselected) again. Still can't select the destination folder, and the Save button stays greyed out, but this may be due to the fact that the layers are being de-activated by the Save dialog.

Oh, and you say you can create a directory but how? What do you click on? As you can see in the screenshot there is no interface to create a new directory (which may be a separate issue, or the same one).

Hope that helps. :-)

[paulbhartzog]

Separate post for a few other things.

The "thinking" icon is a MAJOR enhancement. Seriously.
You'll want to know that on a mac the "Auto re-generate" is always active even when it is turned OFF in the menu. Consequently, anytime you click a button (removal, layers, etc) you get the "thinking" icon. Before the icon, I wasn't sure what was going wrong, but the icon helped to make it clear.

Also, if you turn on the layers via the Menu and NOT the buttons, then the "thinking" icon does not appear (This is the same behavior as it always was).

[Ramah]

I would guess that the Mac isn't unselecting the layer buttons but the effect is just graphical when a dialog is open. Do the buttons resort back to being selected when the dialog closes? There is no code in the save routine to unselect them so it just cannot be happening. So, if it's graphical it's just an annoying mac thing.
As to still having a greyed out save button... :S Stupid question maybe but you ARE giving them a filename? The save button obviously doesn't work until it has a filename to save the file to.
As for the directory creation... that may be because I am using the modified showOpenDialog instead of the showSaveDialog (to get around the supposed mac Java problem). I'll post up a new version later using a save dialog instead. It works fine on the PC as it is but zzz @ macs.

Glad the thinking icon is working ok for you. Odd that it doesn't work with the menu though. It's written to automatically change cursor upon UI actions that take longer than 300ms.

It isn't actually auto-regenerating upon layer change (well... not as much as I class as regenerating, it isn't resizing the arrays or reapplying jitters etc.) but it is redrawing the forest image. I tried having each layer on a separate image so that switching layers on and off was just a matter of refreshing the screen but the memory usage when a large forest was generated was becoming a problem. I prefer it this way. It means recreating the forest image upon each layer change (and layer save) but as that shouldn't really happen that often it isn't that big a deal.

[jfrazierjr]

Search for Mac new folder dialog missing.... I have found that it is a bug in Java(meaning OSx since they made the user interface API's for java) and there is a system property you can set to get the "create new directory" to show up on the Save Dialog window.

On that note, Ramah, you might want to look into using SystemLookAndFeel of the UIManager class(I think I got those right) to make it use the OS's native "skin" instead of the standard Java one for the open/save dialogs. Worst case scenario it just falls back to the Metal LAF anyway if the chosen LAF is not available.

[Ramah]

Heh. Ain't no way I'm using system lookandfeel. It took me an annoyingly long time to get Nimbus working and I ain't replacing it with something that looks terrible. I'd sooner have it broken on macs. Lol!

Thanks for the tip on the missing create folder thing. I'll take a look into that.

I was going to upload a new version yesterday which is hopefully fixed for Paul but as I was checking the exe I noticed it was behaving differently to the one in the developing environment. For some reason when I try to load up a large template or background image (4k x 4k ish) it just has the busy cursor for about 3 seconds or so and then just goes back to normal as if I never even sent the request. Although it loads smaller images fine.
It's quite odd. It loads them up fine in NetBeans. :S So... gonna try and see if I can get to the root of that problem before I update.

[Ramah]

Ok, so after spending some time on the probelm mentioned above (not the saving on macs problem) I've deduced that the fault seems to lie in the memory allocated to the program. This is annoying as I've altered the VM settings in NetBeans to allow up to 1gb of heap memory in the jar file but this doesn't seem to be the case, only in the IDE (to which I had also edited the startup file to do the same).
So any large template or background image loaded is blowing the allocated heap size and the program continues on its merry way without loading stuff. I have no idea how long it has been like this really. Has anyone who has used this to create forests in the past had a problem with larger templates?

Anyway, I've found a pseudo work around for now. By using a wrapper on the jar file I can create an exe and redefine the memory allocation of the program. The program I have used to wrap it is called Launch4j which is a free app that apparently can also create mac, linux and solaris executables. I'm new to this though and not sure if I can create a mac executable on the PC though just by giving it a different extension or whether it needs to be done on a mac.
So for now I think I'll just get it into a presentable state and then upload the jar file as usual so Paul can test the saving on the mac and if anyone has any comments on this memory problem I'm all ears.