Sunday, May 4, 2014

Almost there...

I made another video of my music player to demonstrate a few more features which were left out of the previous video. In the process, I uncovered and fixed more bugs. I also found that I seem to have borked Edje text sizing, as seen briefly in the tooltips.

  • Software rendering hurts a lot here. First Music Player GUI Ever To Require Hardware Acceleration For Smooth Performance was not the tagline that I was shooting for.
  • First two cover art images (first Periphery:Clear cover, Odyssey cover) are being loaded from a disk cache. Every other image is being searched for and downloaded in realtime.
    • File browser uses Glyr for artist image finding, which is horrifically slow/inaccurate => this is why the file browser is blank. Need to figure out a non-Google service to abuse for this...
    • Lyrics were downloaded in realtime

1.0 soon, no I'm not adding non-MPD support.

Tuesday, April 22, 2014

Things That End In 'C'

I've been doing a lot of Edje work lately, and maybe I'll make a post about that at some point. Or about anything. But until then, here's a video of my music player:

Sunday, January 19, 2014

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:
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.

Monday, April 1, 2013


After saying I'd do it for quite a while, I finally made some progress in my promise to write some E-related RSS stuff for Boris Faure, aka 'billiob': eRSSd is in git now, and it's moderately tested and (should be) fully functional.

Originally, Boris was working on a standalone app called ERSS on github. I chipped in a tiny bit to improve his Azy usage, since it's the easiest way to get and parse RSS feeds, but then, as E developers tend to do, I drifted away from the project and absolutely did not forget about it.
Over the time that I wasn't working on it, I wrote a ton of other projects and contributed to even more. Along the way, I realized that what would be great for RSS was if we had an underlying daemon which could then be accessed by all the apps and widgets, and which could run in a distributed fashion by synchronizing with other daemons over a network.

The hardest part of any project, aside from naming it, is starting the work. Aside from working out a number of kinks in Azy related to HTTP/1.1 chunked encoding, the whole thing was written in a weekend. During this process, I spent some time learning the ins and outs of the new dbus integration library, edbus2. It's certainly an improvement over the original, which was basically just libdbus, but it still feels pretty rough around the edges; iterators in particular are not great to work with.

Anyway, the basics of eRSSd:

Adding feeds
* Add a feed from cmdline of daemon or over dbus (or remote api once I iron it out)
* Feed is fetched and cached using eet
* Feed and items become available for use over dbus (and remote API)

Using feeds
* Feed is fetched on interval based on various http/rss attributes which indicate optimal cache length
* dbus signals sent to indicate freshness and new items
* Clients use eet to directly read cache file using local client API wrapper to avoid sending tons of data over socket
* Clients send signals back to daemon to mark items/feeds as read

Deleting feeds
* Client calls dbus delete method on daemon with URL for feed
* Daemon deletes feed, removes cache
* Signals sent over dbus (and remote) to indicate deletion of feed so UIs can be updated

A utility library for clients is provided, allowing developers to avoid having to write any eet/edbus2 code themselves and focus entirely on presentation/usage. At present, only a dummy configuration UI exists, but plans are in motion to create some cool stuff in the near future. RSS is a useful and common enough tool that we should spend some effort integrating it more!

Sunday, August 26, 2012

bits and pieces

finally getting back to some theme stuff; gotta get darkness e/elm into shape before The Big Release (TBR). new hoversel theme:

needs a little tweaking so the edge image doesn't overflow the hover, but I'll tackle that another day when I care more

Monday, July 16, 2012

New Footrest

So I got a mail at work earlier today stating that I had received a package. It was so incredible that I thought I would share: behold, my new footrest!

Friday, July 6, 2012


As some people may have noticed, there's a new module that hit SVN recently: Physics.

Using the new ephysics library which has been written by ProFUSION workers, this module attempts, and sometimes succeeds, at applying basic physics effects to windows on the desktop.

There were a number of hurdles to making this work at all. To begin with, E17 is very particular about where windows are placed. The callback chain for simply dragging a window around is fairly extensive, and it would have been impossible to successfully add physics in. To get around that, I was forced to add a hook on literally the line prior to a window's position being updated; this callback allows a user to receive and, optionally, adjust the coordinates.

On top of this, the version of ephysics which I based the first version of the module on did not allow easy changing of velocity, so the only possibility was to add "impulses", as they are called in Physics Library World. These set initial velocities which decay over time based on friction and collisions, and are much less precise -- obviously quite a problem when working with something that we want to be precise such as moving windows around the desktop. As a result, the current physics movement is inconsistent and feels a bit clunky; I only had one chance to apply the impulse to a window, and adjusting it was impossible due to another bug:

"Boundaries" in Physics Library World are objects which exist at the edges of the world (screen) which should prevent any other object from getting past them; instead, an object will bounce off it. Unfortunately, when applying impulses repeatedly to an object it will tend to accelerate uncontrollably and rocket past these boundaries into offscreen territory, leading to lots of lost windows. I learned to enjoy the "Cleanup Windows" functionality during tests here. Eventually I decided that the best way to prevent this was to try to be less precise -- only setting the window in motion at one point based on a configurable number of drag frames.

I quickly encountered another fun feature: while windows would no longer reach escape velocity, they would actually get stuck in the screen boundaries and be immovable. More workarounds were added here to disable all physics if a window somehow moved into a screen's boundary area, and now a user can freely move them in such cases.

There's a lot of work to be done on this module, and a lot of possibilities for it, some of which I've listed in a TODO file in the module's directory on svn. Graphical effects are doable, and probably worthwhile, but the biggest thing at first is obviously going to be improving the accuracy and "feel" of the physics. Right now it's barely even a toy, but I want to be able to play Jenga with my windows!

To conclude, don't expect to get any work done running this module. Keybind moves won't trigger physics, but having your entire desktop bouncing around probably won't increase productivity by much.

PS. check out my other blog