I'm surprised that more people aren't crowing about iTunes music sharing. I have a Mac laptop with 2000 songs on it. I bring it to work every day. I told the people in my office to download iTunes so they could listen to my music. Within a day, I not only had people linking to my machine but also had 10 people sharing their music too. The fact that Windows finally has reasonable and dead-simple community music sharing shouldn't get lost in the discussion over ITMS, whether iTunes supports XYZ player, or whether it has feature Z from Winamp.
Uh, a Palm pilot doesn't boot when you turn it on. It merely comes out of sleep. The only time it boots is when you hit the reset button on the back. Then it takes about 5-10 seconds to boot.
However, there are a lot of embedded devices that do need to boot quickly. Automotive electronics like your radio, Nav-system, etc.. do boot up when you turn on the car, at least today they do.
FYI. LabVIEW is not an interpreted language. It has a compiler under the hood that takes your program and generates x86, PowerPC, etc.. machine code. Since the syntax check happens as your are editing, the compile is very quick and you don't notice that it's there (since it doesn't need to generate errors, etc..) The only version of LabVIEW that was interpreted was LabVIEW 1 and it was slow (hence the addition of the compiler)
Re:Qt if you need Win32
on
GTK-- vs. QT
·
· Score: 3, Interesting
Relying on a library that does UI emulation is a double-edged sword though. Since the emulation effectively replaces the native UI code, your app will lose all leverage from upgrades to the OS services. For example, an app that natively calls the Windows menu manager will automatically get the new windows XP look and feel for its menus. However, an app that uses a library that emulates the native OS will still have the old look and feel until the emulation library is upgraded. Since look-and-feel issues are the biggest gripes you will get from users when developing a cross platform library, this is not a decision that should be taken lightly.
I've worked on two 1 million+ line sourcebases that were cross platform. One used a commercial porting library that was closed source but we had the source license for it. This was a losing proposition. If there was a bug, we could fix it in the library. However, that was a poor long-term solution because we were just patching the library rather than building a long-term cross platform infrastructure for our product.
The second sourcebase I worked on used a home-grown UI abstraction. This one is a lot better because we have the ability to add or remove emulation as we wish. If we have an OS that doesn't support the services we need, we emulatate it. If the OS does support the services we need, we go directly to the OS and gain native look and feel with much less effort.
For this reason, I recommend libraries that
a) Provide a platform-neutral interface
b) Implement the functionality by eventually calling the OS calls required to implement the functionality
c) Is provided in source form so that you basically "own" the library. That way, any changes you make to the library improve your own long term situation.
The only library I've seen that fits that requirement recently is wxWindows but I haven't used it for a real application so I can't comment on its suitability.
Congressmen listen to letters, whether email, laser printed, or hand written. They key is if you are in their district. They listen to the people who will vote for (or against) them, that's it. So, spamming all 535 representatives won't get you anywhere. Sending a personal email to the three (2 senators and 1 rep) who represent you will actually get you somewhere. So what are you waiting for.... start writing
Of interesting historical perspective, 802.11 has been in committee for at least 6 years. In fact, when its first draft came out, it wasn't one standard, it wasn't even two incompatible standards, it was FOUR. There were two frequencies to choose from and there were two transmission methods (frequency hopping or direct-sequence spread spectrum) that could be used. You could be "compliant" by supporting just ONE of the four combinations. It basically guaranteed that the only devices that would talk were ones that came from the same vendor. If they had picked one frequency and one transmission method, we would have had easy wireless connectivity a long time before the AirPort came out. I guess the Bluetooth community hasn't quite learned from that experience... Pity.
Slashdot Mirror
I'm surprised that more people aren't crowing about iTunes music sharing. I have a Mac laptop with 2000 songs on it. I bring it to work every day. I told the people in my office to download iTunes so they could listen to my music. Within a day, I not only had people linking to my machine but also had 10 people sharing their music too. The fact that Windows finally has reasonable and dead-simple community music sharing shouldn't get lost in the discussion over ITMS, whether iTunes supports XYZ player, or whether it has feature Z from Winamp.
Uh, a Palm pilot doesn't boot when you turn it on. It merely comes out of sleep. The only time it boots is when you hit the reset button on the back. Then it takes about 5-10 seconds to boot.
However, there are a lot of embedded devices that do need to boot quickly. Automotive electronics like your radio, Nav-system, etc.. do boot up when you turn on the car, at least today they do.
FYI. LabVIEW is not an interpreted language. It has a compiler under the hood that takes your program and generates x86, PowerPC, etc.. machine code. Since the syntax check happens as your are editing, the compile is very quick and you don't notice that it's there (since it doesn't need to generate errors, etc..) The only version of LabVIEW that was interpreted was LabVIEW 1 and it was slow (hence the addition of the compiler)
Relying on a library that does UI emulation is a double-edged sword though. Since the emulation effectively replaces the native UI code, your app will lose all leverage from upgrades to the OS services. For example, an app that natively calls the Windows menu manager will automatically get the new windows XP look and feel for its menus. However, an app that uses a library that emulates the native OS will still have the old look and feel until the emulation library is upgraded. Since look-and-feel issues are the biggest gripes you will get from users when developing a cross platform library, this is not a decision that should be taken lightly.
I've worked on two 1 million+ line sourcebases that were cross platform. One used a commercial porting library that was closed source but we had the source license for it. This was a losing proposition. If there was a bug, we could fix it in the library. However, that was a poor long-term solution because we were just patching the library rather than building a long-term cross platform infrastructure for our product.
The second sourcebase I worked on used a home-grown UI abstraction. This one is a lot better because we have the ability to add or remove emulation as we wish. If we have an OS that doesn't support the services we need, we emulatate it. If the OS does support the services we need, we go directly to the OS and gain native look and feel with much less effort.
For this reason, I recommend libraries that
a) Provide a platform-neutral interface
b) Implement the functionality by eventually calling the OS calls required to implement the functionality
c) Is provided in source form so that you basically "own" the library. That way, any changes you make to the library improve your own long term situation.
The only library I've seen that fits that requirement recently is wxWindows but I haven't used it for a real application so I can't comment on its suitability.
Good luck
Congressmen listen to letters, whether email, laser printed, or hand written. They key is if you are in their district. They listen to the people who will vote for (or against) them, that's it. So, spamming all 535 representatives won't get you anywhere. Sending a personal email to the three (2 senators and 1 rep) who represent you will actually get you somewhere. So what are you waiting for.... start writing
Of interesting historical perspective, 802.11 has been in committee for at least 6 years. In fact, when its first draft came out, it wasn't one standard, it wasn't even two incompatible standards, it was FOUR. There were two frequencies to choose from and there were two transmission methods (frequency hopping or direct-sequence spread spectrum) that could be used. You could be "compliant" by supporting just ONE of the four combinations. It basically guaranteed that the only devices that would talk were ones that came from the same vendor. If they had picked one frequency and one transmission method, we would have had easy wireless connectivity a long time before the AirPort came out. I guess the Bluetooth community hasn't quite learned from that experience... Pity.