Your comments in The Art of Unix Programming about Apple/Mac developers being diametrically opposed to Unix developers in development style and emphases (designing simple, user-friendly interfaces from the outside in) were quite interesting. I am wondering about your perspective on Apple now. My interest is specifically in Apple's contributions to open-source (WebKit and LLVM, chiefly) and your take on those. It seems to me that Apple has done quite a bit to foster an alternative ecosystem to the GNU environment, for instance in FreeBSD's adoption of clang as their default compiler; and also it seems to to me that WebKit has supplanted Gecko as the most widely used browser framework. Curious about your viewpoint here.
...than either AOO and LO. Much more optimized for OS X. And its engineering team of two is supported by their user base, not by IBM or Oracle or whosever, so that they can work full-time on improvements. Still open source, of course (GPL). It's a real success story. See http://www.neooffice.org./
I see no problem with requiring payment from users even if the product is open-source. How do you fund development? I happily paid the $10 to the NeoOffice developers to download the latest binary of NeoOffice. And I paid the two bucks for Growl. In the case of NeoOffice, the $10 is worth it to save myself the 24 hours or so it takes to build the entire behemoth. As for Growl, it would have been better had the source been available from the get-go, but it's a small developer team that's overwhelmed with support requests because 1.3 is actually a huge update. I think they're prioritized correctly.
If paying for an OSS product offends you, consider it a service charge for the convenience of a pre-compiled binary. "Support services" are one of the few Slashdot-approved ways of actually getting paid for your OSS work, aren't they?
This sounds very promising and interesting--a robust cross-platform GUI-development platform. However, I've always been a bit baffled by the idea of Mozilla/XUL as a "development platform." It is so unlike the environments I'm used to (Tcl/Tk, AppleScript/Cocoa, Python/wxPython) that I'm not clear what one does with it. So here are some questions:
1. Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language? (i.e. is there finally a good reason for a non-web-dev to learn JavaScript?)
2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)
3. Can anyone point me to applications that already exist that make use of Mozilla as a development deployment platform? I'm already familiar with Firefox, Thunderbird, and Komodo. Are there any others? (i.e. that are standalone apps and don't run as Firefox extensions, say?)
4. What kinds of applications are *not* feasible with this development platform?
You only need to do this if you don't provide source with the binaries. That's one method of compliance, but not the only method. It's legal (though probably not shrewd from a business standpoint) to charge $10,000 for the binary and source package.
As I understand it, developing KDE-Darwin natively for OS X is more difficult than keeping KDE-X11 up-to-date, by a few orders of magnitude. Qt is cross-platform, but KDE is not. A lot of X11-related stuff in KDE needs to be patched/worked-around to work well in the Aqua environment. The main KDE-Darwin developer, Benjamin Reed, has chosen to focus on keeping KDE updated in the Fink/X11 environment. It's simply a matter of time: there are only 24 hours in the day, he has a full-time job, he does a lot of other things for Fink since he is one of the project leads, and (this is significant) he was really the only person doing work on making KDE native, on an ongoing basis, to begin with. Some people have helped out here and there, but there's not exactly a large pool of developers pitching in. In fact, I believe he's said more that once on his blog that if anyone wants to step up and take over leadership of the KDE-Aqua project, he'd gladly step aside.
Inkscape.app runs fine on my Mac (10.4.2), but it looked ugly. I decided to do what the developers of GimpShop and load an Aqua-style skin, Glossy P http://art.gnome.org/themes/gtk2/571. It does a fair approximation of the Aqua appearance, and believe it or not, it helps: makes the contrast between Aqua and X11 less jarring.
To load Glossy P, open the app bundle, navigate to/Contents/Resources, create a directory called/share/themes/Default, and put Glossy P (which untars to a folder called Gtk-2.0) in there.
It would be nice to have a native Aqua version, but porting GTK isn't trivial. There has been a long-running effort to port GTK 1, which looks awful (hardly different from an Aqua-themed X11) and barely runs, and a more recent effort to port GTK 2, which is still in the early phases. Given this situation, I'll gladly use an X11 version in an app bundle. What a good idea! And, Inkscape 0.42 runs much better than previous versions.
I first tried NeoOffice/J a year or so ago. It was huge, took forever to boot, and ran dog slow. I wondered: why on earth would anyone rewrite a beast like OO.org in Java?? Didn't realize the Java part was a lightweight wrapper around the OO core.
Anyway, I went back to using OO.org X11. It's huge, and runs pretty slow, and looks like crap, but it works. The Start OO.org AppleScript launcher, which provides an icon to start OO.org, and also provides support for OO filetypes with icons, is a nice supplement.
After seeing this today, I tried the current version of NeoOffice/J. I didn't realize it was this far along. A real Mac menubar! Aqua print dialogs! Starts up reasonably fast! No X11 required! Compared to OO.org X11, this is already a native port. Yes, it has a little further to go, but my gosh, what a good job for a project with two or three developers.
I posted a long review of Scribus 1.1.4/1.1.5 here.
I publish books for a living. Word, InDesign, Corel Draw, and Photopaint are part of my daily workflow. Scribus performed quite capably with some rough spots in a task that I usually handle with InDesign.
Slashdot Mirror
Your comments in The Art of Unix Programming about Apple/Mac developers being diametrically opposed to Unix developers in development style and emphases (designing simple, user-friendly interfaces from the outside in) were quite interesting. I am wondering about your perspective on Apple now. My interest is specifically in Apple's contributions to open-source (WebKit and LLVM, chiefly) and your take on those. It seems to me that Apple has done quite a bit to foster an alternative ecosystem to the GNU environment, for instance in FreeBSD's adoption of clang as their default compiler; and also it seems to to me that WebKit has supplanted Gecko as the most widely used browser framework. Curious about your viewpoint here.
...than either AOO and LO. Much more optimized for OS X. And its engineering team of two is supported by their user base, not by IBM or Oracle or whosever, so that they can work full-time on improvements. Still open source, of course (GPL). It's a real success story. See http://www.neooffice.org./
I see no problem with requiring payment from users even if the product is open-source. How do you fund development? I happily paid the $10 to the NeoOffice developers to download the latest binary of NeoOffice. And I paid the two bucks for Growl. In the case of NeoOffice, the $10 is worth it to save myself the 24 hours or so it takes to build the entire behemoth. As for Growl, it would have been better had the source been available from the get-go, but it's a small developer team that's overwhelmed with support requests because 1.3 is actually a huge update. I think they're prioritized correctly. If paying for an OSS product offends you, consider it a service charge for the convenience of a pre-compiled binary. "Support services" are one of the few Slashdot-approved ways of actually getting paid for your OSS work, aren't they?
This sounds very promising and interesting--a robust cross-platform GUI-development platform. However, I've always been a bit baffled by the idea of Mozilla/XUL as a "development platform." It is so unlike the environments I'm used to (Tcl/Tk, AppleScript/Cocoa, Python/wxPython) that I'm not clear what one does with it. So here are some questions:
1. Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language? (i.e. is there finally a good reason for a non-web-dev to learn JavaScript?)
2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)
3. Can anyone point me to applications that already exist that make use of Mozilla as a development deployment platform? I'm already familiar with Firefox, Thunderbird, and Komodo. Are there any others? (i.e. that are standalone apps and don't run as Firefox extensions, say?)
4. What kinds of applications are *not* feasible with this development platform?
You only need to do this if you don't provide source with the binaries. That's one method of compliance, but not the only method. It's legal (though probably not shrewd from a business standpoint) to charge $10,000 for the binary and source package.
As I understand it, developing KDE-Darwin natively for OS X is more difficult than keeping KDE-X11 up-to-date, by a few orders of magnitude. Qt is cross-platform, but KDE is not. A lot of X11-related stuff in KDE needs to be patched/worked-around to work well in the Aqua environment. The main KDE-Darwin developer, Benjamin Reed, has chosen to focus on keeping KDE updated in the Fink/X11 environment. It's simply a matter of time: there are only 24 hours in the day, he has a full-time job, he does a lot of other things for Fink since he is one of the project leads, and (this is significant) he was really the only person doing work on making KDE native, on an ongoing basis, to begin with. Some people have helped out here and there, but there's not exactly a large pool of developers pitching in. In fact, I believe he's said more that once on his blog that if anyone wants to step up and take over leadership of the KDE-Aqua project, he'd gladly step aside.
Anyone interested?
*hears only the sound of crickets chirping*
Hmmm, thought so.
Inkscape.app runs fine on my Mac (10.4.2), but it looked ugly. I decided to do what the developers of GimpShop and load an Aqua-style skin, Glossy P http://art.gnome.org/themes/gtk2/571. It does a fair approximation of the Aqua appearance, and believe it or not, it helps: makes the contrast between Aqua and X11 less jarring.
/Contents/Resources, create a directory called /share/themes/Default, and put Glossy P (which untars to a folder called Gtk-2.0) in there.
To load Glossy P, open the app bundle, navigate to
It would be nice to have a native Aqua version, but porting GTK isn't trivial. There has been a long-running effort to port GTK 1, which looks awful (hardly different from an Aqua-themed X11) and barely runs, and a more recent effort to port GTK 2, which is still in the early phases. Given this situation, I'll gladly use an X11 version in an app bundle. What a good idea! And, Inkscape 0.42 runs much better than previous versions.
I first tried NeoOffice/J a year or so ago. It was huge, took forever to boot, and ran dog slow. I wondered: why on earth would anyone rewrite a beast like OO.org in Java?? Didn't realize the Java part was a lightweight wrapper around the OO core.
Anyway, I went back to using OO.org X11. It's huge, and runs pretty slow, and looks like crap, but it works. The Start OO.org AppleScript launcher, which provides an icon to start OO.org, and also provides support for OO filetypes with icons, is a nice supplement.
After seeing this today, I tried the current version of NeoOffice/J. I didn't realize it was this far along. A real Mac menubar! Aqua print dialogs! Starts up reasonably fast! No X11 required! Compared to OO.org X11, this is already a native port. Yes, it has a little further to go, but my gosh, what a good job for a project with two or three developers.
Great job, guys!
I posted a long review of Scribus 1.1.4/1.1.5 here. I publish books for a living. Word, InDesign, Corel Draw, and Photopaint are part of my daily workflow. Scribus performed quite capably with some rough spots in a task that I usually handle with InDesign.