-
Notifications
You must be signed in to change notification settings - Fork 5
Photologue 3.X wishlist
Although current focus is on fixing bugs in Photologue, at some point we will look to the future and start evolving and improving Photologue. The plan is to start a 3.X series of releases; Photologue will continue for some continue, mostly with bug fixes.
Meanwhile Photologue 3.X will be added onto Pypi as its own package - 'django-photologue3' - and will evolve quite rapidly between releases. The idea is to bring lots of new features, release them quickly, and to continuously improve the application. This does mean that websites using Photologue 3.X will need to pay attention every time that they upgrade versions!
The long-term plan is that once Photologue 3.X is the best gallery application ever made, and the number of commits drops away, then we will get rid of the photologue3 package and return to just using 'django-photologue' on Pypi.
Here is a personal wishlist of new features; please feel free to discuss it on the mailing list and make new suggestions!
Photologue manages thumbnails internally. However, there are many 3rd party packages for creating thumbnails of images - maybe we are re-inventing the wheel, and should rip out all of this code from Photologue and instead rely on another package.
"Photologue is a huge app, and i believe if it more easy to mantain if we separate these responsibilities os management and processing. Look I'm not saying to drop this funcionality, I believe we can use them simply by calling the methods that already exist on photologue
There are a lot of packages created especifically to process images: https://github.com/SmileyChris/easy-thumbnails https://github.com/jdriscoll/django-imagekit https://github.com/globocom/thumbor"
-- Petry
Marcos Petry has started a branch to integrate ImageKit - this will be a big change, and will require a number of changes elsewhere in the project.
By this, I mean providing a way for the developer to extend these models in his project, and to tell Photologue to use these instead of the default classes.
This change will be required if we switch to ImageKit (as the developer will need a way to define custom image sizes).
As a bonus it will allow us to remove the tagging feature from Photologue - not all developers need it, so it might be better to have it as a customisation, and let Photologue concentrate on providing only core features.
Can uploading of photos be uploaded? For example, when you do an image search you can drag-and-drop an image file onto the browser window. Would such an interface improve Photologue?
If the user wants to upload many photos, they have to zip them up and upload the zip. The interface for this is clunky - we could use a JS image uploader to make the experience far more enjoyable.
A common way of displaying photos from a gallery - is it something to have as an option in Photologue?
Maybe the templates can be improved - for example, some of the css class names are not brilliant (what's the difference between gallery-photo and photo-gallery?).
- Given the popularity of Twitter-bootstrap, would it make sense to change the templates to use markup in the style expected by Bootstrap - e.g. have the gallery thumbnails as <li> rather than as <div>s?
- If we do make the change to Twitter-bootstrap, then we probably should keep the existing templates in a 'contrib' folder and have a SETTING to allow devs to easily continue using them.
- At present the 'sample size' show in a gallery is fixed - would be nice to be able to set this (or override this) from a template; it would give more control of a display feature to the front-end devs.
- Remember that these templates need to be i18n.
Note: now that we can override the template styles (as per Petry-admin) then maybe we can put these new templates ASAP into 'contrib', then switch them with the existing templates in 3.X.
Add option to sort the photos in a gallery (for example by using django-admin-sortable).
Currently the length of this field can be set via IMAGE_FIELD_MAX_LENGTH (defaults to 100); it don't work any more because South has hard-coded a snapshot of the table definition at a point in time (as pointed out by Xavier Ordoquy). Probably this setting should be taken out, instead if the dev needs a longer field, he/she can override the field by extending the Photo model.