Serve as a basis for team and community discussions about GR 1.0 features, how they will be implemented, and by whom.
The goal is to ship Gallery Remote 1.0 once all P1 and P2 features have been implemented. P3 and lower features will be implemented in point-releases following the release of GR 1.0.
Name | Priority | Status | Version | Who | Description | Comments |
---|---|---|---|---|---|---|
Main UI | P1 | 90% | 1.0 | paour | The main UI needs to be rewritten using Layouts, in order to allow more flexibility. | |
Preferences | P2 | 90% | 1.1 | paour | A preferences dialog, that allows users to set most or all the preferences that are exposed in the properties files, and create/edit Gallery connection profiles. | The structure for this is starting to emerge: all or most preferences should be read directly from the Preferences class, and a system of defaults exists. |
Inspector | P2 | 70% | 1.0 | paour |
In the UI, have an inspector pane for each Picture, that can display full filename, file size, thumbnail, caption, order ID, resize/rotate buttons, remove button, move up/down buttons, order counter, etc. | And later on, any property that is supported by G2. Also, with Explorer UI, can inspect Album properties. |
Create album | P2 | 100% | 1.0 | paour | Provide UI to create albums on server. Option to create albums before existing albums, or after. |
Would be more elegant in Explorer UI. Needs protocol upgrade |
Upload Picture captions | P2 | 100% | 1.0 | tim | When a picture is uploaded, also upload a caption. | Needs protocol upgrade |
Pre-upload resize | P2 | 100% | 1.0 | paour | Pictures can be resized on the client, thus minimizing the bandwidth necessary for the upload. | Default Java resizing quality is not great, and not very flexible. We may need to use an external app. It may be worth investigating the plug-in mechanism in G2 for resizing. |
Fix DnD | P2 | 0% | 1.2 | DxM | Dragging pictures out can cause duplicates and is counter-intuitive. Dragging in should scroll the list when pictures are dragged over the top or bottom parts of the list. |
|
Fetch only writeable albums | P3 | 100% | 1.1 | paour | Display only writeable albums (and albums that contain albums that are writeable) in the combo-box. | Needs protocol upgrade to optimize network traffic. Could be a client-side only solution too... |
Picture inspector: extra fields | P3 | 100% | 1.1 | paour | Display in the Picture Inspector text fields so extra fields can be set for each picture, in addition to Caption. | Needs protocol upgrade |
Download Album | P3 | 0% | 1.2 | In order to support reordering existing albums, we need to be able to download albums from the server, including order, thumbnails and captions. | Needs protocol upgrade | |
Upload Album order | P3 | 0% | 1.2 | Upload updated order for album. Would be nice to do it in such a way that we don't need to lock the album while the user is editing the album order. | Needs protocol upgrade | |
Auto-rotate | P3 | 0% | 1.2 | Use EXIF to figure out whether an image has to be rotated (optionally). This is only useful for pictures from cameras that contain a horizontal/vertical sensor, such as the G5. | Needs EXIF reader class. I will not do this if it requires executing yet another external app. | |
Multi-album upload | P3 | 100% | 1.0 | paour | Allow pictures to be uploaded to different albums within one session. This can be done without a protocol upgrade, and is slightly different than batch upload. | |
Pre-upload rotate | P3 | 100% | 1.1 | paour | Pictures can be rotated on the client. | This can probably be done in Java, since it's not resource-intensive (only for JPEG, though). |
Proxy support | P3 | 100% | 1.1 | paour | Allow setting up and using a proxy to access to Gallery. | |
SSL support | P3 | 100% | 1.1 | paour | Allow using SSL/https to access Gallery. | |
Watermarking | P3 | 10% | 1.2 | paour | Allow watermarking operations using ImageMagick. Also arbitrary IM operations. | |
Fix progress bar | P3 | 0% | 1.2 | The progress bar currently doesn't provide predictable feedback, as it can be overriden by different tasks. Also, a Cancel button should be provided. Does this mean that we should display progress in a separate window? Probably. |
||
Explorer UI | P4 | 0% | 1.2 | In the long run, I want to use a Windows Explorer-like UI, with albums on the right, and their contents on the left. | Depends on Download Album | |
XML serialization | P4 | 100% | 1.1 | paour | Album objects need to be able to serialize themselves, so batch uploads can be considered | Data is now stored in Bean classes that could be serialized automatically (Castor) or by hand (lighter). Final choice: |
Batch uploading | P4 | 30% | paour | Allow pictures to be uploaded using command-line tools, all in one go, using saved files (XML) containing the upload parameters. | Alternately, it could be interesting to allow more than one album to be viewed in the UI at the same time, and to set up uploads to more than one album. Also see Explorer UI |
|
Shutdown after upload | P4 | 0% | Optionally shutdown the machine after upload is complete. | Architecture-dependant. |
Name | Priority | Status | Who | Description | Comments |
---|---|---|---|---|---|
Security | P0 | 20% | tim | One person needs to be in charge of auditing the security of any protocol change. Maybe we can ask help from Bharrat for this. | Security problem |
Modularity | P1 | 80% | tim | The remote code is all in one file, and other projects want to use remote functionality, but want a UI or other features. We should see if we can separate the current code to isolate what is GR-specific, and what should be available to other remote interfaces. | WPW project is one example |
Protocol versioning | P1 | 100% | tim | Make it easy to support protocol versioning. It's probably somewhat in there, but we need to make sure we won't run into trouble when we start revving the protocol frequently. | |
IIS support | P1 | 100% | paour | IIS seems to send a slightly different acknowledgement to GR, so login fails. | Bug 602606 |
Picture caption upload | P2 | 100% | tim | Expose an interface to allow uploading captions for a given picture. Right now there is a hack that allows using the filename for the caption: posts 3 and 4 of this thread in the forums describe the hack. We need to also allow the user to type in a caption. |
|
Create album | P2 | 100% | tim | Expose and interface to allow creating albums remotely. | Does this mean we also need to handle album security setting, or just that we only use the default settings? |
Fetch only writeable albums | P3 | 100% | paour | Only send to the client albums that are writeable by the user, and albums where at least one decendent is writeable. | The order is that of the creation of albums. Clients have to resort according to containment, for example. |
Album: get extra fields; Picture upload: set extra fields | P3 | 100% | paour | In the album fetching, get the extra fields list. In the Picture upload, allow uploading extra field values. | |
Album download | P3 | 0% | tim | Expose an interface to allow downloading of picture order, thumbnails and captions for a given album. | |
Album order upload | P3 | 0% | tim | Expose an interface to allow remotely changing the order of pictures/sub-albums in an album. | |
Double byte support | P3 | 0% | We need to make sure the protocol can handle double-byte chars. | Bug 480880 | |
Honor Filename retention | P4 | 0% | The server needs to allow not retaining filenames of uploaded files (if that is the server setting). Right now, all uploaded images use their original filename instead of an automatically generated filename. |
|
|
SOAP protocol | P4 | 0% | Move to SOAP for the protocol. | Probably not useful until GR2. |
Name | Priority | Description | Comments |
---|---|---|---|
Logging | P1 | Every user task and network task should be logged (using the Log class) so we can figure out what happened when something doesn't work. Shipping versions of GR should write nothing to System.out and System.err |
Log.log(level, message) |
Status and progress | P2 | Most user actions should update the status bar. All actions that take time (network stuff, image manipulation) should also update the progress bar built into the status bar. When the progress bar is being used, it locks the status message so that only updateProgressStatus can be used to change the message. This suppresses 'normal' status messages. |
MainFrame.setStatus(message) MainFrame.startProgress(min, max, message) |