• Media Player 26.09.2008

    This is being cross posted at Javalobby and they made the first two parts into one, so this is either part 2 or 3 depending on where you read the first one (or two). The next one will be part 3 for sure though…

    OK, redesign, redesign and another redesign, that is what designers do until all pixels makes sense. Anyway, no biggies but the devil is in the details and a there were a lot of details that I didn’t like. Go and look at part 1 and part 2 to see the old screenshots for comparison.

    As you can see the top button labels look better now. Cleaner and more readable. I have also opted for monochrome icons with a tint for the selected button/tab. Again, it looks more clean, at least compared to having the full colored icons. I may need to recreate the icons from scratch later, to get that pure custom feel, but for now I use the excellent icon set from Icon Experience.

    If you look at the second button from the left you can see that it has a slight white-blue glow. That is how the mouse-over effect will look. Of course it will fade it but it will do that very quickly, we don’t what it to feel sluggish. I have also unified the color scheme a bit. Gray-blue is the favorite color fo the day, let’s see if it sticks around to the final version.

    I have removed the “track” for the scroll bar so now it looks very iPhoney (pun intended). I don’t want to be a copycat, but it looks clean. Not sure if the track should be re-enabled for mouse over or not, or maybe it will be there all the time? Not sure and it is a decision for later when we have the animations in place.

    You might have noticed that the shadows have changed slightly. They are now more consistent and correct with the intended z-ordering of the main window and the side bars. Out of a performance perspective they are now also easier to make really fast.

    One comment on the earlier designs was about the bottom button bar. The buttons didn’t really look like buttons. They still don’t look like normal GUI buttons but I think they look more like buttons. The easy to recognize play button will help the user in his quest to understand the GUI and what he can do with it. Usability tests will later will show if I’m wrong.

    The biggest new part is the bottom bar. As I said before I didn’t want to make it white, that would make the whole GUI too blended and boring. It is still a bit experimental but generally I like the look. It should be noted that it is 60% translucent, which is impossible to see since the background is solid gray…

    The main windows is now showing the newly designed tracks tab. It was harder than I first expected. Not because tracks are particularly hard to show but because they are so boring that there is little room for innovation and spicing it up. The albums on the left are all the albums to the selected tracks. Here it is very important the that loading and preparation of the album art is done in a background thread or the GUI will be sluggish at best.

    Next time I will show the mini and micro version of the GUI, I promise…

    Mikael Grev

    Posted by mikaelgrev @ 22:51

    Tags:

  • 15 Responses

    • Vic says:

      Do you know how to deploy this?
      Problem w/ java, you tube like video flash/flex is deployment.

    • bill says:

      Any code ? or is it all about your thoughts on GUI ?

    • Mikael Grev says:

      Vic,
      The MP will need Java 6 Update 10 and WebStart in that version is much more robust than in previous versions. That is one alternative. There will also be a normal download, like Skype does it, and it will probably be compiled with Jet (www.excelsior-usa.com).

      Bill,
      Not yet, but there will be of course. Currently I am in the design phase. Soon I will start designing the code as well. :)

    • David says:

      I really do like the way your UI is looking so far, I think it’s clean and well suited to it’s purpose. I have asked before and did not see a response, so going to ask again.

      Many out there use most of their programs in full screen, how are you going to handle the pullouts and side / bottom tabs (or buttons, whatever you want to call them) if the program is maximized?

    • Mikael Grev says:

      David,

      Thanks for clarifying the question. I did not understand exactly what you meant before so I was thinking about an answer until I forgot to write one.. :)

      I have a plan for that but it is quite hard to convey in a few words. But I’ll try.

      First and foremost every part of the GUI should behave and degrade very nicely when shrinking/growing, courtesy of MiGLayout.

      Secondly, if you open a tab you intend to see it. This means that it will never open outside the screen since that wouldn’t be your intent. Therefore the app itself must be made smaller to show the pullouts. It will do this, ultimately, with an as smooth and nice animation that the pullout has when extending, countering the effect so that the whole app will stay the same size.

      Thirdly, if you move the application so that the pullouts goes off screen they will act as a spring and be pushed into their closed position by the screen edge, extending again if the user moves the screen to make room.

      Fourthly, if the pullout will open automatically for some reason (not sure this will be happening, but anyway) then there will be some visual que that it want to open. The user can then act accordingly, either by reducing the size of the main app or explicitly by pressing the tab.

      As I said, this is hard to explain but at least I think I have a good plan. :)

    • saeed says:

      Great work mikael ,

      I think it’s better that you make your project open source . so
      we will have an open source and fully java implemented media player.

    • Mikael Grev says:

      Thanks Saeed,

      Actually I have no need for outside help so there is no incentive for me to make it open source.

    • Mats says:

      I have been working on a similar project for some time now. However, it is a bit different since I chose a very Itunes like interface and my application is audio only. I also intend to release it as open source when it is finished.

      My player is based on Java, but uses native cross platform c libraries for audio playback (FFMpeg) and tag reading/writing (Taglib). It uses the Java Plugin Framework (JPF) to provide a modular architecture.

      You can have a look at a screenshot here:
      http://static.zooomr.com/images/5992883_55927cdd54_b.jpg
      (This shows the application in action. It is not just UI)

      I find it a bit strange that you do not want “outside help”. Do you have any idea how effort you have to put into a project like this if you plan to actually release something useful? Have a look at SongBird’s code base to get an idea… (www.getsongbird.com)

    • Mikael Grev says:

      Mats,

      I will try to stay away from native code if at all possible. With Update 10 and JavaFX it might be…

      Lets just say I have a very bad case on the “Not Invented Here Syndrome” ;)

    • mats says:

      Well, I also had the goal of staying away from native code, but there are some very good reasons I chose to use it.

      I use FFMpeg to decode my audio data because:

      1. FFMpeg supports pretty much every audio/video format in existence
      2. FFMpeg is super fast (even with the overhead of calling it from java) and much quicker than using for instance the JavaZoom mp3 decoder.
      3. The only decoders I found in pure java was for Mp3 (javazoom, very good impl btw), Ogg Vorbis (Decent, but not as good as FFMpeg) and Flac (A fairly buggy impl). This means you cannot support AAC for instance…
      4. As far as I know there does not exist any way to convert between these formats in pure java. (but with FFMpeg you can)

      Maybe you could actually playback most of these formats natively with the new Media Components framework which I believe is part of JavaFX, but if you do it that way you will not have access to the decoded audio data. That would make it pretty much impossible to create things like audio visualization (for instance the bars in the screenshot of my application) or an audio equalizer (which my application also has).

      You can get away with a java only implementation to read/write the audio tags. I recommend the JAudioTagger library, which is really good. I decided in the end to use the Taglib native library. The reason is mainly that it is a lot faster AND that it identifies more files correctly. Actually, if the Taglib library cannot identify the tags of a song I try to use the JAudioTagger library as a backup solution.

      I would rather have a Java only implementation of everything, but I have come to accept that it is just not possible or practical.

      As a final tip, do not try to use the Jave Media Framework (JMF). It is just a horrible piece of software. I tried to use it because there exists projects that give you access to FFMpeg through JMF. However, with my own wrapper I can use FFMpeg through JavaSound which works 10x better :)

    • Mikael Grev says:

      Thank you for your comments Mats, they will save me a lot of time when it comes to the impl. I will probably wait as long as possible to make the decision though since I want JavaFX to be as mature as possible when I evaluate it.

    • Manuel Kaess says:

      Very intersting comments…
      I am also working on a media player right now. Currently, I am using the javazoom mp3 library since I do not want to call an external program… as far as I understood FFMpeg has to be called using the command line? So it has to be started with something like Runtime.getRuntime().exec(…);? Hmmm… I don’t really like that approach. Or is there another way of calling the FFMpeg library?

      @Mats: is there a project home page for your player? How did you create the buttons (play, pause, etc) since I found it hard to create them using Java2d. Or did you use images instead?

    • mats says:

      Hi Manuel

      I did not call FFMpeg using the command line. I compiled my own binaries (dlls for windows) from the FFMpeg source using MingW. Then I created my own simple c wrapper around functions I needed to make it easier to create a Java wrapper using Java Native Access (JNA). And finally I created the necessary Java code using JNA to call the c wrapper functions. Believe me… it was not as easy as it sounds :p

      I can now just add more functions to my c wrapper and update the java JNA wrapper to enable me to use more functions inside FFMpeg… like converting audio.

      I have a project homepage on sourceforge (just search for High Fidelity). However, it is veeery outdated and probably won’t be updated in a while. This is mainly because some friends and I have setup our own build server and like to have full control over everything.

      The buttons are just images. Don’t waste your time trying to make such complex GUI items in Java2d. It is not worth it. It would just take ages to make and would also be 1000x slower. (Yes, you gain flexibility, but like I said, in such cases its not worth it)

    • mats says:

      Just realized the explanation on how I am using FFMpeg was really confusing.

      To make it easier:
      1. FFMpeg is a library created in the c programming language
      2. Java Native Access (JNA) is a java library that makes it possible to call functions in c libraries such as FFMpeg using java
      3. It is fairly easy to create Java code using JNA that calls a function in a c library

      However, calling the FFMpeg functions directly from java using JNA is complicated because all structures you access that are defined by FFMpeg (typically c structs) must be mapped to java classes in a way that is defined by JNA. The real problem is that FFMpeg exposes some really HUGE structures which makes it very easy to make a mistake when you try to map them to a java class as defined by JNA. So to make this easier I created a my own c library that uses the FFMpeg libraries. My own library exposes only a few functions and some very small structures which are easy to define as classes in Java using JNA.

      Well, there are some other reasons for doing it this way as well, but I hope you get the general idea :)

    • Manuel Kaess says:

      @mats: Thank you for your explanation. I haven’t done any C code-wrapping in Java yet, but sure will try it one day…yeah, one of these days ;-)

      I’ve heard of a program that uses the command line params to execute an external player like this before, so that was why I was assuming you were doing it that way.

      I think I will stay with the javazoom library for the beginning. For tag editing I think I will go for the JAudiTagger library and use the javazoom mp3 spi package as a backup solution (again: thanks for the great idea!)

      Also thanks for noting that it is not worth painting the buttons in pure Java2D. I will focus on images now :-)