OpenStep is not an X11 toolkit, although GNUstep has a backend for X11.
Also, OpenStep doesn't have "bindings" -- OpenStep is built in and for Objective-C explicitly. Other languages can connect up to OpenStep via the Objective-C runtime, but it's fundamentally an Objective-C framework.
Finally, GNUstep is LGPL'd, not GPL'd. Big difference.:)
Otherwise, right on! OpenStep and GNUstep are the way to go.
You'd have to code in Objective-C, but that's not exactly a detriment. The designers of the Standard C++ Library could learn a thing or two from the OpenStep FoundationKit, and the designers of the Java AWT probably should've followed the Netscape IFC team's lead and just reimplemented the OpenStep ApplicationKit.
I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.
From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).
One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.
I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.
I would also be cool if apple or moto or ibm would pay to get gcc up and optimized on linux-powerpc specifically.
Apple is using egcs to build Mac OS X. Mac OS X Server was built with gcc 2.7.2.1 (who comes up with these version numbers?). I bet they're putting a lot of optimization work into it.
I bet their changes would port to Linux pretty easily.
Hackers will always take care of their own machines, but the masses will let someone else do the dirty work.
This illustrates a fundamental misunderstanding of how real users think. Users don't want "someone else to do the dirty work" of administering a computer -- they want computers that don't require any "dirty work" to administer!
The only reason they might say they want someone else to do it is because they've been convinced by DOS, Windows and Unix that it's not possible to have a computer without "dirty work."
(MacOS isn't perfect in this respect either. It's a lot closer to the ideal than any other system, though.)
You can get the same effect with NetBooted Macs. The administrator can set up applications, user privileges, etc., and lock everything down.
And as an added bonus, the user experience doesn't absolutely suck, so the workstation gets out of the user's way and lets them get their work done. This cannot be stressed enough: "Not crashy" doesn't automatically mean "easy to use!"
Does GIMP support an arbitrary number of channels yet? At the very least, it absolutely needs CMYK support. Support for display correction using (and embedding of) ICC profiles is another feature that would be really useful.
(For people who are curious, Chapter 13 of Foley & van Dam talks about color spaces.)
Re:in answer to the original questions...
on
Is X The Future?
·
· Score: 1
The trap you point out though is so easy to fall into that you fall in yourself. "Mechanism not Policy" isn't a fault of X, it was the feature that made it possible to become a standard!
X? A standard? What planet do you live on?
There are two standard graphical interfaces in the personal computer industry. The Macintosh interface is the one every other interface tries to be, and the Windows interface is the one most people use. X isn't even on the radar.
(And yes I know there are people who will insist that it isn't X that's the interface, it's KDE, or GNOME, or CDE, or some other crap. They can bite me. X refers to the whole ball of wax now, no way around it, no matter how much semantic BS you try to invoke.)
Re:in answer to the original questions...
on
Is X The Future?
·
· Score: 1
The only reason I suggest Display GhostScript is because it's most of the way done (from what I gather it still needs a good amount of display-oriented functionality work and a lot of optimization, but at least the rendering code is complete and works well) and it implements the PostScript imaging model. I think the latter is the important part.
Most of the time in OpenStep application development you don't need to write real PostScript code. If you do need to do drawing, you call functions like PSmoveto() and PSlineto() that send messages to the DPS server. You can also write "pswraps" -- PostScript procedures that get compiled into a chunk of code that you can call from C, which when invoked send the whole chunk to the server at once. (This can improve performance because you reduce the number of round trips/context switches required.)
In Mac OS X, because it uses Quartz rather than Display PostScript, the PSxxx() routines should still be usable but pswraps are going away.
Incidentally, one of the reasons Apple is dumping DPS (besides Adobe's outrageous licensing fees) is to get better performance. They're doing this by making most of Quartz a client-side library that draws directly to the screen (or the backing store). They say they're leaving hooks in so remote display can be added back later; of course, some people are freaking out about that, but IMHO Apple has their head on straight. Optimize the common case, make the uncommon case possible.
Re:in answer to the original questions...
on
Is X The Future?
·
· Score: 1
Within the next year, there will be a new, large base of non-X Unix applications for Mac OS X. Everybody that writes Mac software will be porting their code to Carbon (think of it as the Mac Toolbox, take II). A lot of people will also write write new applications with OpenStep--er, Yellow Box--er, "Cocoa".
GNUstep is almost to the point where serious OpenStep porting and debugging can take place. (The text system is in flux right now; when that's over, I think it'll be ready.) This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; Macintosh software developers are the best in the industry when it comes to building usable, consistent interfaces to high-quality end-user applications. (Hey, I'm allowed a little egotism, aren't I?)
What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is. GNUstep runs on X right now, sure, but it could also be made to run on a sane display subsystem without affecting application-level code. So the situation isn't quite as hopeless as it seems.
My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.
PDF ("the acrobat format") is effectively declarative PostScript. It allows for totally precise, resolution-independent page layout -- an absolute necessity for real printing. It's megayears ahead of HTML in that respect.
Chuck Wiltgen, Apple's QuickTime evangelist, has had a very consistent message for people on the QuickTime list who want to see QuickTime on their favorite platform: "Get your platform vendor to license QuickTime." (That's paraphrased, not a direct quote.)
A representative from Sorensen also said on the QuickTime list that they're only interested in having their CODEC running on QuickTime. If your platform has QuickTime, they'll see if there's a business case for porting.
The situation with Apple and QuickTime is almost exactly equivalent to the situation with Sun and Java: Apple is doing the work on the two major client platforms -- Macintosh and Windows -- and leaving it up to licensees to do the work on everything else. (I'm pretty sure SGI is or at least was a QuickTime licensee.) The only differences are that Sun is willing to license a Linux port of JDK to BlackDown for cheap or free, and Sun provides source code to the JDK to whoever wants it without distribution rights. (If I'm wrong about the Java licensing issues, please correct me.)
So talk to RedHat, or Caldera, or VA Research, or one of the other monied Linux companies, and convince them to do a licensed port of QuickTime. I'm sure Apple and many application vendors would like to see it; they just don't see any business case for doing it themselves considering how small a percentage of the client and content creation market Linux makes up.
If you want more affordable housing, try the Chicago area. I live & work as a software engineer in the northwest suburbs, and I can afford a relatively new and rather large two bedroom, two bath apartment by myself with little trouble.
There's a lot to do in the city (see Metromix for some good listings), there's good public transportation if your destination is the city (within the burbs public transportation sucks just like it does everywhere else), and there's a large and diverse geek culture. After all, it is the third-largest city in the United States. And you can get the best pizza and hot dogs and polish saussage in the world here.
About the only downside is the weather, because we have a real winter here. And the winter isn't all that bad; just learn how to drive in snow and you'll be fine. It's not like Michigan or some of the other northern states where snowfall is measured in feet...
If anyone wants to work in the Chicago area writing Mac & Windows software in C++, drop me a note. I may be able to hook you up.;)
There were other mainstream platforms that used a client-server window system. To name a few, in chronological order:
Carnegie Mellon University's Andrew "wm" system, by Gosling (among others) and described in some detail in "Programming as if People Mattered" by Nathaniel Borenestein
Sun's NeWS, based on an object-oriented PostScript system and developed by Gosling (among others, again)
NEXTSTEP's Display PostScript system
I'm sure my list is not complete. I bet Sun's SunView system (which NeWS replaced) was also client-server, for example, and I bet whatever Apollo used prior to X was also client-server (since DomainOS was actually a network operating system).
Also, Mac OS X Server uses Display PostScript right now. Mac OS X uses "Quartz", a display system that has an imaging model affine-equivalent with Display PostScript's but isn't currently implemented in a client-server fashion.
(Though it's been a stated goal that it should be easy to make it client-server, either by third parties or in subsequent releases by Apple. My bet is that Apple will do it themselves in v2.0 or something, since it's something a bunch of their engineers will probably want...)
Actually, on the Darwin list people have talked about booting Mac OS X Server with a Darwin kernel.
Darwin is Open Source. If this is a kernel issue, anyone can fix it and submit the changes, and make a binary kernel release available until Apple releases an official patch.
There are two things in QuickTime that matter: The API, and the file format.
The QuickTime-compatible library at http://heroine.tampa.fl.us/quicktime/ just gives you access to the file format and the ability to do some simple encoding and decoding. I'm aware of no efforts to replicate the actual QuickTime API on Linux.
The interaction between the programming model and the extremely flexible file format is where a lot of QuickTime's power comes from.
Also, the author should really stop using "QuickTime" in the name of his library. It's trademarked by Apple, after all...
The Lisa interface - the direct parent of the Macintosh interface - wasn't actually all that much like Smalltalk's interface.
Go read Inventing the Lisa Interface for more on how the Lisa (and therefore the Macintosh) came about. Read the Macintosh Human Interface Guidelines and Tog on Interface to learn more about why the Mac interface is the way it is.
This is not to say the Macintosh interface has no deficiencies; some of them -- though less than you imply -- are due to the original Mac's anemic hardware specs when compared to the Lisa's. But as someone who's used MacOS, NEXTSTEP, various X-based systems, BeOS, the Lisa, and Windows rather extensively it's obvious that it's the best personal computer interface yet.
(Also, just so you know, you can get a multi-button mouse for the Macintosh. I know people who swear by their 4-button mice. You can also get a command line environment for the Macintosh with pipes and redirection; it's just not part of what's shipped to end users because end users generally don't wnat or need that functionality.)
Why do I need my Word Processor integrated with my 3D modeller? They are two different, orthogonal applications, with two different interfaces.
Wrong. They're two different, orthogonal applications, which will have all of their most basic interface elements in common. The point isn't to build a single binary, the point is that applications from different developers (who may not even know about the other app) work well together.
For instance, say the preferences dialog in the word processor and the preferences dialog in the 3D modeler both have a text field you can type something into, a couple of radio buttons, and a couple of checkboxes. The look and behavior of these controls need to be identical between the majority of available applications before you can even begin to talk about whether your operating system is easy to use.
Now compare a drawing program and a modeling package. These have more in common. If a single click selects a shape in the drawing program, a single click should select a model. If dragging an object's handle in the modeling application resizes it there's no way in hell that doing so should move the selection in the drawing app.
"Ease of use" does not simply mean "easy for newbies to learn." It means that a system can be learned easily, and that knowledge about how one application behaves transfers to every other application. This leads to increased efficiency for even extremely expert users because such knowledge transfer reduces the cognitive load involved in using a system.
And why does my spreadsheet have to be integrated into the GUI? Shouldn't I be able to choose the GUI that works for me, and use whatever spreadsheet I like best? To me, ease-of-use is defined by my ability to customize my environment to fit me, not to change my desires and preferences to fit my environment.
You're not talking about "ease of use", you're talking about "ease of customization." Look at how customizable the average system running X-Windows is -- ooh, you can change your window borders!!! Yeah, you've really "changed your GUI" there... Now look at a Macintosh running Kaleidoscope or an Appearance Manager theme. Notice how all of the buttons and all of the scrollbars look the same, from application to application? I think that's what most people really want, not just some decoration around the edges.
KDE or GNOME may allow for true wide-scale cross-application consistency eventually, but only if the rest of the X-Windows software base is buried, and only if just one of them "wins."
FilterTop does this on the Macintosh. I've heard there was also a tool for NEXTSTEP that allowed you to graphically build pipelines and put interfaces on them. NEXTSTEP also supports "Terminal Services", where you can add command lines to the Services menu (present in all applications) and apply arbitrary command lines to whatever you have selected.
Additionally, AppleScript on the Macintosh and COM on Windows allow you to automate a lot of things inside of other applications, both in "do this one task lots of times" and "put an easy or automated front end on this complicated series of actions" forms. Find someone who uses AppleScript, FileMaker Pro, and QuarkXPress to do automated catalog layout to show you what I mean...
It seems like CORBA is going to provide this same sort of functionality in Linux applications. I look forward to it, especially if there's some integration with GUILE; after all, "Lisp is the only computer language that's beautiful." (Well, for me, there's also Smalltalk, but that's better for building full-fledged applications than for scripting...)
Yes, that's fine if I wanted to know how a quicktime file is structured, but it has no technical details or algorithms to reproduce the codecs. With this information, I could build a mean-ass QT file parser, but I wouldn't know how to decode the infomation contained in it. Those codecs are closly guarded corporate secrets. I'm sure that Qualcomm, Apple, Sorenson and other will let you look at them, if you gave them a few million bucks..:-)
You can use the information in that and other publicly-available documents to start reimplementing the QuickTime API. Once you have the right portions of the QuickTime API reimplemented you can call Sorenson and Qualcomm and everyone else and say "Hey, wanna port your CODEC to Linux? It'll be simple if you already have it working with QuickTime!"
This does mean that a lot of CODECs would probably be distributed as closed-source shared libraries, but to me that's not a big deal at all. And all but the most unreasonable Open Source purists will prefer such a situation to having no advanced CODECs.
Really, I don't see why Sorenson or Qualcomm or Intel or anyone else would object to porting their CODEC if it wasn't too much work. (Particularly if Linux starts to gain significant desktop share.) But right now, there's no single solid multimedia target at all for Linux, so telling Sorenson that you want their CODEC on Linux would likely just garner you a confused look.
(Incidentally, this same issue applied to widget sets and window managers is likely holding up a lot of commercial application development. Commercial developers with Mac and Windows products don't want to decide which of { Qt, GTK, Athena, Motif, GNUstep,... } to use for their product. We want a single API for building applications with graphical human interfaces, and we want all of those applications to look and behave the same. In other words, we want a solid target.)
QuickTime is the API to use for multimedia, in the Mac & Windows world. It's a decent API. It's also published. Not just the data formats, but the high-level calls that developers use in their products, and the low-level interface that allows developers to build new codecs and effects and so on.
To get more codecs and multimedia software, Linux has to support this API. It's a much stronger argument to go to Intel, Sorenson, or any other codec developer and say "if your QuickTime codec compiles on MacOS/Windows it'll only need some tweaking to run on Linux" than it is to whine at them about how they need to support your favorite operating system. This goes double for application developers.
One other suggestion: Follow GNUstep's lead and separate the front end from the back end of the multimedia system. It'd be cool for game developers to be able to use LinuxTime in their SVGALib game, or for application developers porting from OPENSTEP & Mac OS X to use it within GNUstep on Display GhostScript, or...
Most of the exceptions that drop me into the debugger on the Mac would probably not have been helped by guard pages - the exception happens in the system code after you feed it some stupid parameter value... sure, it is usually a memory access exception but it isn't in your code - so who catches it and who cleans up???
Buy yourself a copy of Spotlight from Onyx Technologies. It's like Purify for the Mac -- it provides protected memory and system call parameter validation and memory leak detection for code run under it. It works incredibly well for a product that's still in development, and compared to equivalent utilities on Windows and Unix (Purify) it's really cheap.
If these memory bugs are in other peoples' software, email or call or write them and tell them to run their code through Spotlight. It can really help you clean up your code and make it rock solid.
This is in response to the other posters in this subthread...
The big benefit of an integrated development environment like CodeWarrior is that it maintains and manages your projects for you, not because of any sort of interface construction. (IDEs often include interface-construction tools, but they're not the reason for IDEs' existence.)
When develoing software with CodeWarrior, I don't have to remember the different -W flags to turn warnings off -- I go to the "C/C++ Warnings" panel in the Project Settings and click on checkboxes. When adding a source file to a project, I can just click on the targets I want it added to. To check in a modified file, I just select it in the project window and choose "Check In" from a menu. I never have to touch or even think about a makefile, because the IDE does dependency tracking for me.
In other words, it lets me focus almost completely on writing code.
And for the vast majority of Macintosh projects, the IDE is flexible enough that you don't have to worry about not having makefiles or anything like that.
The only problem with it is that the project file format's not open. But to me, it's not a big problem...
Also, at least CodeWarrior is not a monolithic tool. There's the project manager -- the IDE proper -- which hosts compilers, preference panels, linkers, etc. as plug-ins, and also has an excellent syntax-aware text editor and class browser. Then there's Constructor, the interface construction tool, and ResEdit or Resorceror for editing resources. So while it's a complete environment, and some pieces of it do run in the same memory space, it's not all that huge or monolithic.
What's the benefit of using PNG over TIFF, other than that most browsers (for some reason) don't support TIFF?
To me, it seems that TIFF is a mature format with all the options and extensibility that anyone could want. About the only thing I can think of off the top of my head that's missing is a standard tag for LZ77 compression like that used in PNG. With enough lobbying and/or agreement among developers, that could be fixed too.
(Note: I realize PNG's advantages over GIF, and over some other image formats. It's TIFF I'm particularly interested in.)
Slashdot Mirror
GNUstep is an Open Source (LGPL) implementation of OpenStep.
Also, OpenStep's Objective-C programming interface is really elegant, and it performs pretty well.
And since Objective-C is a strict superset of ANSI C, interfacing with C (and C++ code) and wrapping an interface around other code is really easy.
Also, OpenStep doesn't have "bindings" -- OpenStep is built in and for Objective-C explicitly. Other languages can connect up to OpenStep via the Objective-C runtime, but it's fundamentally an Objective-C framework.
Finally, GNUstep is LGPL'd, not GPL'd. Big difference. :)
Otherwise, right on! OpenStep and GNUstep are the way to go.
I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.
From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).
One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.
I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.
THE X WINDOW SYSTEM IS NOT UNIX.
Mac OS X Server does support remote windowing through a Display PostScript and Mach messaging mechanism. It does not (thank God!) use X-Windows.
Apple is using egcs to build Mac OS X. Mac OS X Server was built with gcc 2.7.2.1 (who comes up with these version numbers?). I bet they're putting a lot of optimization work into it.
I bet their changes would port to Linux pretty easily.
This illustrates a fundamental misunderstanding of how real users think. Users don't want "someone else to do the dirty work" of administering a computer -- they want computers that don't require any "dirty work" to administer!
The only reason they might say they want someone else to do it is because they've been convinced by DOS, Windows and Unix that it's not possible to have a computer without "dirty work."
(MacOS isn't perfect in this respect either. It's a lot closer to the ideal than any other system, though.)
And as an added bonus, the user experience doesn't absolutely suck, so the workstation gets out of the user's way and lets them get their work done. This cannot be stressed enough: "Not crashy" doesn't automatically mean "easy to use!"
(For people who are curious, Chapter 13 of Foley & van Dam talks about color spaces.)
X? A standard? What planet do you live on?
There are two standard graphical interfaces in the personal computer industry. The Macintosh interface is the one every other interface tries to be, and the Windows interface is the one most people use. X isn't even on the radar.
(And yes I know there are people who will insist that it isn't X that's the interface, it's KDE, or GNOME, or CDE, or some other crap. They can bite me. X refers to the whole ball of wax now, no way around it, no matter how much semantic BS you try to invoke.)
Most of the time in OpenStep application development you don't need to write real PostScript code. If you do need to do drawing, you call functions like PSmoveto() and PSlineto() that send messages to the DPS server. You can also write "pswraps" -- PostScript procedures that get compiled into a chunk of code that you can call from C, which when invoked send the whole chunk to the server at once. (This can improve performance because you reduce the number of round trips/context switches required.)
In Mac OS X, because it uses Quartz rather than Display PostScript, the PSxxx() routines should still be usable but pswraps are going away.
Incidentally, one of the reasons Apple is dumping DPS (besides Adobe's outrageous licensing fees) is to get better performance. They're doing this by making most of Quartz a client-side library that draws directly to the screen (or the backing store). They say they're leaving hooks in so remote display can be added back later; of course, some people are freaking out about that, but IMHO Apple has their head on straight. Optimize the common case, make the uncommon case possible.
GNUstep is almost to the point where serious OpenStep porting and debugging can take place. (The text system is in flux right now; when that's over, I think it'll be ready.) This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; Macintosh software developers are the best in the industry when it comes to building usable, consistent interfaces to high-quality end-user applications. (Hey, I'm allowed a little egotism, aren't I?)
What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is. GNUstep runs on X right now, sure, but it could also be made to run on a sane display subsystem without affecting application-level code. So the situation isn't quite as hopeless as it seems.
My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.
PDF ("the acrobat format") is effectively declarative PostScript. It allows for totally precise, resolution-independent page layout -- an absolute necessity for real printing. It's megayears ahead of HTML in that respect.
A representative from Sorensen also said on the QuickTime list that they're only interested in having their CODEC running on QuickTime. If your platform has QuickTime, they'll see if there's a business case for porting.
The situation with Apple and QuickTime is almost exactly equivalent to the situation with Sun and Java: Apple is doing the work on the two major client platforms -- Macintosh and Windows -- and leaving it up to licensees to do the work on everything else. (I'm pretty sure SGI is or at least was a QuickTime licensee.) The only differences are that Sun is willing to license a Linux port of JDK to BlackDown for cheap or free, and Sun provides source code to the JDK to whoever wants it without distribution rights. (If I'm wrong about the Java licensing issues, please correct me.)
So talk to RedHat, or Caldera, or VA Research, or one of the other monied Linux companies, and convince them to do a licensed port of QuickTime. I'm sure Apple and many application vendors would like to see it; they just don't see any business case for doing it themselves considering how small a percentage of the client and content creation market Linux makes up.
There's a lot to do in the city (see Metromix for some good listings), there's good public transportation if your destination is the city (within the burbs public transportation sucks just like it does everywhere else), and there's a large and diverse geek culture. After all, it is the third-largest city in the United States. And you can get the best pizza and hot dogs and polish saussage in the world here.
About the only downside is the weather, because we have a real winter here. And the winter isn't all that bad; just learn how to drive in snow and you'll be fine. It's not like Michigan or some of the other northern states where snowfall is measured in feet...
If anyone wants to work in the Chicago area writing Mac & Windows software in C++, drop me a note. I may be able to hook you up. ;)
There were other mainstream platforms that used a client-server window system. To name a few, in chronological order:
I'm sure my list is not complete. I bet Sun's SunView system (which NeWS replaced) was also client-server, for example, and I bet whatever Apollo used prior to X was also client-server (since DomainOS was actually a network operating system).
Also, Mac OS X Server uses Display PostScript right now. Mac OS X uses "Quartz", a display system that has an imaging model affine-equivalent with Display PostScript's but isn't currently implemented in a client-server fashion.
(Though it's been a stated goal that it should be easy to make it client-server, either by third parties or in subsequent releases by Apple. My bet is that Apple will do it themselves in v2.0 or something, since it's something a bunch of their engineers will probably want...)
Darwin is Open Source. If this is a kernel issue, anyone can fix it and submit the changes, and make a binary kernel release available until Apple releases an official patch.
The QuickTime-compatible library at http://heroine.tampa.fl.us/quicktime/ just gives you access to the file format and the ability to do some simple encoding and decoding. I'm aware of no efforts to replicate the actual QuickTime API on Linux.
The interaction between the programming model and the extremely flexible file format is where a lot of QuickTime's power comes from.
Also, the author should really stop using "QuickTime" in the name of his library. It's trademarked by Apple, after all...
Most of what you say is false.
The Lisa interface - the direct parent of the Macintosh interface - wasn't actually all that much like Smalltalk's interface.
Go read Inventing the Lisa Interface for more on how the Lisa (and therefore the Macintosh) came about. Read the Macintosh Human Interface Guidelines and Tog on Interface to learn more about why the Mac interface is the way it is.
This is not to say the Macintosh interface has no deficiencies; some of them -- though less than you imply -- are due to the original Mac's anemic hardware specs when compared to the Lisa's. But as someone who's used MacOS, NEXTSTEP, various X-based systems, BeOS, the Lisa, and Windows rather extensively it's obvious that it's the best personal computer interface yet.
(Also, just so you know, you can get a multi-button mouse for the Macintosh. I know people who swear by their 4-button mice. You can also get a command line environment for the Macintosh with pipes and redirection; it's just not part of what's shipped to end users because end users generally don't wnat or need that functionality.)
Wrong. They're two different, orthogonal applications, which will have all of their most basic interface elements in common. The point isn't to build a single binary, the point is that applications from different developers (who may not even know about the other app) work well together.
For instance, say the preferences dialog in the word processor and the preferences dialog in the 3D modeler both have a text field you can type something into, a couple of radio buttons, and a couple of checkboxes. The look and behavior of these controls need to be identical between the majority of available applications before you can even begin to talk about whether your operating system is easy to use.
Now compare a drawing program and a modeling package. These have more in common. If a single click selects a shape in the drawing program, a single click should select a model. If dragging an object's handle in the modeling application resizes it there's no way in hell that doing so should move the selection in the drawing app.
"Ease of use" does not simply mean "easy for newbies to learn." It means that a system can be learned easily, and that knowledge about how one application behaves transfers to every other application. This leads to increased efficiency for even extremely expert users because such knowledge transfer reduces the cognitive load involved in using a system.
You're not talking about "ease of use", you're talking about "ease of customization." Look at how customizable the average system running X-Windows is -- ooh, you can change your window borders!!! Yeah, you've really "changed your GUI" there... Now look at a Macintosh running Kaleidoscope or an Appearance Manager theme. Notice how all of the buttons and all of the scrollbars look the same, from application to application? I think that's what most people really want, not just some decoration around the edges.
KDE or GNOME may allow for true wide-scale cross-application consistency eventually, but only if the rest of the X-Windows software base is buried, and only if just one of them "wins."
Additionally, AppleScript on the Macintosh and COM on Windows allow you to automate a lot of things inside of other applications, both in "do this one task lots of times" and "put an easy or automated front end on this complicated series of actions" forms. Find someone who uses AppleScript, FileMaker Pro, and QuarkXPress to do automated catalog layout to show you what I mean...
It seems like CORBA is going to provide this same sort of functionality in Linux applications. I look forward to it, especially if there's some integration with GUILE; after all, "Lisp is the only computer language that's beautiful." (Well, for me, there's also Smalltalk, but that's better for building full-fledged applications than for scripting...)
You can use the information in that and other publicly-available documents to start reimplementing the QuickTime API. Once you have the right portions of the QuickTime API reimplemented you can call Sorenson and Qualcomm and everyone else and say "Hey, wanna port your CODEC to Linux? It'll be simple if you already have it working with QuickTime!"
This does mean that a lot of CODECs would probably be distributed as closed-source shared libraries, but to me that's not a big deal at all. And all but the most unreasonable Open Source purists will prefer such a situation to having no advanced CODECs.
Really, I don't see why Sorenson or Qualcomm or Intel or anyone else would object to porting their CODEC if it wasn't too much work. (Particularly if Linux starts to gain significant desktop share.) But right now, there's no single solid multimedia target at all for Linux, so telling Sorenson that you want their CODEC on Linux would likely just garner you a confused look.
(Incidentally, this same issue applied to widget sets and window managers is likely holding up a lot of commercial application development. Commercial developers with Mac and Windows products don't want to decide which of { Qt, GTK, Athena, Motif, GNUstep, ... } to use for their product. We want a single API for building applications with graphical human interfaces, and we want all of those applications to look and behave the same. In other words, we want a solid target.)
To get more codecs and multimedia software, Linux has to support this API. It's a much stronger argument to go to Intel, Sorenson, or any other codec developer and say "if your QuickTime codec compiles on MacOS/Windows it'll only need some tweaking to run on Linux" than it is to whine at them about how they need to support your favorite operating system. This goes double for application developers.
One other suggestion: Follow GNUstep's lead and separate the front end from the back end of the multimedia system. It'd be cool for game developers to be able to use LinuxTime in their SVGALib game, or for application developers porting from OPENSTEP & Mac OS X to use it within GNUstep on Display GhostScript, or...
If these memory bugs are in other peoples' software, email or call or write them and tell them to run their code through Spotlight. It can really help you clean up your code and make it rock solid.
The big benefit of an integrated development environment like CodeWarrior is that it maintains and manages your projects for you, not because of any sort of interface construction. (IDEs often include interface-construction tools, but they're not the reason for IDEs' existence.)
When develoing software with CodeWarrior, I don't have to remember the different -W flags to turn warnings off -- I go to the "C/C++ Warnings" panel in the Project Settings and click on checkboxes. When adding a source file to a project, I can just click on the targets I want it added to. To check in a modified file, I just select it in the project window and choose "Check In" from a menu. I never have to touch or even think about a makefile, because the IDE does dependency tracking for me.
In other words, it lets me focus almost completely on writing code.
And for the vast majority of Macintosh projects, the IDE is flexible enough that you don't have to worry about not having makefiles or anything like that.
The only problem with it is that the project file format's not open. But to me, it's not a big problem...
Also, at least CodeWarrior is not a monolithic tool. There's the project manager -- the IDE proper -- which hosts compilers, preference panels, linkers, etc. as plug-ins, and also has an excellent syntax-aware text editor and class browser. Then there's Constructor, the interface construction tool, and ResEdit or Resorceror for editing resources. So while it's a complete environment, and some pieces of it do run in the same memory space, it's not all that huge or monolithic.
To me, it seems that TIFF is a mature format with all the options and extensibility that anyone could want. About the only thing I can think of off the top of my head that's missing is a standard tag for LZ77 compression like that used in PNG. With enough lobbying and/or agreement among developers, that could be fixed too.
(Note: I realize PNG's advantages over GIF, and over some other image formats. It's TIFF I'm particularly interested in.)