Davinci is the result of my first foray into Open Source Software – When I have attempted to change my default text editor of the years, the one thing that consistently prevented me from doing so was not being able to get used to the slightly different color schemes in the new editor.
I set out to fix this problem using Sublime – my editor of choice, and Atom, which seems like the new up-and-comer in the world, and I created Davinci – a ruby command-line gem that parses an intake file or directory and spits out a new theme for a different editor. You can find it here: https://github.com/mattcheah/davinci.
How does this witchcraft happen?
Simply put, a parser (xml or regex) reads a theme file and searches for specific settings which it slots into an options hash for specific pieces of code (comments, strings, function names, function arguments, integers, constants, language-specific variables, etc.) A template from the output text editor is then searched to replace option-specific strings with the values parsed from the original document.
For future releases, I intend to add additional I/O controllers for new text editors like Brackets or Dreamweaver (or Vim, for the crazies.)
A Theme Translating Tool That Works Perfectly Every Time?
Revolutionary! Mind-Blowing! Inconceivable!
No. Someone lied to you. Each text editor has it’s own method of adding specific styles to its code. Atom is built on the Google chrome platform so it’s underlying architecture is similar. This also means that all content on the page is styled using CSS by applying different html classes to pieces of code.
Sublime, on the other hand, is styled by an XML document that specifies different schemas for code elements, with each schema nesting more levels that apply to more specific code elements.
As such, there is no one-to-one ratio for applying colors to specific code, meaning that often times there’s some guess work involved in assigning a color from a schema over to a class, or vice versa.
This is further complicated by the fact that not all theme developers will write their themes using the same schemas or classes, and therefore sometimes Davinci will use the color assigned to a general schema when it was intended for a more specific element.
As an example of the difficulties encountered – Atom considers a variable passed to a Ruby block to be a
syntax--variable, but Sublime does not consider this to be related to a variable, meaning that this color must be changed manually if one wanted the new theme to be a perfect copy.
This was an interesting discovery for me, because it led to the realization for this project at least, there are some things which i could fix, but they would require a lot of time and energy, and would probably result in a lot of code bloat. Sometimes it’s easier to do the work by hand, unfortunately.
An Open Source Adventure!
This project is about more than just helping myself to move on from Sublime, although i’m sure many of us could use a hand with that. It’s also about learning how to work in OSS – as a developer I feel I’ve been rather compartmentalized in my own world working on my own projects, and I know that opening myself up to feedback and collaboration would probably do wonders for my ability to think about developing software as a part of a team and not as a one-man-band.
As such, I’m looking for feedback regarding several issues:
- How efficient my code is:
- Is it intuitive? Is it DRY?
- Is it easy to understand and follow along?
- Does it violate anything that might be considered ‘The Ruby Way’?
- How well does it solicit collaboration? Have I included anything that is off-putting to potential collaborators?
- How can I improve the concept?
I’ve already learned quite a lot from simply taking ownership and solving an issue I wanted to solve, but I’m hoping that collaboration on Davinci in the future will lead me to even more improvements in the way I write code and in the way I interact with other developers.
Davinci can be found on rubygems under the name davinci-text