Vague Hope

When following conventions of working within a framework, it is import to know when to follow and when to deviate. As was once famously said, “Rules are there to make you think before you break them.”.

Previously I mused on the possibility of creating a fixed control bar across the top of Morrigan’s main window. This is, surprisingly, a completely supported feature of RCP and some experimentation this afternoon yielded this:

It is not wired up yet, but that should not take too long. I will also remove the menu bar and re-home the few unique commands it contains. The toolbar buttons that controlled lists will be moved to the top the list editors themselves. The video can then be shown in either a view, an editor or full screen (or as a last resort, at the right-hand end of the control bar).

Also Morrigan now has global hotkey support on both Windows and Linux. Well, on windows at least. Linux global hotkey support still has a fatal bug I have yet to solve.

Morrigan’s GUI as of today:

This weekend I have once again spent rather more time that planned working on Morrigan. Progress has mainly been in the area of playback and some GUI stuff. The big new feature is that video can now go full screen, and with terra you can chose which display this happens on.

The problem I am now up against is workout out where to put everything. In the world of RCP, the GUI is very definitively divided into discrete areas – Views and Editors. In Morrigan media lists (libraries and playlists) are editors and everything else are views. This all works quite nicely until we get to the player view.

A view has several key features:
– A main area.
– A caption bar across the top.
– A toolbar with icon buttons on it.
– A drop-down menu (click the little button circled in red below).

Some funky GUI logic allows the toolbar buttons to be moved into the tab area if there is space, otherwise they can end up sharing the same space as the caption bar. The drop-down menu is handy for hiding things… but that is just it. Its hidden. Placement of stuff is all rather flexible and with this power comes a world of GUI pain. While in theory views can be placed anywhere, some expectation of width is required as this dictates how many tool-bar icons you can get away with.

The layout shown in the screen shots here is my current best-attempt at coming up with a sane default layout. It works quite well… until you realise that I have dumped far too many options into the Player view drop-down menu.

Logic says I should pull some of them up onto the main tool-bar / menu-bar. This is indeed an option, but could cause confusion if I ever allow more than one Player view per window. This does not happen at the moment and I don’t see a huge demand for it, but so far I have been keeping this option open.

Another question is weather the video should be detached from the Player view into its own view / editor. (Import note here: Views and Editors can’t share the same “stack” of tabs – the Player view can’t be placed on top of playlists). The best way to arrange things will very much depend on the user’s screen size, so perhaps the best option is to allow all these and make it configurable? But I don’t want to cause too much confusion.

And I have not even begun to talk about the problem of placing the seek / progress bar. I could default the Player view to being long and thin along the top of the window, and arrange controls in it in a similar way to a more typical media player. RCP allows for views with no tab and which can’t be moved, so perhaps this would work here? But then were would the video go? In another view? Always in an editor? An editor that can’t be closed?

Here I have shown this along side the top of terra’s window.

One thing I always liked about terra’s interface was how I somehow managed to avoid too much GUI clutter. I am hoping that RCP will not force clutter upon Morrigan’s GUI.

I know text comments are no where near as powerful as standing round a black-board, but if reading this has given you some ideas, then any suggestions would be much appreciated.

For anyone interested, I have another (probably) stable build for Morrigan. Main new feature: DirectShow or GStreamer support, including video.

Well, There would be a Windows/DirectShow build, if it were not for the issues outlined my last post. Though if anyone wants a windows build with DirectShow, then please ask and I will rig something up :D.

But anyway, for anyone on Linux, this build should be a goodun.

morrigan.a2.linux.gtk.x86.zip

Known Issues:
– The list of file extensions used for library searching / open dialogue is hardcoded to what I can pay on windows. What can actually be played depends on the GStreamer codecs you have installed.
– On Ubuntu 9.10 I am seeing an issue where the video disappears (leaving an empty box) when the video panel is resized smaller. The video re-appears when the panel is made larger again (so just resize it pixel larger and that *should* fix it).
– On Ubuntu 8.10 playing wmv files sometimes crashes the whole thing with a segmentation fault error. Though I suspect this is a GStremer error. :p

In the last 2 days I have assembled 3 more playback engines for Morrigan, bring the count to a total of 4.

– SPI (as released before)
– Java Media Framework (JMF)
– DirectShow (native Windows)
– GStreamer (native Linux)

The addition of the 2 native plugins really does make Morrigan much more versatile. As DirectShow and GStreamer are the dominant frameworks on their respective platforms, Morrigan can now essentially play almost everything. This is cool because it means that CPU usage should be comparable to using any other media player on that OS.

While the GStreamer implementation fairly clean and even uses video-overlay to take advantage of hardware acceleration where available, my DirectShow plugin has an ugly skeleton hiding under the desk. To access DirectShow from java, I am using the DirectShow Java wrapper from http://www.humatic.de/htools/dsj.htm. This very functional library is implemented using JNI to talk to a .dll that it expects to be present on the Java Library-path.

I don’t know much about JNI, so the only supported method I know for getting .ddl files on the library-path is to specify them when launching the JVM. But I am using RCP and while it probably possible to do that, its really not a great approach. So this leaves me with the need to pull in the .dll onto the library-path at runtime. Turns out this is somewhat nastier than using Class Loaders, so after some research I ended up with the following monstrosity.


try {
clazz = ClassLoader.class;
Field field = clazz.getDeclaredField("sys_paths");
boolean accessible = field.isAccessible();
if (!accessible) field.setAccessible(true);
field.set(clazz, null);
} catch (Exception e) {
e.printStackTrace();
}
System.setProperty("java.library.path", "D:\\haku\\development\\eclipseWorkspace-java\\dsjtest\\lib");
System.load("D:\\haku\\development\\eclipseWorkspace-java\\dsjtest\\lib\\dsj.dll");


Hard-coded paths aside (this is easy to fix), this is really ugly. The use of reflection to modify the inner works of the ClassLoader is about as not supported as code gets. But at the moment I am out of other ideas…

So if you are reading this and understand this stuff, then please let me know the right way to do this! Thanks in advance.