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?

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.

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.

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.

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.

The asynchronicity stuff has made it into many a presentation, but it's not really about that. If it were all about async maybe someone can tell me why they're not allowing I/O completion ports and APCs. It's about not trusting developers, and rooted in an overreaction to the perceived problems in the existing Win32 ecosystem. You can do async I/O with Win32 just fine, but Microsoft now believes you're too stupid to do it.

Also, there is a port of sqlite to WinRT.

You're right, that's not the only issue. The "Windows Store" apps are limited to a specific subset of what we're accustomed to coming from Win32 and COM. Much of this is designed to sandbox applications.

So there's a new API and the new API is async all the way through. The async aspect gets a lot of attention because it's so pervasive, and can require some adapting. But you're right, the limited API can have a larger impact on a porting effort.

BTW, my point about no database API is in reference to the lack of System.Data (ADO.NET). The assumption is that people are expected to consume data through Web services. It's great that SQLite supports WinRT, though. That definitely fills a big need.

> It sounds like it's going to be a real challenge, then.

Yes

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

We will do the database APIs, in fact :)

Wow. Sounds like anyone who's ever made Windows software and wants to port it to Windows 8 store is going to have to go through a lot of pain.

If it's not very computationally intensive program, using javascript/html is starting to make a lot more sense

Agreed. But multimedia is computationally intensive program.

Do you think VLC will be the better for it?

Considering Microsoft's actions with Windows 8 for ARM (Win RT), the classic desktop is probably going to be depreciated in the future. This kind of work needs to be performed at some point, and being allowed in the Windows Store is also a very nice payoff. I don't know how much work would be required for Windows 8 ARM support for VLC, but this work definitely gets it closer (knowing your UI will work is a good motivation to get the backend sorted).

And knowing Microsoft's track record with new APIs (cough Silverlight cough WPF cough COM cough), WinRT should be deprecated in, what, 5 years?

Personally I feel like the 40K GBP should go to all the devs of VLC combined. Porting to metro is only a small part of VLC itself, and is not worth 40K GBP.

What makes it worth that money, and that people will pay for it, is that VLC is the hard work of all the _previous_ developers.

So while I'm all for giving people money to make an open source project advance, I feel a little wrong about this very one.

What? then have no VLC for metro because they gave the kitty away and had no work done at all? Defeats the purpose don't you think?

No, it'll be done anyway. Do you think ppl got paid to make vlc or mplayer to begin with?

It seems too hard for the human mind to understand that the people who make 90% of the work for free going unrewarded is wrong. Now then again, it certainly fits the way the rest of the world works.

You totally miss the point. The point is to speed up the development for Metro.

The point is to raise money, period. That's like saying a knife is not made to cut.

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

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.

I am one. The thing with Metro is that it's just too much clutter on big screens and strange colour choices by Microsoft. Out of 15 or so options in Windows 8, there is exactly 1 that looks good!

And the jumping between Metro and Desktop environment is just too hectic!

An analysis of Metro http://www.riagenic.com/archives/487

Previous discussion: http://news.ycombinator.com/item?id=4848569

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

I've been using VLC for years... time to contribute back.

Cheers guys

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

I'd like to invite you to have a look at my blog post detailing on how to customize the new Mac UI to suit your needs:

http://feepk.net/customizing-vlc-for-mac

If this isn't enough for me, create requests on https://trac.videolan.org/vlc/ so we can see what we can do!

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