While I applaud the technical acheivements of the Mono team, the day that significant numbers of developers can buy MS's development tool stack for next to nothing, develop their applications in Visual Studio and then just click a button to deploy to an array of cheap Linux servers running Apache/MySQL/Mono, is the day that I suspect MS will realise they've gone a little too far towards commoditising their own cash cows out of existence.
What they'd do about it is anyone's guess, but I suspect an organisation as paranoid as MS has already thought about this fairly carefully.
Could you let us know which setting this is? I sometimes think I can hear some distortion in the upper register even with LAME 192kbps VBR and would love to have a way to reduce it.
Hopefully this goes some way to averting the fears expressed recently by Bob Cringley in a recent article.
His prediction: VoIP may have seen its best days and faces slow extinction by cartels of carriers using QOS to throttle all but their own VoIP services.
Well, I hope this won't make you need to exhale and shake your head sadly again, but what I meant was that even if you pick up native themes by a platform inferface (which for example Swing in JDK 1.4.2 does on Windows to emulate XP themes), you still don't get the look and feel right. Do you do the drop-shadows on menus? Menu fade-in and combo box slide-down? Do you snap the mouse to the default button in dialogs? Handle my funky font preferences? Handle multiple screens properly? How do I send text into your text boxes from my speech recogniser? etc.
Yes, you can code these if you have all the resources in the world but, as Swing's developers now know, you don't. Or you can try to extend/hack the system widgets, but you run into problems with cross-platform differences, a problem likely to be greatly exacerbated by the fact that MS couldn't give a damn about whether S.W.F is portable or not.
Re:What applications are there
on
Mono Beta 2 Released
·
· Score: 3, Interesting
And surprise, surprise, these look like Unix apps running in an OS X window frame. The same with WINE-based S.W.F apps running on Linux - they look like (daggy) Windows apps.
If the toolkit doesn't map to the native widget set, not only does it tend to look crap, it also behaves wrongly (try bringing up a context menu in a GTK app ported to Windows and running on the second screen - the menu appears as an orphan on the primary screen). There are a thousand little things the emulation writers get wrong and don't even realise it.
A random collection of other things you miss with a non-native widget set:
Things like system speech extensions usually don't work
Screen movie capture systems do a sub-par job
Remote desktop performance suffers
Things like system themes and ClearType often don't work
This took me years of banging my head against Swing's crappy Windows L&F to understand - it looks perfect in a demo, but is filled with so many buglets it gives me a headache thinking about it. After switching to SWT I breathed a sigh of relief that at least I wouldn't have to apologise for things like menus popping up under the toolbar (or on the wrong screen).
Slashdot Mirror
While I applaud the technical acheivements of the Mono team, the day that significant numbers of developers can buy MS's development tool stack for next to nothing, develop their applications in Visual Studio and then just click a button to deploy to an array of cheap Linux servers running Apache/MySQL/Mono, is the day that I suspect MS will realise they've gone a little too far towards commoditising their own cash cows out of existence.
What they'd do about it is anyone's guess, but I suspect an organisation as paranoid as MS has already thought about this fairly carefully.
Could you let us know which setting this is? I sometimes think I can hear some distortion in the upper register even with LAME 192kbps VBR and would love to have a way to reduce it.
Hey, any code base that includes a "libpr0n" module can't be all bad.
His prediction: VoIP may have seen its best days and faces slow extinction by cartels of carriers using QOS to throttle all but their own VoIP services.
Yes, you can code these if you have all the resources in the world but, as Swing's developers now know, you don't. Or you can try to extend/hack the system widgets, but you run into problems with cross-platform differences, a problem likely to be greatly exacerbated by the fact that MS couldn't give a damn about whether S.W.F is portable or not.
If the toolkit doesn't map to the native widget set, not only does it tend to look crap, it also behaves wrongly (try bringing up a context menu in a GTK app ported to Windows and running on the second screen - the menu appears as an orphan on the primary screen). There are a thousand little things the emulation writers get wrong and don't even realise it.
A random collection of other things you miss with a non-native widget set:
- Things like system speech extensions usually don't work
- Screen movie capture systems do a sub-par job
- Remote desktop performance suffers
- Things like system themes and ClearType often don't work
This took me years of banging my head against Swing's crappy Windows L&F to understand - it looks perfect in a demo, but is filled with so many buglets it gives me a headache thinking about it. After switching to SWT I breathed a sigh of relief that at least I wouldn't have to apologise for things like menus popping up under the toolbar (or on the wrong screen).