Late last night (CET), we reported on the story that the VLC project needed more developers for the Mac version of this popular video player, or else the Mac variant may disappear. Just about every website out there reported on this issue, but it turns out it all got a bit exaggerated (on the internet? Surely you jest…). We spoke to VLC developer Pierre d’Herbemont to clarify the issue, and they’ve also put up a wiki page about the so-called demise of the Mac version of VLC. He also detailed what, exactly, they meant by “Apple is blocking us”.
So, how dead is the Mac version of VLC, really? Well, they surely do need developers, but the port certainly isn’t near death. The problem is that while the core of VLC is properly maintained, the old Cocoa graphical interface (1% of VLC’s code) for VLC is not. This is why there were problems in the latest VLC 1.0.x version.
They explain that the reason for this lack of maintenance is that the interface is currently being rewritten, in a project called Lunettes. This is done because the current interface “isn’t Mac enough”. Lunettes aims to solve this problem by using VLCKit, which is “pure Cocoa, Objective-C 2.0 with bindings support”. They state this will help them concentrate on features. In addition, the entire graphical appearance of this new UI can be changed using CSS. Their aim with this is to make altering the UI easier in the future.
Lunettes will also bring a number of other new features, such as the ability to continue a video where you left off when you closed VLC. It will also come with better media discovery, and you can scroll through your playlists and/or TV channels when in full screen mode. Last but not least, Lunettes is 64 bits.
Lunettes is currently still under heavy development, and more developers are most certainly welcomed. You cna take a look at Lunettes here.
So, what about the comment regarding Apple? The VLC developers stated that “Apple doesn’t want us on the Mac platform and is blocking us a lot, and refuses to explain why.” d’Herbemont clarified this for us. “This actually means that Apple doesn’t want to list VLC on apple.com/downloads,” he told us via email, “We don’t know why. That’s all.”
I’m glad this has all been cleared up.
Is the qt4 interface for VLC on the mac so horrible that they are better off starting over from scratch?
They’re doing what programmers like doing best. Create their own product.
http://www.joelonsoftware.com/articles/fog0000000069.html
That’s not necessarily a criticism, after all, open source development is supposed to be fun, but I really don’t think it’s the best for the project as a whole. However, in the end he who codes decides, so unless someone steps up to make sure the Qt interface plays nice on OSX, it won’t happen. I’ll check it out since I develop Qt stuff on Mac as well, but I suspect it will take more time than I have.
That article of Joel’s is often quoted, and indeed is probably accurate for most projects. But consider it’s central example – the abandonment of the old Netscape code in favour of what eventually became Firefox.
In hindsight, I think it’s pretty safe to say that keeping with the old code would never have led to anything like the modern Firefox. And without Firefox kick-starting competition between browsers, I don’t see that we’d have ended up with anything like the modern Web – we might, god forbid, be stuck with IE6 as the pinnacle of browser design…
I disagree. If they had refactored and replaced components in a controlled and orderly fashion instead of saying “Hey, let’s throw out most of the existing codebase and start from scratch!” they would have had a usable and markettable product throughout the entire cycle rather than a slow and buggy product, not ready for prime time (but with perpetual “awesome nightlies!”), and wouldn’t have had to claw their way back up from 1% market share or wherever the old Mozilla ended up. And arguably, they could have gotten to the current technical state of FF as fast, or possibly faster than they did. And likely with a higher current marked share than the badly trailing second place that they have managed world wide at this time. That IE’s continued huge lead and Firefox’s 25% or whatever is so often considered a ‘victory’ says more about the abysmal state of competition that we all just got used to than about the current state of competition.
Edited 2009-12-18 00:37 UTC
I find this to be a gross mis-characterization of what things were really like. I’ve been using Firefox since it was Phoenix and started somewhere around the .5 series. Back then I was still on Windows and up till then was (of course) an IE 6 user. Was Phoenix perfect back then? No. Did it have some bugs? Yes. But it was easily a better browsing experience than IE 6, even in that state. I give big time props to the devs for getting things working so well so quickly.
Eh? I suspect he wasn’t talking about Firefox – but rather the Mozilla suite (AKA SeaMonkey).
Well, that’s nice, but totally irrelevant. Netscape released their code as OSS back in early 1998. The grossly overconfident (OSS development takes place at Internet speeds!) Mozilla guys essentially decided to throw out most of the mature code and start from scratch, keeping gecko, the new renderer still under development by Netscape and not ready for prime time. Meanwhile, we got year after year of Netscape 4.x while Mozilla was unusable. Years passed… and still no product. Market share, already in decline, started dropping like a rock. In desperation, Netscape 6 was released, based upon Mozilla, and flopped badly because the new ‘start from scratch’ codebase was still not ready. Milestone after milestone went by. Finally, the browser shaped up into something that was usable. But very few people outside of the Linux and *BSD communities cared by that time. Mozilla, now with a browser that someone might want to use, had completely lost momentum and name recognition with the general public by then.
And the remainder of the 11 year history has been FF, based upon Mozilla, clawing its way up from <1% market share to the respectable but badly trailing share they have today.
So tell me again that I’m grossly mischaracteringing what happened based upon the fact that you found Phoenix sort of usable. All that tells me is that you don’t know the actual history.
Edited 2009-12-18 13:17 UTC
It’s a bad example to cite. The reason why Firefox had to take a completely new direction was because of that disastrous decision by Netscape over version 6, or what should have been version 5. That pretty much finished them and the browser off in that incarnation to the point where Mozilla had no real choice.
The mistake of deciding to rewrite from scratch was made long before Netscape 6. Netscape 6 was a desperate attempt to get some new Netscape… anything… out before the brand was completely forgotten, and all marketshare for Mozilla/Netscape was lost. Netscape 6 flopped (and badly) because the rewrite was taking *way, way* longer than expected (Surprise!) and wasn’t anywhere near baked yet.
The fact that 11 years after the foolish decision was made, FF is just now clawing its way back to the point that IE only has about a 3 to 1 lead on it makes it an excellent example of the problems Joel is referencing.
Note to people who seem a bit confused: Firefox was not a rewrite of Mozilla. It was a strip-down and streamlining of Mozilla. The stupid mistake was in throwing out so much of Netscape’s mature and tested code back in 1998 and 1999… long before Phoenix/Firefox.
Edited 2009-12-18 14:44 UTC
It was mature and tested but struggled to support CSS. Even the earliest buggiest betas of Mozilla and Netscape 6 had superior CSS support to IE6. The rendering engine was solid, most of the problems came with the decision to render the UI with XUL rather that sticking the new rendering engine in a more conservative UI.
They could have released Netscape 5 based on the Netscape 4 codebase, an alpha did appear at one point and it was an improvement on 4, but it could have done little more than keep the Netscape brand limping along.
They still did not have Microsoft’s ability to stick their browser on every windows desktop which is the thing that really unseated Netscape. If it wasn’t for that they could have kept with 4 until 5 was ready. Netscape might have had 80% of the market at one point, but that was a large percentage of a much smaller market.
It also would not have moved web standards forward at all, just created another browser to support with kludges.
Well… and the networking code and all the other stuff they decided to replace. The number one priority should have been to finish Raptor/Gecko and get it out in a usable release no matter how much they disapproved of the code quality of the rest of the code-base.
If the current code base for FF had been closed and was released for the first time, today, to a new generation of OSS developers, I’ll bet they’d look at it and say “Yuck! This is just awful! We’ve got to rewrite this mess from scratch!”. And when they came out with their first barely functional release, people would oooh and ahhh about how small and efficient and clean the new code-base was… and in several years we’d have something that was usable, well-tested, huge, and “a mess”.
Edited 2009-12-18 17:00 UTC
Yer, that’s why I mentioned Netscape 5. To skip a release number completely to try and give the impression that things hadn’t ground to a halt tells you everything you need to know about ths whole episode. Netscape might have been led to the toilet by Microsoft, but they ultimately pulled the chain.
Or webkit, that would suck…
Without Firefox, IE6-only sites would still be the norm, so Webkit would never have been able to make inroads. It is only because of Firefox that Webkit is now a viable option for anybody.
I speak as a developer who, when he has something new to build, goes out and finds somebody who has already done it, download the code and discover that it^aEURTMs an ugly, unmaintainable, over-engineered mess that^aEURTMs more effort to redesign and repurpose than to simply start from scratch.
I could have used MarkDown but it was useless for my needs so I wrote ReMarkable. I could have used a CMS, but they^aEURTMre all too bloated and changing the HTML would be a backward cow-pat shovelling mission, cleaning up their mistakes. I wrote my own. I throw away and write my own^aEUR”new and better^aEUR”tool for almost every third party piece of code I come across.
The fact is, that once a project has been started with an initial design, that project is now on a set of rails and can go in only one direction. The more steam it builds up the bigger the turning circle it has.
In every instance, it is more effort to try turn around a big, fast moving project with many people, than it is to create a new skunkworks project and go you own^aEUR”better^aEUR”direction.
It^aEURTMs why Google contributed to Firefox up to a point (paying full time developers) and then made their own browser. Firefox had gathered the steam to open the marketplace to competition, but cutting the bloat from Firefox was too difficult to do by removing things people were now used to^aEUR”their only option was to start from scratch.
This will happen, and will keep on happening, and is why even with QT4 so well developed, developers will *still* opt to roll their own^aEUR”because it would take too much effort to change the fundamental design of QT4 than it would be to just write something new.
I _hate_ Qt4 apps on OS X. They are awful, unwieldy pieces of crap. They look worse than an amateur OS X programmer starting out with their first app. At least the amateur programmer coding for the first time has XCode, the HIG, Interface Builder (which allows easy HIG sizing / placing) and a sense of what an OS X app is supposed to look like.
I am sorry if this is too harsh, but this needs to be said if the case truly is what you describe above. It seems like you are not much of a developer.
Odd, I get a few e-mails a week from people who are blown away by my code.
Perhaps then I^aEURTMm a developer who has standards higher than the average.
“The Internet is full of generic code that solves generic problems, generically.”
I think you^aEURTMll find that the truism is that _most_ code is crap. Not the other way around.
Amen. Most code definitely is crap.
as i learned in the field and from others in the field, the good developer is one who is able to write a workable solution, satisfying the requirements, in the least time possible, possibly conforming to coding conventions and maintaining code clarity throughout development (that is, assuming his code must and will be reused by others) and, last but not least, evaluating the best tools for the job, and this includes including the choice between an initial/inspirational codebase, and starting from scratch
this is because other people’s code is a solution to other people’s requirements, and the result of their development skills, mental process and coding style – so when a publicly available open source project works, but results from conventions and practices differing beyond a certain threshold (say, no unit tests because the programmer doesnt’ know about them, or thinks he can do without them – or use convoluted constructs – and be forgiven because he is oh so l33t, or simply because he doesnt intend his code to be read and resused by others) there is an inevitable cost (in time, which when you develop commercially becomes money) associated with evaluating the codebase, learning its structure and understanding what the code does, and then (notice that at this point one has already spent some time) balancing it out against the option of starting from scratch (wich has has an obious disadvantage but, may be largely preferable)
if one takes an existing project made of messy code (maybe even written by duct tape programmers ( http://www.joelonsoftware.com/items/2009/09/23.html )) to spend 6 months developing into it in order to make the software do something alike to what he needs, and coming up with a 10% larger, but equally messy, codebase; how is he a better developer than someone who, after evaluating the above open source codebase, decides to start anew, and in 6 months is able comes up with a smaller but vastly cleaner (thus more easily expandable) C# code base, complete with unit tests and all, doing exactly what he needs with roughly the same performance?
For starters, it’s Qt. QT is QuickTime.
Secondly, the long line of cross-platform toolkits and development avenues proves you wrong. Porting individually to each platform is a spectacular amount of work that merely ends up creating a dominant port where ports on other platforms, including the Mac, are totally incomplete. It’s happened with Firefox and it’s happened with Eclipse and SWT, which are both primarily Windows platforms. You’re best off starting with a cross-platform GUI toolkit and then making your own slight platform specific changes. For an application like VLC it’s possibly less of a concern.
Would you rather there were no applications there at all for the Mac, because that’s what’s at stake? As your application base grows then I’m afraid the ideas of purity don’t continue to hold, which is possibly one of the reasons why few developers in the world are interested in the Mac. That and there not being much of an installed base.
It depends what you are doing and why you are doing it. If you are doing it for fun, or it is some sort of project where you have your own skin in the game, then I fully agree with you. If you are getting paid to write code, typically it is to get a job done, not to create a masterpiece. There is definitely such a thing as taking pride in your work, but re-inventing the wheel for every little thing because you feel it is more elegant is never what the customer is paying you for. There is an evaluation process when choosing what to use for any piece of technology: does it do what i need it to do? is it supported? is the cost to use it less then the cost to roll my own? is it extensible in the ways I will probably need it to be extensible? is it improving at an acceptable rate? none of these are black and white questions, and all of them are important if you are going to make the the right kind of decision that people pay programmers to make.
Not only this. If you’ve ever worked with large projects — open or closed and for money or for fun — something that takes years and years to write by a team of programmers, you quickly learn that rewriting is hardly an option, at least an option for you to make.
Or if you’ve ever worked within a large team.
Or if you’ve ever worked with a mature codebase.
Or or or.
As someone referred to Joel (on software), a quick pick could also be:
http://www.joelonsoftware.com/articles/fog0000000069.html
The title is: Things You Should Never Do, Part I.
Edited 2009-12-18 15:25 UTC
That’s called “not invented here” syndrome, and is shared by majority of developers.
It’s an unfortunate glitch in programmer psyche that code is easier to write / design than read / understand / debug. That’s especially prominent if the code is a bit on the overengineered side (frameworkitis…)
Edited 2009-12-18 14:42 UTC
It’s jut not Mac. Stands out like a sore thumb. Not really the case on Windows because there’s no unified look. Fits perfectly in KDE because it uses Qt. Fits well in even GNOME to lesser extent when using QGTKStyle.
I wonder if that really matters for a media player. Media players really require UI’s quite far removed from the usual routine of “File Edit View Search Tools” anyway. For example in Gnome, Totem blends in seemlessly with the desktop… but feels like a text editor that’s been modified to be a media player. VLC clashes a bit with the HID and is as overly-busy as any KDE app. But for a media player, I think that’s probably appropriate.
That’s actually a good point: it certainly captures my opinion of Totem’s appearance quite nicely.
By the same token, tho, iTunes, say, manages to simultaneously have probably the best media-player interface around, and to look very “mac.” (With the disclaimers that I am not an iTunes user, I do not have a high opinion of it, I don’t even own a damned Mac, I use VLC continuously and love it, etc.) Rhythmbox, for that matter, is a not-awesome-but-good-enough media player, with a perfectly usable (with an amusingly iTunes-like) interface that fits in quite nicely with Gnome. So it is at least possible to have something that’s simultaneously a good UI for a media player, and a UI that’s consistent with the rest of the environment.
You asked my question. I believe Qt4 is cross-platform and it improves, why use Cocoa when devel resources could be spent on other issues?
Having a native interface that works the way other applications work would be desirable on any platform.
The interface VLC uses doesn’t even seem to be finished, with several functions not connected to the buttons they represent. It wouldn’t seem to be a fault with Qt but who knows for sure what the problem is?
As opposed to starting completely from scratch with no Mac UI whatsoever, and nothing that can be improved currently, thereby creating even more work? Yer, I’m sure that would solve their problems.
Exaggerated? That’s understating the case a bit…. how about *dead wrong*!?
Yes, well, that’s really the whole joke, isn’t it?
The allusion is to a quote attributed to Mark Twain, who was reported to be dying in London. He told the man who found him at his house in New Haven something like “the reports of my death are greatly exaggerated.”
s/ cna / can /
It doesn’t look Mac enough? Just wondering, what does this mean? Will the Mac version look completely different from the other OS’es.
This is more or less a problem with multi platform development. Keep the look consequent with the OS it is running on, or keep the look of the program consequent among all versions.
I have used the program on Linux and Windows, and if I would ever use OSX, and run VLC, I would like to see the interface I am familiar with.
It^aEURTMs like the difference between Camino and Firefox on Mac. Sure they look samey enough, but Camino under the hood is a whole world more native on the Mac because of all the little touches. People who^aEURTMve used the Mac platform for several years care about these things because they grate when it^aEURTMs not done properly. And I^aEURTMll regret saying this, but those on other platforms looking in on Mac stories wouldn^aEURTMt understand this. I^aEURTMm still discovering nice little touches in OS X four years later. Being native matters more on OS X than any other platform.
I’d argue that being native on OS X is about as important as being native on BeOS.
Sure, you can get something else to run, but it’ll suck in comparison.
Or to put it in a less gentle way:
You can put Grandma in a dress and take her to prom, but it doesn’t mean she’s going to get lucky.
Edited 2009-12-18 15:05 UTC
Unless, of course, there *is* nothing else to run, because none of the relatively few available devs for your platform have yet to get around to reinventing that wheel. Or maybe the ‘native’ alternatives look real pretty, but suck on features…
If your and the GP’s attitude is typical then no wonder VLC is having problems on the Mac side. Apparently, VLC would only be welcome on the Mac if it were a native OSX app.
Typical platform/DE elitism. No different than GTK/Qt fanboys refusing to use Qt/GTK apps just because they don’t ‘blend in’.
How ironic that ‘that other platform’ thats kicking all of our asses is controlled by a company that, for whatever reason (by accident or incompetence, you decide), never did get around to establishing a deep, consistent, universal look-act-n-feel (even this company’s own apps don’t all look/behave the same) and thus their platform never really fell into this elitism trap… and that is probably part of the reason *why* they are kicking our asses. They’re too busy cranking out more apps to worry about how things are ‘blending in’.
Me? If it works for me, and its better than the alternatives, I’ll use it, no matter its origin.
Anyway, ya’ll have fun reinventing all those wheels, I’ve got work to do…
Enjoy all the stress from your clunky, mismatched, mess of a UI.
Funnily enough I don’t have any stress using clunky interfaces and mismatched GUIs. I get on and just get on and use something to get a job done.
As for applications something should not be rewritten if it does a job adequately. Recoding wastes time (which is better spent elsewhere) and puts a project in jeopardy.
Recoding stuff from scrach only makes sense when the current implementation is unworkable.
Customers simply don’t care as long as something does the job for them and is delivered on time.
You can talk about nicely written code etc etc, but delivering something which works on time is what gets the bills paid. Sometimes you gotta bodge and hack to get stuff to work when time limits are tight.
I beg to differ. Sometimes, you have to work like that. But don’t forget that this kind of behavior is the main cause that ITC has such a bad reputation delivering products that are not ready for the users. After all, producing only “good enough” products is also a main factor that we learned to live with bad and clunky user interfaces. Sometimes, you just need somebody like e. g. Apple that does is more or less “right” and not just “good enough”.
I’m glad that there are developers that think further than just looking at code and features. At the end, products live or die having user acceptance. And you don’t get user acceptance just with features because users will see those features through the user interface. Having a bad UI for a cool feature is wasting development resources: the feature should have been skipped right from the beginning ..
Dude, what *stress*?
Its not like these different GUI-based apps are really, fundamentally that different from one another. They’ve all got windows, buttons, checkboxes, menus, etc.
My idea of stress is trying to parse one of g++’s template instantiation errors (usually about 2 screens long). That’s stress. Using a (slightly different) GUI is not.
Seriously, stress?
Sure. And there’s a difference between someone who prefers native app (while still being willing to put up with non-native if necessary), and someone who just automatically turns their nose up at any non-native app. The former is a reasonable position, the latter is the very definition of putting form over function.
That’s how I read Bryan’s post (as an example of the former sentiment), I don’t really see where you’re getting the platform elitism thing from.
That’s a bit of a false dichotomy. For one, there’s no shortage of GUI visual inconsistencies to be found on OS X (even among Apple’s apps). And given that there are many more applications available for Windows, there’s naturally going to be a greater variety of visual appearances.
I doubt Microsoft’s policies/philosophies on application visuals has much to do with it. If a lack of visual standards makes a platform a success, then Java GUI apps should have overtaken everyone else years ago.
I was kinda also responding to Kroc’s post as well. As for Bryan’s post, it was the Grandma joke at the end that made me think he was in the latter camp (where Grandma == a xplatform app), but I may have read it wrong.
Oh I dunno, seems to be quite a bit of that here on OSN.
Yea, I’ve heard that too (never used Apple myself), which just makes it harder for me to understand the typical fanboy responses about this issue. Sounds to me like Kroc would want to disagree with you on this, for example.
Agreed, thats why I said it was only ‘probably part of’ it. The main reason was that MS’s was handed a defacto monopoly position early on due to IBM’s lack of foresight at the time.
If it weren’t for MS not wanting Java to succeed on their own (dominant) platform, and even now doing everything they can to kill it (.NET), then who knows, maybe Java *would* have done better?
Kinda hard to succeed when the 800lbs gorilla of your market is trying very hard to put you 6 feet under.
I think Bryan was indulging in something of an in-joke reference amongst BeOS users – there’s a comment Jean-Louis Gassee made about Win98 from back in the day, don’t remember the exact quote but I paraphrase:
“Sure, you can dress grandma up in a multimedia mini-skirt and take her out to the nightclub – but that doesn’t mean she’s gonna score.”
You’ll get no argument from me there. IMO, the only antidote is to be a completely shameless platform whore
(speaking as someone using a KVM that’s currently connected to an old G4, a Linux server, a BeOS PC, and a PC running XP).
IMO that’s because the distinctions between aesthetics, design, and usability are often blurred (as a result of those terms being used as if they were interchangeable).
My outside-looking-in perspective is that Mac users are typically willing to put up with inconsistent visuals from a UI, as long as it conforms to certain Mac conventions (global menu bar, uses the standard keyboard shortcuts, etc).
Agreed there. IMO, what it comes down to is: Microsoft is entrenched, and they’re aggressive about maintaining their entrenchment.
It’s hard to say. I do find it amusing that Java didn’t really deliver on its initial promise, yet Flash has succeeded in much the same space.
Aw… Come on!
Mac developers and mac users are so weak sissies?
I don’t believe so…
In Amiga and MorphOS VLC is developed by ONE SINGLE programmer who makes it all by himself and updates are released at a certain reasonable steady rythm.
Sure if any mac projects requires a team of X persone (where X is major than 10 elements) then that’s means that Mac users want just their Momma prepare them the pappa any day…