Why I started Image Upload Manager
I used to use ImageBot to upload my images to ImageShack. But it has been at least a year since I last succeeded in logging in using ImageBot. So I looked through the ImageShack website for an alternative. They didn't have one that could do what ImageBot did. That is, more than just upload the image. ImageBot can do all the following, when it works:
- Upload the image
- Delete the image when you don't want it anymore
- Provide URLs for both the original image and thumbnails in various strings like BBCode, HTML, etc.
Since ImageShack has a public API, I figured I could write a utility to replace ImageBot in my needs. I also figured that other sites like ImageBot had similar APIs. So the new program could be made extensible to support those other sites.
Why .NET?
Mostly, because I expected to do most of the coding myself. .NET is the most modern platform that I know how to develop for. Other platforms would have required a steep learning curve before I could write a single line.
What versions of .NET and Windows will be supported?
Without someone who has Windows 7 or a 32-bit Windows, testing will be limited to .NET 4.0 and Windows Vista 64-bit. As for XP or older versions of .NET, those will only be supported if it works out that the final program runs there. If they don't, oh well.
Why Windows Forms rather than Windows Presentation Framework (WPF)?
See above. I don't understand WPF yet.
How will Image Upload Manager be extensible?
- Upload providers will provide all communications with the image website servers. (Upgrades will be handled elsewhere.) These could have their own preferences and could recompress images on the fly. However, they would have no access to the physical file on the local drive. Instead, they would see the file as a data stream only. Currently, I am expecting to include just one upload provider: ImageShack. However, that could change.
- Thumbnail providers would allow the program to show thumbs for non-standard file types. For instance, the Windows shell can provide us with thumbs for file types like PNG, GIF, BMP, and JPG. But for other files, say SVG, you are out of luck. This is where thumbnail providers come in. Some would also allow those built-in types to be handled differently. Windows might handle certain types of photos poorly. But a 3rd party thumbnail provider could fix that problem. Currently, I am expecting to include a “default” thumbnail provider that only uses the Windows shell thumbs, a provider for SVG, and a RAW provider (maybe).
- Extensions would provide abilities not available to either type of provider. While upload providers could recompress images as they are uploaded, they can't save the image recompressed. Extensions could do that. Extensions could provide photo retouching ability. Both of these are really outside the core mission of the main project. But I have no problems with extensions do those things. I don't expect to allow extensions the ability to do as much as Mozilla extensions can do. But they will still have a lot of power.
How come I don't see any preferences windows in the screenshots?
Because they haven't been written. I am holding of on even coming up with preferences because the rest of the program is in flux. I don't know what preferences will be needed. I don't want to have to rearrange those windows any more than I have to. But if I code them now, I would be adding preferences like crazy at this point. So it makes sense to hold off.
Will there be themes?
Probably not for a while. I don't consider them to be a priority. They could require a lot of code. So I am skipping them for now.
How will data be stored?
Entirely as XML. The only binary storage will be for the thumbnails as they will need a cache somewhere.
Will the program be portable? Or will it need to be installed?
Take your pick. The code I have can already go either way. If there is a file in the program directory named “data location flag file.txt” with the contents “portable", the program will look to sub-directories of the path containing the executable for the profile data. Otherwise, the program will look to "%appdata%\Will Pittenger\Image Upload Manager” for profile data. If the program is portable, the same folder with the profile will be checked for extensions and providers. Otherwise, it will check the "%appdata%\Will Pittenger\Image Upload Manager” followed by "%programdata%\Will Pittenger\Image Upload Manager” for those. (I do want to allow users to disable global extensions and providers.)
What about PortableApps.com support?
I won't rule that out. However, Chris Morgan of PortableApps.com told me that they currently don't bother with .NET applications. So no code will be added for now.
What would happen if files or folders are missing?
Except for the executable and DLLs, the program will simply create them.
What preferences are planned at this point?
As previously noted, that is in flux. But I do want these:
- Disabling global extensions and providers
-
How to save the current working directory when the import wizard is open. Options would include:
- Remember the current directory, but reset it for each session
- Remember the current directory, even if the program is restarted
- Always return to a specific directory
- Use the current directory set by Windows
- Defaults for how to import items. Those include:
- Upload immediately and (if so) to which upload provider to use
- Filters for what the program should include in the imported version of a folder (folders only)
- The current folder to show in the main window when the program starts
- I also expect the program to record the size and position of all windows.
- Should files be deleted from the local drive once uploaded? (Not available if the next option is selected.)
- Should files that are missing locally be downloaded from the remote server. (Not available if the previous option is selected.)
- Should files that have been changed locally be re-uploaded to the server?
In addition to those preferences, extensions and providers might have their own options. The preference system needs to be able to provide access to those. The import wizards also offer a favorites pane with access to commonly used folders. That is mostly coded along with code to store the favorites list. Also coded is the ability to show or hide file types and add new ones. Those changes are also saved.
How will thumbnails be cached?
There are several different systems. I would like to allow each as none are truly superior to the others.
- Embed the thumbnail into an XML in the user's profile folder as encoded data. This stays the most within the XML data theme, but is messy. Plus thumbnails could end up being duplicated by multiple users each with their own profile. Plus the thumbnails could get out of date.
- Store thumbnails as files inside a folder in Program Data. This eliminates duplication, but allows thumbnails to get out of date.
- Store thumbnails as hidden files next to the original file. This also eliminates duplication, but now the files are visible to users who might delete them by mistake. These would be the mostly to remain up to date, but only when Image Upload is running.
- Disable thumbnail caching. Now the thumbs will never be out of date and there are no files to be seen by users. However, thumbnail generation could take a while if they have to be downloaded again.
What is meant by importing?
Importing is the process of telling Image Upload Manager about your images. There are two types of importation. When you import individual files, that is all you are importing. You can import them into any “virtual folder.” A virtual folder is one that exists as far as Image Upload Manager is concerned, but doesn't actually exist on the local drive. If you import a real folder, you are implicitly importing all of its contents (subject to filters). You can't move the contents of an imported folder. Nor can you import anything into such a folder. However, you can hide its subfolders and contents.
What do I need to compile the project?
- Microsoft Windows Vista or newer
- Microsoft .NET 4.0+
- Microsoft Visual C# 2010 or newer. The Express version is sufficient and happens to be what I use at this time. It lacks plugin support (which means no integral SVN), a breakpoint manager, install generator, and a few other things.
- Object List View—The good news is that for the time being, we are using a slightly modified version in SVN. You don't need to download it.
- A SVN client. If you use the Express version of VC#, I suggest using TortioseSVN. It integrates into Windows Explorer.
- Windows API Code Pack—You do need to download this. It is a free .NET wrapper for Windows Shell functions. You can get it here.
Will Image Upload Manager spawn any subprojects?
There are several DLLs that I hope will become their open projects here on SourceForge. But for the time being, they will remain as part of Image Upload Manager.
Are you working on a project logo?
I haven't thought up any yet. But I am open to suggestions. Please post them in the developer forum. All submissions become the property of Will Pittenger and subject to the license listed in the footer.
Do you have any screenshots?
Yes. Go to the screenshots portion of our gallery.
Is “Image Upload Manager” the final name?
Definitely not. I am hoping to come up with a better, more unique, catchier name. The current name is a place holder. However, the name used in the code will remain unchanged. I won't change the project's Unix name on SourceForge unless I am certain that it won't break your bookmarks to our site.
What page should I link to?
This page please. Please let us know about any links by posting in the guestbook.