

VLC for the new Windows 8 User Experience ("Metro") - PaulHoule
http://www.kickstarter.com/projects/1061646928/vlc-for-the-new-windows-8-user-experience-metro/posts/366106?ref=email&show_token=dd67c6b0e2aa990e

======
ComputerGuru
I'm all for funding 40k pounds (~65k USD) for VLC (they deserve it), but 40k
under the guise of Metro seems a bit much, no?

~~~
jbk
Well, no, this is not too much.

This is an excellent question.

Designing a UI above VLC for Metro is quite easy, and we've already done some
proof of concept. Finding a designer would be simple and 1k$ for the project
would be too much already :) It would take a couple of months and be done with
it.

The issue is to get on the store. And this is hard.

Why is that?

VLC (and its underlying libraries, including codecs, networking and demuxers)
represents around 7M LoC of C, C++ and ASM. All of this is very C99 code and
inline ASM. Visual Studio cannot eat that in any way. Believe me, we tried. A
lot. So we need to compile the VLC for Windows on Linux, using gcc+mingw.

Unfortunately, this does not work on WinRT ("Modern UI" or whatever you like
to call it). WinRT restricts a lot the Win32 APIs. And only Visual Studio
knows which ones. Oh, and the BSD sockets are gone...

So, we need to change and update the toolchain, fix MingW for WinRT, rewrite
the code that is using Win32 APIs since 10 years (and in all underlying
libraries too...), write a new UI above this, fix the code using HWND for
rendering, port the audio and video outputs, work-around the sandbox for DVD
playback, probably write a WinSock2 replacement library to build all the
cross-platform libraries that expect a BSD-socket-like library, etc...

Add to that the need to modify MingW to output dlls that we can load on ARM
(Windows RT) and fix all the same different APIs for WP8.

Of course a lot of the work is not really on VLC, but on being able to compile
for WinRT with open source tools, and a lot will be re-usable.

So, yes, we will need quite a few developers, and therefore money.

~~~
Todd
It sounds like it's going to be a real challenge, then. Much of the
restriction around API usage is related to IO and other things that can block
for more than about 50ms. As you know, the APIs that are allowable have been
converted to be asynchronous, or have been replaced entirely with an async
equivalent (more or less). This will make it difficult to just link with a gcc
lib unless it's been purged of these references. In addition, there are no
database APIs, for example. So it's really a crap shoot about how much
difficulty a given project will take to port.

~~~
PaulHoule
Async comm is relatively easy to deal with in the context of media players
than it is in other applications because in media players there is a fairly
direct flow of information from a file or a network connection to the video
and sound subsystems.

If you're building the kind of app I was building a few years ago, such as
semantic graph editors, where a change in one UI element might have effects
that propagate to other UI elements in an uncontrolled way, then, yes, the
async comm in Windows 8 (the same problem that exists in Javascript, Flex and
Silverlight) requires you to have a systematic approach to how information
gets into the app.

(One thing I'd definitely note is that the Windows 8 apps like "Photos" and
"Mail" are really a joke when you compare them to the Windows 7 era "Windows
Live Essentials", which are really competitive -- Windows Live Essentials can
handle mail spools on my crappy 2GB shojou netbook that destroy Thunderbird on
a 32GB machine. My experience is that async I/O sets an upper limit on the
complexity of what you can do)

VLC will have the option of bending their UI to be something that fits the
Metro mold easily, so async I/O and comm should not be such a big deal.

~~~
Todd
You make a good point about the linear flow that's typical in media players. I
haven't looked at the VLC source, so I'm not sure about how it's structured.
With 7M LOC, I'm guessing that there might be some entanglements. The async
model causes the async pattern to propagate all the way up the call chain. The
I/O and other async dependencies would have to be decoupled from the gcc
library to minimize impact on the existing code base.

------
dkersten
Not really on topic, but am I the only person who finds metro to be really
really REAllY ugly?

~~~
untog
Yes it is off topic, and no you aren't. There have been lengthy, lengthy
discussions between members of HN of whether Metro is a good or bad thing. I
think at this point we probably all have to agree to disagree.

------
albertzeyer
Previous discussion: <http://news.ycombinator.com/item?id=4848569>

------
TommyDANGerous
VLC is amazing, I will always be down to donate to them.

------
Torn
I've been using VLC for _years_... time to contribute back.

Cheers guys

------
CrLf
You know what I would like to contribute for? To bring the old Mac interface
back.

(BTW, I already contributed to VLC in the past. It's very useful and I think
they deserve it.)

~~~
jbk
You can have the old interface back with a few clicks...

