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!|
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!|
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?|
Less than an hour later:
|EMPC V4 - Not noticeably different|
At this point I had also really fleshed out the overlays:
|EMPC V4 - Overlays open|
After more tweaking today, I finally ended up with something I'm moderately pleased with:
|EMPC V4 - Overlays open, song selected|
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.