I tested the cropping widgets with several high definition wallpapers and cropping the wallpapers of dimensions above 5000px * 3000px crashed the browser. Now the multi-monitor wallpapers are expected to be of such high resolution, so my mentors & I decided to do the actual cropping on server side. I have implemented cropping on the server-side such that the dimensions of all the overlays are sent to server-side via POST request by AJAX. In response, the server sends the gzipped tarfile of all the cropped segments. The cropped PIL/Pillow image objects couldn’t be saved as TemporaryNamedFile, so following my mentor’s suggestion I have now used tempfile.tempdir to save the cropped images & final gzipped tarfile, instead of setting a TEMP_FOLDER in app configuration.
I implemented the delete overlay functionality by removing the DOM element & splicing the array of overlays’ jQuery objects, but a bug crept in. The overlay object which was shifted to the index of the object that was spliced doesn’t has its DOM element, so I changed its implementation to use different ids for each overlay and use the jQuery object of specific ids. It solved the problem, but then I realised I could just use the jQuery object of classoverlay to maintain the collection of overlays’ DOM elements instead defining a new array.
Sirko Kemtersuggested to ask user to input all the monitors’ resolution beforehand, so we can display only those wallpapers that can best fit all the monitors. So after discussing it with my mentor, we have planned to create a new download tab where user can enter dimensions of all their monitors and send it to server-side where a query is fired to display all the wallpapers larger than the size of rectangle enclosing the multi-monitor configuration. For this query, the resolution of the wallpaper will be added to the Candidates table. After user selects the wallpaper, the wallpaper will be shown with the overlays of the monitors so the user can enlarge or move them apart & finally download the gzipped tarfile of cropped segments of wallpaper. This will make the “Add Screen” & the above mentioned delete overlay irrelevant.
Following the above discussion, several constraint are added to the overlays like minimum, maximum size & fixed aspect ratio. Moreover, the overlays now snaps to one another.
I also fixed several bugs reported by my mentor & discovered by me.
Yay! the cropping widget now crops the wallpaper into multiple segments of desirable dimensions. Now, it would be cumbersome to crop high resolution, let alone multi-monitor, wallpapers in their full glory, so the wallpaper is fit inside the browser and all the overlays created are scaled down proportionately. To achieve this we could have got the wallpaper’s actual dimensions by recreating the image without applying CSS, but we already have that information in wallpaper’s filename. So the image’s dimensions & file type are extracted using regex.
For the cropping function, a canvas is created & resized to the dimensions of the screens, proportional to the size of the respective overlays. We then draw a copy of wallpaper at full resolution over the canvas at the position marked by the respective overlay.
I have completed basic implementation of dynamically created multiple cropping overlays. Add Screen can add multiple overlays simultaneously adjacent to one another. These overlays can then be moved according to the multi-monitor setup.
I looked into a number of plugins with compatible licenses that could be used to crop the wallpaper. Using already maintained plugin will save us the effort to optimise for multiple browsers, as cropping high resolution wallpaper on client-side may impact browser performance.
So for our specialised application I’m working on a tailor-made image cropping widget. In this widget, wallpaper will be drawn on the HTML5 canvas. Multiple cropping windows could be created on-the-fly as draggable divs. The parts marked by these divs will then be extracted as data URIs. Most browsers have good support for these methods.
Now, the plugins used for downloading cropped images, like picEdit, cropimg, Image Cropper, croppic, Picture Cut & imgAreaSelect, handle actual cropping on server-side. Moreover the plugins that crop the image on client-side does so to avoid uploading high resolution images. So to reduces the bandwidth requirement & browser performance impact, if we choose to crop on server-side, then Nuancier needs to generate the wallpapers in medium resolution such that they can be downloaded for marking the parts to be cropped in browser. Moreover as users can on-demand crop any wallpaper as per their multi-monitor setups, scheduling these cropping jobs also needs to be considered.
Nuancier is a Python Flaskvoting application for the supplementary wallpapers included in Fedora releases. This season, I’m working with awesomementorsPierre-Yves Chibon & Ralph Bean to solve the design constraint that doesn’t let users with multi-monitor setup to take advantage of these high resolution wallpapers such that they can set different parts of the wallpaper on different monitors without breaking its continuity. GNOME Shell, my favourite desktop environment and so does Fedora’s, just allows to set different images on different screens but it can’t split a single large resolution wallpaper to be displayed continuously on multiple screens of same resolution, let alone different resolutions, like
Now, this wallpaper has been carefully split by the user according to its multi-monitor setup. So, a download widget will be created with multiple cropping windows like
such that users can easily segment & download parts of the wallpaper in multiple sizes without compromising the continuity of the image across various different or same sized monitors. Moreover this solution doesn’t even require the wallpapers to be curated for multi-monitor.