lusk@hilbert.cs.unc.edu (John Lusk) (01/28/91)
I hesitate to ask this. Given a choice between developing for a Macintosh and developing for X windows, why would anybody choose X? I know nothing about the Mac toolbox, but I've been reading the O'Reilly manuals on Xlib, Xt and Xview. Seems like the Mac toolbox couldn't possibly be as complicated as X. I've only got one plausible explanation: hardware platforms that run X can be much more powerful than Macs, so if you want to develop a resource-intensive application, you should gravitate toward X. I know this is a horribly undefined question, so here's some background: I'm about to start a major project, I have my choice of platforms (simplistically put), and I don't know a whole lot about programming for either platform. John.
de5@ornl.gov (Dave Sill) (01/29/91)
In article <930@borg.cs.unc.edu>, lusk@hilbert.cs.unc.edu (John Lusk) writes: >I hesitate to ask this. Given a choice between developing for a >Macintosh and developing for X windows, why would anybody choose X? Because they don't want to be tied to single vendor. Or perhaps they realize that X-based systems are the present/future of desktop computing. >I know nothing about the Mac toolbox, but I've been reading the >O'Reilly manuals on Xlib, Xt and Xview. Seems like the Mac toolbox >couldn't possibly be as complicated as X. You might reserve judgement until you've looked at the Mac. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/31/91)
As quoted from <1991Jan28.173654.10133@cs.utk.edu> by de5@ornl.gov (Dave Sill): +--------------- | In article <930@borg.cs.unc.edu>, lusk@hilbert.cs.unc.edu (John Lusk) writes: | >I hesitate to ask this. Given a choice between developing for a | >Macintosh and developing for X windows, why would anybody choose X? | | Because they don't want to be tied to single vendor. Or perhaps they | realize that X-based systems are the present/future of desktop | computing. +--------------- There is at least one Mac-emulator for X and other window systems, not to mention critters like the Amax for the Amiga. In general, however, you are correct: X is more portable. BUT: you didn't really answer the question that was asked, which involved why a more complex system would be chosen over a less-complex one. Here's a stab at a more relevant answer. The Mac has a user interface. X is *not* a user interface, however; it is a toolkit for *building* user interfaces. (Consider Open Look vs. Motif, both of which are built on X.) The Mac provides *some* low-level mechanisms for building your own alternative user interface, but not a full set; anything you build will be decidedly MacOS-like because the most primitive operations available on the Mac are the low-level MacOS interface ones. Thus, it takes more work to write for *raw* X than for MacOS, because you need to build the user interface. It takes somewhat less work to build for specific GUIs built on X; both Motif and Open Look provide toolkits, similar to the MacOS Toolbox. But then you're tied to that GUI; something built for raw X should run on *any* X, including the ones underlying Motif and Open Look. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
amanda@visix.com (Amanda Walker) (02/03/91)
In article <1991PMSat.02.14347@dircon.co.uk> uad1077@dircon.co.uk (Ian Kemmish) writes: >Also, much effort is wasted on >fighting the toolkit (this may be implementation rather than design bugs >in the version of Motif I was using, but it's still relevant to the >choice of whether to use it in future!). The common problem I've seen with most X toolkits is that they contain a lot of preconceptions about How Every Application Shall Be Structured, and tend to have very narrow APIs. The Mac, whatever faults it may have, has a very broad and general API. There is, of course, no reason that a broad API can't be built on top of X--it's just that there are very few of them around, and even fewer are for sale to the public. Disclaimer: We have built such a toolkit, and we will be selling it this summer. I am therefore biased on this issue. -- Amanda Walker amanda@visix.com Toolkit Team Leader ...!uunet!visix!amanda Visix Software Inc. +1 800 832 8668 -- "If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him march to the music he hears, be it however measured or far away." --Henry David Thoreau
GHGAQZ4@cc1.kuleuven.ac.be (02/21/91)
>>I hesitate to ask this. Given a choice between developing for a >>Macintosh and developing for X windows, why would anybody choose X? > >Because they don't want to be tied to single vendor. Or perhaps they >realize that X-based systems are the present/future of desktop >computing. > >>I know nothing about the Mac toolbox, but I've been reading the >>O'Reilly manuals on Xlib, Xt and Xview. Seems like the Mac toolbox >>couldn't possibly be as complicated as X. > >You might reserve judgement until you've looked at the Mac. I find both the Mac toolbox and X toolbox rather complicated. I've programmed in the X toolbox and I know people who program for the Macintosh. I find it really strange that you need so much code simply to open a window. The X toolbox is better, but still I prefer the Amiga way of doing things (I mean in AmigaDOS 2.0 the new version of the operating system). There is now a toolbox that is very easy to use. A C program to open a window with a button could be written in only about 12 lines, with on each line only one statement or declaration. And you don't need external files like in X. And this program would automatically account for window sizing, closing of the window, refreshing of the window and it would include a small event loop for the button. This is of course my personal opinion. Jorrit Tyberghein