…on the sever-side

Server-side Cropping

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.

Delete Overlay

Delete overlay
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 class overlay to maintain the collection of overlays’ DOM elements instead defining a new array.

Design Changes

Sirko Kemter suggested 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.

Overlay Constraints

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.

Bug Fixes

I also fixed several bugs reported by my mentor & discovered by me.

Crop Complete

Multi-monitor download

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.

Cropped Wallpaper (left)

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.

Cropped Wallpaper (right)

I added buttons to resize all the overlays simultaneously preserving their aspect ratios, along with several UI tweaks. Lastly, I also completed the JavaScript track on Codecademy.

Multiple cropping overlays on the fly

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.

Multi-cropping overlays

I had to consistently refer documentation for jQuery & JavaScript, unlike Python. While debugging, an error in fedmenu was annoying along with the errors in my own code, so I sent a PR. Next, I’ll polish the user interface like displaying warning, add global resize buttons and implement the cropping itself.

DRY try

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.

Plugins like cropbox.jsjquery.viewport-crop.js, jquery-cropboxguillotine & cropit crop image in place. Moreover guilotine & cropit require coffeescript. Jcrop doesn’t allow to create multiple cropping windows. All in all these plugins are generic & support cropping of the image into just single cropped image. Some like guilotine & picEdit also have unnecessary image editing options.

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, croppicPicture 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.

Multi-monitor Magic!

Nuancier is a Python Flask voting application for the supplementary wallpapers included in Fedora releases. This season, I’m working with awesome mentors Pierre-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

High-res wallpaper displayed continuously on dual monitors with different resolution
Multi-monitor manga 

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

Download widget's mockup
Download widget’s mockup

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.

After reading the documentation & exploring the code, I have been tinkering with different ways to crop the image locally using JavaScript, HTML Canvas or jQuery plugin. I’ll soon start working on the download widget template.

return “Hello GUADEC!”

It’s been a week after my first GUADEC and I hope you haven’t got sick of the overwhelming amount of post-GUADEC posts🙂

Getting Things Gnome!

It was really weird to see that Getting Things Gnome! had little or no presence at GUADEC, considering it has two GSoC projects. So I tried to squeeze in some bits and pieces of what’s going on in our application in my intern lightning talk, maybe making the talk a bit vague and long.


I am really impressed to see how Gnome as an open-source organization has evolved and focused on usability testing, security, privacy, quality assurance and even on the emotional aspects of software development like awesome release video. Gnome community is welcoming and I never felt like a newcomer. I would like to contribute to the core modules this winter and be active on the engagement team.


I attended/session-chaired a mixture of technical and non-technical talks, but the best part was to meet & know the people whom I identified just by their IRC nicks. I had a great time with my mentor Nimit. He helped me to get acquainted with the dynamics of an open-source organization and introduced me to many Gnome contributors.

  • The talk I admired the most was “Where has all the Python gone?” by John Stowers. It may be due to my biases, but it touched the same point for Python as a language that I feel for GTG as an app.
  • Though I was sceptical about the process of usability testing, I hope we would use the data to redesign the specific apps in next iteration.
  • Matthew Garrett’s keynote on “Why do we do desktops?” was rosy and motivating but the toughest part I believe would be to co-ordinate and collaborate towards the abstract goals, across all the applications.
  • I am also excited for Builder, a new IDE for GNOME.

Though I was a passive participant in a few BoFs, they were quite informative. I was amazed to see how Benjamin literally played with the GTK using CSS.

Volunteering was fun except on 25th. On 25th, I got so exhausted setting up chairs in White Room after 19 hours all-nighter (layover) in Paris that I got late to the Pre-registration event and just slept afterwards.


