• Media Player 15.09.2008

    Not a title that is easy to live up to… Well, at least I am going to try. If you are interested I invite you to tag along for the ride. It is going to be some technical stuff, in Java mostly, and some design related stuff. Lets get right to it why don’t we?

    What I’m creating is a Medial Player that will actually help you when listening to music, looking at pictures or watching movies. The goal is that anyone should be able to use it, even your mother, and her mother. And it should look darn good too. In all it should look better than iTunes, be more versatile than WinAmp and at least play all files that your OS plays (but probably more). As I said, not an easy task..

    Design. Very Light. I like light designs. Vista black is nice too, but it’s to high in contrast for my taste. Light it is. I do have something of a blueprint in my head and I have just finished some preliminary GUI design using Adobe Fireworks.

    Here is a screenshot of a first take and the main view shown when the player is in “full mode”.

    Main Window

    Main Window (Click to Enlarge)

    I am not a big fan of menus. They are a scrap heap where you put stuff you didn’t think of putting in the GUI. Therefore one of the main goals, of which there will be many, trust me, is to create a UI where you can reach all functionality directly. WYSIWYG UI…

    Tomorrow I will add something sliding in from the side… Stay Tuned.

    Posted by admin @ 19:22


  • 10 Responses

    • Colm Smyth says:

      This is a great start to a potentially very interesting blog thread, and it’s definitely a good idea to start with the GUI design before you get into JMF. I suggest working out a couple of other aspects to the design too; what will the Tracks tab look like and how will it deal with Artists, Genres, dates and other ways to search and mix-n-match tracks?

      Still, it’s worth getting to coding and putting together a basic player that can have some level of working with music meta-data.

    • Mikael Grev says:

      Hello Colm,

      I have most of those things in my head. I have come a bit further now and I do have the tracks tab as well as movies largely figured out. There is already the second part up, but it has not been added to DZone yet. Third part will come today or tomorrow.

      I have a very ambitious plan regarding the music and video metadata. Basically I will “correct” everything using online databases and only where there is now way to get the correct info will the file name be shown. I hope I can make it as good as it is in my head right now. 🙂


    • […] kicks off his blog with a series on creating a multi-media player in Java. The first two entries (entry 1, entry 2) are yet to show the code, focusing instead on the process of sketching and refining the […]

    • Tom says:

      Tagging along…

    • Kevin says:

      Do us all a favor, please build it via interfaces and make it pluggable. I have often thought of doing something similar, but if your app is capable enough but I want some sort of feature, it would be nice to add it via a simple implementation plugin.

    • Mikael Grev says:

      Yes, I will make the whole thing very pluggable. Even more so than you might think. A lot of the functionality from the start will be using internal plugins. I have not decided if I should build my own plugin framework or use something that exists though.

    • Manuel Kaess says:

      That is very interesting! I’ve started coding on a similar type of media player only recently. However, I decided on focusing on music playback, visuals and MP3 ID3 editing only.

      You can find a work-in-progress screenshot under http://www.impressive-artworx.de/tests/java/player_earlyaccess.jpg

      It would be interesting to know which kind of media framework you are using (or intend to use). I chose the javazoom JLayer library for my project.

      For the plugin feature I plan on implementing the plugin-engine from swing-fx (take a look at it: http://swing-fx.blogspot.com/2008/07/add-auto-update-and-plugins-to-your.html#comment-form ).

      I will continue reading your blog with great interest.

    • Kevin says:

      I responded to Manuel’s post, you may be interested as well Mikael Grev… I and a friend wrote a pretty solid plugin engine framework back in 2005, based loosely on the Eclipse engine semantics (extension points, extensions, etc), complete with auto dependency resolution, if I recall we had done some work on plugin versions, and more. You can take a look at the “old” sourceforge project at:


      Needless to say, the CVS head is probably the better code, as I know we had done some work since the 1.0 release to fix some issues and such. Honestly I don’t remember enough of it now, but I used the engine on several small projects and many others had as well. What was nice is it basically was a “headless” application, where by your main() method started up the engine, and then the rest of the application were plugins, much like Eclipse was at the time. The benefit of using our tiny little engine was that you didn’t have to get tied into the Eclipse bloat for simple applications. The Eclipse RCP app was great, and they supprot way more than we did now, but it’s pretty heavy compared to our tiny library and for what our library did, it made sense for our use of it at the time. I have since gone “back” to web development, but I miss the Swing days. We were working on a full blown Swing app “shell” around the engine, complete with dynamic menu extension points, dockable interface, etc. That was quite some time ago tho. Not even sure FlexDock still is around or not.

      Anyway, take a look at our project. Feel free to borrow from it, use it completely, or what have you. I think I can explain “most” of it, but may have to take a stab at the code for a bit to regain that knowledge.

    • Kevin says:

      Interesting, I was just looking at your sources. I notice you don’t have a separate custom classloader to load the plugins with. In our engine we had done the whole dynamic classloader bit. We mostly did this becuase we supported a “.par” file format (for plugin archive). Bsically, you could bundle up your plugin code similar to a WAR app, where by you had something like:


      I forget the structure now, but the idea was each plugin was a self contained jar file that did NOT need to be extracted to disk to run. The classes folder was for the plugin classes, the lib folder for any jar files the plugin depended upon, and the plugin.xml descrbied the plugin, any extension points it offered, any extensions it depended upon (from other plugins), and so forth.

      It seems complicated, but really it’s easy to make use of. The parts we didn’t totally iron out were multiple versions of the same plugin, and reloading of plugins without restarting the app. It worked on plugins that did not have any dependencies on it, but plugins that had other plugins “using” it, could not be reloaded without the full chain of plugins using it being reloaded. Internally, it got pretty crazy with the classloader work we did.

      Again, check it out. If anything you’ll probably enjoy the capabilities of the engine and the amount of “learning” we had to go through, especially related to the classloader work. Breaking the normal delegation model to find classes inside of .jar files that were inside of the /lib folder that were inside of the .par file was quite interesting!

      Hope you can make use of it.

    • Mikael Grev says:

      Thank you guys! I will surely be checking back here when I start coding. Very interesting!