A few days ago I built and released the second milestone release of PICEDIT 1.3. This gives people a chance to see yet more of the new features I've been working on for 1.3. This release focuses mainly on fixing a few bugs and making some existing features more usable. Note that this is just a milestone release and I plan to release more milestone releases before the final 1.3 release.
* Single point lines so that Sierra and fan-made games that have such lines can be loaded and edited. Single point lines are supported by the Line, Pen and Step tools. Simply click on the start point then right-click to stop drawing and you now have a single point line.
* Replaced the custom Sierra-like menu system with a more modern windows-like menu (that is always visible) along the lines of what people are used to seeing these days.
* Split out the "Save" menu option in to separate "Save As" and "Save" options.
* Added support for user preferences. Two of the existing features are now saved as preferences when the user exits PICEDIT. These are grid lines and zoom size. PICEDIT will now remember what zoom size you were using the last time you used PICEDIT, and likewise whether you had grid lines (i.e. bands) enabled or not.
* PICEDIT now also remembers what the last used directory was from the last time you used PICEDIT.
* This release also includes an attempted fix for the screen resize bug. Some people noticed that the window frame and its contents were not properly resizing.
* As part of the new menu system, more keyboard shortcuts have been added, such as for toggling the bands, toggling dual mode, opening a file, saving, etc.
Let me know what you all think. I am very keen to hear your feedback and suggestions.
* Not all hotkeys work, F6 (toggle background), ESC (menu).
* Special's Background's tick-status varies regardless whether there is actual background-image or not, say choose new picture while having existing background, you get blank screen, no background-image but it still stays ticked.
* Ability to maximize PICEDIT-window itself to full screen, the picture-window itself along with tools is big enough with 5 x zoom (@ 1920x1080), still too easy to get accidentally accidentally swapped to underlaying application while drawing line for example.
* Able to open recently opened files/folders
* Ability to browse folder, in other words seeing thumbnails of pictures in folder? Regardless of how the pictures are named? ( Though using PICTURE.whatnot has been naming custom signatory's case. )
* Possibility to choose whether background-image is stretched to whole window or stretched while maintaining aspect ratio of the original image, say locating background to centre or even better, giving user ability to move partially stretched background to desired position.
I haven't really tidied up the textual content on the help pages since I converted the old C version to Java, so I am aware that there are some details on there that probably don't work the way they are described. For example, ESC no longer brings up the menu. This is because I decided that this wasn't really standard for windows like apps. On Windows it seems that the Alt key serves this purpose. If you simply press the Alt key then the menu system is activated. If you do something like Alt-F then it brings up the File menu. If you instead type Alt-V or Alt-H then you get the View or Help menu. This appears to be standard Windows menu behaviour, so I'm using that approach now.
Regarding the Help Pages, I intend to clean this up in the next Milestone. I have been looking at the built in HTML rendering capabilities that Java has. What I should be able to do is build some simple static HTML content that is packaged with the application and that can be loaded up when the Help Pages are activated. This will make it a lot easier for both me to maintain and also for users to use. And I think it will look a lot better. The current help pages are a bit ugly, especially when the zoom factor is not 2 or 4.
Yeah, I haven't really implemented background image toggling as I had it in the old version. What it currently does is load an image and then unchecking the checkbox will actually forget what the image was that was loaded and you'll need to load it again to display it. I think I'll need to rethink that a bit. I need a way of distinguishing between toggling the display of the image and choosing a new image. If I used the checkbox to toggle the image then how would the user say that they want to load a new image? I guess what I would need is an "Open Background" and a "Toggle Background" to make it work properly. Maybe the current Background option can be used for the toggling and I can add a new item to the File menu to load the background image.
Regarding your suggestions:
* Full Screen: Do you mean the ability to maximise the window to fill the whole screen? Java also supports an actual full screen mode as well, i.e. no window at all, no explorer bar, etc. (although I think it depends on the host operating system's support for this). I was thinking about experimenting with that feature as well. Maybe I'll give both the maximise and the full screen a try and see how it goes.
* Recently opened files: This should be fairly easy now that it supports user preferences. I'll simply keep a rolling list of maybe the last four opened files that I'll show in the File menu, a bit like what the Microsoft Office apps do.
* Browse folder/thumbnails: For this do you mean thumbnail support in the open file dialog?
If you implement full screen, you should just maximize the window, not actual full screen. The delay while the display switches modes would get maddening if you had to do it more than a couple of times.
Any modern graphics application has thumbnail displays of the images in the folder in the browse dialog, but on Windows this relies on a shell extension for the file type. If it is not a standard type (i.e. GIF, JPG, PNG, etc.) this extension needs to be supplied by the developer, such as Adobe supplies it for PSD and PDF. If you do not want to write such an extension, you would need to build the ability into PicEdit and not use Java's file dialog abilities. Even if you wrote the extension, it would be Windows exclusive.
Yeah, I was wondering about how I would do the thumbnails in the file dialog. A custom file dialog sounds like it would have to be the way to go, which might end up being a bit too much work. I'll have a look to see what is involved. I definitely don't want to make it a Windows only app, especially since I am doing more than half the development on a Mac.
Regarding a fully full screen mode, what I was thinking is that it would be something that you select from the menu (or use the shortcut key) and wouldn't be hooked into the window maximise. I'll get the window maximising working first I think. Maybe there isn't a need for the fully full screen mode, or perhaps it would only be useful in a testing or preview mode. I usually run DOSBOX in full screen mode when I'm playing the old AGI and SCI games, which is why I thought such a view might be useful.
Full screen mode may be nice for a preview of the pic resource itself as it would appear in the game. To fill the screen to work on it would be best to be just a maximized window.
