INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: JimH on June 20, 2012, 09:29:24 am
-
For some time, we've been migrating our source code away from the Microsoft model.
For those who aren't software developers, Microsoft offers great development tools as part of Visual Studio, the Visual C++ development kit. They include something called Foundation Classes (http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library) and its successor .Net (http://en.wikipedia.org/wiki/.NET_Framework)
Both packages are a very large set of specialized source libraries that can be used to do things like draw on the screen or build menus. The good news is that they make development much easier and faster. The bad news is that they tie a developer tightly to Microsoft Windows.
So we began moving away from that model five years ago. Whenever we could, we wrote our own classes for fundamental tasks. Following a recent final sprint to the finish line, our development team is now within sight of the finish line. As we did with Red October, we've built a complete replacement for these Microsoft development tools. We have our own source libraries for all the functions we need. The current release of MC17 is built with these, so we know they work well.
This means that we can port MC to one or more other operating systems. It won't be trivial to do, but it will be massively less difficult.
Congratulations to Matt, John, Bob, Yaobing, and Keenan. Thanks for all the work you've done.
-
Fascinating. I knew you were up to something like this, but didn't realize the scope. Well done!
PS. It seems like that foundation might be something other developers would be interested in as well. Just saying...
-
I’m impressed.
-
Wow.
-
Congratulations on laying the foundation for the future.
-
Congratulations. I'm sure you got Keenan up to speed with some Cliff's Notes (http://en.wikipedia.org/wiki/CliffsNotes). ;)
"The Source, Baby, it's easier with Cliff's Notes'' ;D
-
with some Cliff's Notes. ;)
Jim does have a source for those, after all. ;) ;D
-
Super good news, I can't wait to have a Mac Version of MC :D
-
Respect! This right step has been a strategic decision for new markets. :)
I am working for the development department of a big car manufacturer and we are using a same tool called "Baukastensystem" (model kit system) to develop economically many models for the worldwide markets.
How many Windows users are interested in buying JRiver´s MC? It will be a little number relative to the big number of Windows users. But enough to make this product economic successful. And I suppose it will be the same number of Mac users who are interested in a high quality MC. Although the market share of Mac (5..10%) is relative low vs. Windows I will estimate that there is a chance to explore enough Mac users in this market ... if you achieve to draw the Mac users from iTunes or Amarra. MC will be placed between iTunes and Amarra as competitor of both.
Before starting a Mac version I would do a market test with Mac users who should test the actual MC17 by attendance of Windows users because Mac users are minted by the Apple world.
-
I do wonder why you didn't choose to go with a cross-platform framework like Qt for your basic functionality needs?
It reads like you re-invented the wheel on alot of things, while there are plenty of good C++ frameworks out there that can run on all the major OS'es.
-
For what it is worth.....here is my impressions on the current threads on Platform Independence and where MC can be used.
It is worth pointing out that MC has several parts, and each has there own "value" depending on the function being used:
- Server: There is a great argument that a MC Server should be ported to run on Linux given the very large base of Unix based NAS out there in addition to the Windows version but I'm doubtfull of the market for an OSX version. The only issue I see in porting to Linux is what you will do with Video Transcoding and streaming as Red October is based on third party MS Direct Show code.
- Clients: Currently JR supports both Win and Android for consumption of media. Other front end OS with reasonable market share would include Linux, iOS, OSX, WinMo. When looking at the front end the big issue I see is the handing of Video (see above). I find it odd that JR is toying with OSX support for a front end given it has such a small overall market place % for PC's and yet shuns iOS that is so very very big in it's market share. I'd suggest JR dev effort is better spent porting Gizmo to iOS (and charge for it) that an OSX client. You will have a much much bigger market but it is IMO.
-
- Client: Currently JR supports both Win and Android for consumption of media. Other front end OS with reasonable market share would include Linux, iOS, OSX, WinMo. When looking at the front end the big issue I see is the handing of Video (see above). I find it odd that JR is toying with OSX support for a front end given it has such a small overall market place % for PC's and yet shuns iOS that is so very very big in it's market share. I'd suggest JR dev effort is better spend porting Gizmo to iOS (and charge for it) that an OSX client. You will have a much much bigger market but it is IMO.
That's a very good point. If people really like a software, they should have no problem running a single windows based computer (or linux based computer/NAS if a linux server side ever sees the light of day) on the server side. And rather consume the media on Windows, Android and iOS.
-
The only issue I see in porting to Linux is what you will do with Video Transcoding and streaming as Red October is based on third party MS Direct Show code.
Can't this still be done at the (frontend) client level, or does the (backend) linux server have to do the transcoding?
I don't know, so I'm just asking.
-
Can't this still be done at the (frontend) client level, or does the (backend) linux server have to do the transcoding?
I don't know, so I'm just asking.
With DLNA, the backend checks with the front end what format it wants then servers it up in that format else you would get a whole bunch of "Format not supported" errors.
-
- Clients: Currently JR supports both Win and Android for consumption of media.
JR supports Android for the consumption of media, but not the management of media. For me (and for many users, I suspect) this is critical issue. I can use my Android phone and tablet for 90% of my computing needs, but I'm still bound to my Windows PC for managing my JRiver library.
An integral part of the JRiver experience for me is managing my tags and smartlists while listening to music. Whichever OS JRiver plans to tackle next, I hope it will include a full client for the associated mobile platform.
-
OS Market Share (http://yabb.jriver.com/interact/index.php?topic=72886.0) split
-
Congratulations. This is a huge effort but the architectural benefits will be with you (and with us, the customers) for years to come.
-
I do wonder why you didn't choose to go with a cross-platform framework like Qt for your basic functionality needs?
It reads like you re-invented the wheel on alot of things, while there are plenty of good C++ frameworks out there that can run on all the major OS'es.
This was a hard decision.
When we first started moving away from a Microsoft-specific toolkit, I believe Qt cost $10k per developer per year. It wasn't used by many (any?) top-tier applications. It required rewriting code in a way that would tie it to Trolltech / Nokia.
There were other technologies we discussed, but they also had drawbacks.
So we decided to gradually move towards a toolkit that we controlled.
As Jim stated above, much of the work is behind us now. The work did slow us down, but it also made the code better in many important ways.
-
When we first started moving away from a Microsoft-specific toolkit, I believe Qt cost $10k per developer per year. It wasn't used by many (any?) top-tier applications. It required rewriting code in a way that would tie it to Trolltech / Nokia.
You can use Qt under the LGPL, the same way you use ffmpeg for example, wouldn't have to cost money :)
Granted, it was only relicensed under the LGPL in 2009, so maybe that was too late for you.
I don't buy that argument with being "tied" to Nokia/Trolltech. Sure, you use their framework, and you highly depend on that, but it is open-source and even if Nokia would decide to kill it, it wouldn't die.
Following that logic, any outside library would be bad, and thats just insane, assuming you have to implement *everything* yourself.
-
Technical question from a novice user:
Is your independence from MS libraries why MC isn't compatible with Aero Peek/Snap/Shake and so on ? ::)
-
That did not work, even before they started to go platform independent. At least to my knowledge. So, it's probably just something that have not been prioritized to add.
I would like this my self. Especially drag and snap functionality. I use 3 monitors now, and it's bit lame how you have to minimize, drag and maximize, instead of just dragging it to the correct screen.
-
MC uses its own implementation of many UI elements (such as windows, lists, etc.), and thus the standard Windows functionality is not automatically available.
-
That did not work, even before they started to go platform independent. At least to my knowledge. So, it's probably just something that have not been prioritized to add.
I would like this my self. Especially drag and snap functionality. I use 3 monitors now, and it's bit lame how you have to minimize, drag and maximize, instead of just dragging it to the correct screen.
Understood & agreed :)
-
Wow! As a relatively new user, I've noticed that the MC GUI is way more legible than many Windows programs. I had no idea of the huge effort behind that (even if legibility wasn't your main driver). It's quite a tour de force, and with that as evidence, no one can question the abilities of the JR development staff.