App Development & Me: A Brief History With Infographics And Supplementary Readings As Well As A Look Into The Future

Fed up with the constant GTK3-related downward spiral of GMPC (which I have been using for 6+ years), last month I started writing my own music player. I know what you're saying:
Why write an EFL app which isn't an image viewer?

Well the short answer is...I didn't. It displays images. So don't worry about that. We'll come back to apps, but first let's take a look into some history.


I've written a number of EFL apps in the past. The thing is, mostly I just write them for my own use. I needed a photo viewer and XV wasn't available, so I wrote EV. I was linking lots of images in chat, so I wrote Shotgun and then started on its successor, S2, so I could have tooltips of all the gifs without needing to click them. I even wrote an RSS aggregating daemon, eRSSd, on a request with the intent to build a nice gadget around it, which I'll probably get back to sometime next year.

All these things have something in common: they were functional. I mean this in the sense of function vs. form--they served their purposes, but they didn't necessarily look great while doing it.

This is a bit of a problem, I suppose, given that I work so much with UI stuff while working on Enlightenment. People see that I'm writing an app, they know that there are very few EFL-based apps (Terminology, that other one, uhh...), and so they expect great things. Then I get a deluge of Gustavos saying "Hey nice app, kid, did you make it with TK?" While such things are always amusing, it seems like the idea of making "self use" apps which are moderately complex, such as an XMPP client, is Not Smart. Or at least, that's the idea that other people have tried to convey. I'm not going anywhere with this, it's my personal development blog so I get to ramble if I feel like it.

So that brings me to the present-ish. After the amazing people over at SRA were nice enough to take in a lowly release manager, I found myself with a small amount of both time and sanity to spare. Naturally, to fix both of these things I decided to write another app, and to make that app look good. Also I merged the 6+-month old E19 branch, creating $Texas bugs and causing me to spend well over 70 hours in the past week doing emergency cleanup.

Now that I'm writing another app, and a music player(ish) one at that, the obvious first question that most people would ask is "How should it look?" Amateurs. The first question I asked myself was "How can I massively overengineer this?" Those people who are in the know about my previous development history can probably guess the answer.

Empeedee, as I am calling the initial project, is a client-server package for MPD. "Why MPD and not XMMS2?" asked one random stalker. I use MPD. I've used MPD for almost 10 years, and I don't see myself ever not using it unless something similar-but-better is written. If I'm in a place where it's not practical to set up MPD, I use a piped mplayer for gapless playback. Look it up.

MPD has what I would consider a bit of a design flaw: it doesn't have any concept of subscriptions or PUSH data. This means that it's completely passive, only providing information/data when explicit requests have been made, and then only to the client which has made the request. If you're using a system and want to have updated information in a couple places, such as a gadget and an app, this means you've got to spam MPD with status requests multiple times a second from each client--hardly ideal even if MPD is able to handle a number of clients doing this simultaneously.

My approach was a bit different: create a daemon to do the connection to MPD, and then use DBus to interact with that and broadcast it to anyone listening. This reduces overall CPU usage since additional clients get the same data for free. Obviously this approach isn't as useful if you're only going to have one app running against MPD, but it does make writing that app much easier, I've discovered, since I can use autogenerated DBus bindings and keep everything asynchronous with ease.

Anyway, last month I started the project. This was the result (26 Dec 2013):

EMPC V1 - Widgets!

I use the darkness theme on my desktop along with its accompanying elm theme, which is why it's black instead of gray. And yes, I redid the slider theme after taking that shot.
Now this obviously isn't anywhere near a great-looking app. I wanted to get something functional and non-crashy in place before I took some time to work on aesthetics. Every element in the UI here is functional and works as expected, so that was a great foundation to start with.

I used EMPC daily after this point, mostly as a nice way to display MPD status in a smaller window on my IRC desktop since GMPC needs to be run fullscreen to be useful. Lots of things happened over the next month, and then I was struck by the need to get back to it over the past few days, possibly due to the arrival of the incredibly catchy Clear album by Periphery, which I'm looking forward to purchasing legitimately in a few days. Here's another shot from 18 Jan 2014 after a few hours of work and introducing some custom EDC:

EMPC V2 - BLARGH!

The cover art just copies the GMPC/GLYR database (sqlite, vomit) info using Esskyuehl. I had a great time working with ESQL again after being away from it for so long, and it worked perfectly right out of the git with only one bug in the sqlite part itself. The extremely hackish module for getting this data is about 170 lines, 40 of which are lines of enums copied from GLYR and another 20 for the SQL query.
I spent some time experimenting with text here before arriving at the conclusion that it just wasn't going to be possible to display the playlist over the album art like this due to coloring. This album art was especially good since it was very light-colored, which caused my normal bright-colored text preference to fall on its face. Edje doesn't yet provide many options for outlining or related effects to make text stand out here, so I had to think of something else. Also there were still the gross widgets at the top to do away with.
Later the same day this happened:

EMPC V3 - What's that thing in the middle?

I've got a custom slider style in action at the bottom, and all the buttons have been moved offscreen. Artist/Album/Title/Track are now easily visible, and the current time is stuck in the middle because I hadn't figured out what to do with it then.
Less than an hour later:

EMPC V4 - Not noticeably different

This is basically the same as the previous version except that the alignment of the text and slider at the bottom is a little more accurate. I don't remember why I updated the screenshot.
At this point I had also really fleshed out the overlays:

EMPC V4 - Overlays open

This is actually two separate overlays: the bottom one holds the control buttons and moves up and down (pushing the slider and text with it), and the playlist is a scrolling 3 column custom genlist which slides in/out from/to the right along with the translucent underlay so the text is readable. Both toggle automatically based on mouse movements and also can be manually toggled by pressing F1, which is sort of the same as GMPC.
After more tweaking today, I finally ended up with something I'm moderately pleased with:

EMPC V4 - Overlays open, song selected

The time now displays and updates only on the overlay, which enabled me to remove it from the main screen. Also I added some super hacks to the slider to make it look super cool, though this isn't visible from a screenshot.

I've still got a lot to do here: the metadata fetcher needs to be an actual module instead of a compiled-in, repeat/consume/single mode toggle elements need to be added, and I should probably add file selection capabilities at some point so I can do more than just delete items from the current playlist without having to go to another client.

Based on this, I'd say that app development with EFL is definitely possible with the current libraries. Some of the more subtle animations that I wanted to do were tricky to implement, but none of this was anything that I'd consider challenging, so maybe others will be inspired to try working on their own EFL apps after reading these ramblings.


I should probably blog here more frequently, but I seldom work on my own projects any more so there isn't usually a lot to talk about.