FEC was nice & convenient place to stay: within walking distance of Epitech (the venue) and near the iconic cathedral of Strasbourg. First few days, the GTG team, comprising Nimit, Parin & I, explored the city in the evenings after the talks.Reasons to like France Unlike the popular belief, French were nice to the English speakers. I am thankful to Alexandre for welcoming us and making our stay enjoyable at Strasbourg. Alexandre helped the interns, including me, a lot, to understand Strasbourg and its functioning. Apart from the pleasing environment of Strasbourg, I loved the idea behind the light show of the Strasbourg Cathedral. Instead of maintaining the cosmetic beauty of the cathedral, they embraced its structural beauty and highlighted it with beautiful storytelling during the tourist season, brilliant!

I thank the Gnome Foundation to partially sponsor my travel and accommodation. Also, special thanks to Tobias who expedite my invitation letter else I just couldn’t attend GUADEC in first place.sponsored-badge-simple

Hope to see you all at Gothenburg, next year.

House of Services

Task manager and to-do list online services offer a range of interfaces for the Getting Things Done (GTD) methodology and to unify them under the Getting Things GNOME‘s (GTG) service engine umbrella involved a lot of thought. Google Tasks, Remember the milk (RTM) & Todoist are good choices to be integrated as service plug-ins to GTG as they offer very different implementations.


Google Authentication Screen for GTG
Google Authentication Screen for GTG
Authorization code for Google OAuth 2.0

Google Tasks provides standard OAuth 2.0 authorization with only caveat that user needs to copy the authorization code from browser window to GTG (a desktop client) to receive access token & refresh token, else GTG will be required to setup a web server listening to a port to receive authorization code. Also, users behind the firewall will have to grant the incoming port access to GTG for the latter, so it’s much of a hassle for just account authorization which is a one-time deal.

RTM, on the other hand, has OAuth 1.0 authorization, requiring to sign every request, with authorization support for desktop clients such that redirection to a callback URL isn’t required. Todoist simply provides authorization token by username & either password or Google OAuth 2.0 access token (for Log In with Google Account).

Task models

While GTG has no special status for top level tasks, all three services handles the top level tasks as projects/tasklists, as suggested by GTD methodology. Google Tasks provides infinite nesting of tasks using parent ids (just like GTG), Todoist only provides 3 levels of subtasks using indent level, and RTM provides none. To handle these differences, service engine will manage top level tasks of GTG as tasklists to be compatible with online services. Moreover, feature to add notes to a task is paid in Todoist.


I will implement a local service plug-in to store the GTG’s tasks locally and then move to implementing service engine and synchronization.

Rocky Road to Design

Last few weeks have really been rocky. According to my proposal, I was set to design an API of GTG for the service plug-ins. I read several articles, watched awesome lectures on API design. As I started to learn more and more about APIs, I came to realize my project doesn’t need one. Instead what would really simplify the life of GTG service plug-ins’ developers (hopefully you) would be to just create wrapper functions for (generally RESTful) API of online service and leave the rest of the implementation details to us.

GTG service framework diagram
GTG service framework diagram

​So, I came up with above rough design and resolved the conflicting ideas in my mind, which were slowing me down, with my mentor Nimit. He has been really helpful in resolving my conflicts and providing me a line of thought on approach.

Now, I have been busy implementing service plug-ins so that I can sense the pattern of several API (esp. RTM & GTask, Todoist) out there, which probably would be following the best industry practices. This would help me to decide the design choices for Service Engine.

Moreover, in news, Todoist silently released v5 (directly from v2) of its API along with its apps’ updates.

I’ll be posting again as soon as substantial amount of work is completed.

Summer is coming!

This summer I will be working on Getting Things GNOME (GTG) to revamp the backends’ experience, under Nimit Shah.

The status quo of Getting Things Gnome heavily depends on generic backend & local xml database for different third-party services. The class generic backend is inherited by backends for different services. This makes it quite difficult to add new services independent of generic backend, and maintain the core modules, including generic backend, independent of backend service sub classes.

My project aims to introduce several features that make GTG not only developer friendly but also user-friendly. These include detaching backend services from the generic backend such that new & customized services can be added easily, and also improvements in synchronization that will provide flexibility to users.


So, stay tuned for more updates & nightly builds for beta testing, while I get things gnome.