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.
fgreco@govt.shearson.COM (Frank Greco) (01/29/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. On one hand I agree with you. X is overly complex. That's what happens when 1000 pgmrs work on the same project. I thought it was a well known tenet that the best software is written by a small set of programmers. However on the other hand, unlike the Macintosh *proprietary* approach, X was designed to be policy-free and only specified the mechanisms. Also, portability among different machines, operating systems and even networking protocols was a design choice that the Mac ignores (probably more of a business decision than a technical one). If you specify policy in the window system, you probably can get away with less code in your toolkit and less complexity, but you lose the portability that allows a client pgm that was developed on a Sun to be executed on a Cray and connected to an X server on, say a Macintosh. Its a tradeoff. I'm not a big fan of the complexity of X but lets be fair here. Besides I'd say comparing the Mac toolbox to X is a bit unrealistic. Let's see how easy the new Mac System 7.0 API is first. Frank G.
mrose@cheetah.ca.psi.COM (Marshall Rose) (01/29/91)
Well, I'm neither in the X nor Mac mainstream, but I've done a bit of programming in both. In my perspective, the key advantage of X is that it allows you to decouple the display engine from the compute engine. It turns out that this allows you to get a lot more leverage out of your software, just like putting up an NFS server let's you ge a lot more leverage out of your disk investment. Also in my perspective, the key advantage of the Mac windowing system is that the look-and-feel is superb. X is so-called policy-free, and whilst this is an appropriate design goal if you are trying to provide windowing building blocks, it makes it a lot harder when you want to put together a finished product. Of course, there are other advantages to both. In terms of programming complexity, I find them about equally hard, although I've programmed UNIX a lot longer than I've programmed a Mac. Neither is simple. Now, finally in my opinion, the best of all worlds would be to get someone to right a Mac emulator or something for X. However, given the legal posturing of the industry these days, I'm sure that this would result in many billable hours being racked up. /mtr
doug@genmri.UUCP (Doug Becker) (01/29/91)
I hesitate to ask this. Given a choice between developing for a
Macintosh and developing for X windows, why would anybody choose X?
Without having near enough time to answer you, here are some basic
observations:
1. A well-written X program will run (or at least display) on many
different vendors' hardware, *including the Mac*.
2. I would dispute your claim that X Toolkits are any more involved
than the Mac's. As counterevidence to your "O'Reilly" claim, I
submit Volumes I-V of Inside Macintosh, and countless hundreds of
obscure Technical Notes. (I would also point to the unrivaled
clarity of the X documentation and the availability of the X source
code in its entirety. Note also that the essential documentation
for much of X is free, the notable exception being the Asente &
Swick Toolkit book. [Incidentally, will the *roff source for Asente
& Swick be included free in R5, the way Scheifler & Gettys et al.
is now?])
3. As I see it, a long-term, successful venture into the Mac world
depends largely on your being classified by Apple as an "Apple
Certified Developer" (i.e., a "member of the club"). I find this
sort of "tell us how many more machines you're going to sell for
us" policy stifling and obnoxious.
4. Assuming 1., 2., and 3. above are false, I find it difficult to
relate to the theory that "if it's simpler to develop for it,
that's the one that should be built."
X is complicated, sure, but so is anything that gives you any kind of real
programming power (the Mac Toolbox included). Believe me, you'll spend as
much time learning about the intricacies of different vendors' approaches
to the wasted 8 bits of 32-bit QuickDraw as you will learning how to match
a visual for a given screen. Without knowing anything about your
application, I'd recommend that you give VERY serious consideration to X.
--
Doug Becker
doug@nmri.ge.com
crdgw1.ge.com!sane!dougfgreco@fis1.UUCP (Frank Greco) (01/29/91)
> > Now, finally in my opinion, the best of all worlds would be to get > someone to right a Mac emulator or something for X. However, given the > legal posturing of the industry these days, I'm sure that this would > result in many billable hours being racked up. > I read in Unix Today that RDI announced a product like this (initially for the SPARCstation) at Uniforum. Frank G.
mouse@lightning.mcrcim.mcgill.EDU (01/29/91)
> I hesitate to ask this. Reasonable; it's almost tailor-made to incite a religious flamewar. > Given a choice between developing for a Macintosh and developing for > X windows, why would anybody choose X? Personally, because (a) I can develop on a UNIX machine (multitasking, primarily), (b) I can't *stand* the Mac GUI, and (c) X is what runs on the box on my desk. Reason (c) is more cause than effect, given (a) and (b). While I suspect it is not very influential in my case, there is also (d) X runs on well-nigh any bitmap display; writing for a Mac restricts you to running on a Mac. > 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 don't know whether it is or not, but if not, I offer as a possible reason that it's also less powerful. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@lightning.mcrcim.mcgill.EDU (01/29/91)
> Well, I'm neither in the X nor Mac mainstream, but I've done a bit of > programming in both. If you'll let me play devil's-advocate with your comments on both systems for a moment.... > In my perspective, the key advantage of X is that it allows you to > decouple the display engine from the compute engine. This can also be a disadvantage; for example, SunView can blit a client image onto the screen a lot faster than X (modulo MIT-SHM). I feel sure a Mac can do it fast too, though I haven't tried it. > just like putting up an NFS server let's you ge a lot more leverage > out of your disk investment. And in both cases, you pay a (sometimes, but by no means always, significant) speed penalty. > Also in my perspective, the key advantage of the Mac windowing system > is that the look-and-feel is superb. De gustibus. I find it intolerable. Yet others can take it or leave it; I know at least two persons who can use either Macs or X machines with approximately equal apparent ease. > Now, finally in my opinion, the best of all worlds would be to get > someone to [write] a Mac emulator or something for X. However, given > the legal posturing of the industry these days, I'm sure that this > would result in many billable hours being racked up. Perhaps one of our colleagues in Europe (where they aren't so lawsuit-happy) will do it. There are a lot of good hackers over there where they don't believe in stupid legal inanities the way they do over here. (Yes, I include Canada. Not yet as bad as the USA, it's true, but getting there.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
auvdeso@auvc15.tamu.edu (John DeSoi) (01/29/91)
... > Well, I'm neither in the X nor Mac mainstream, but I've done a bit of > programming in both. ... It seems if you really have a choice between using X or the Mac, you should look more closely at what your application is going to do and what primitives/tools are available to implement it. While I am relatively new at programming in both of these environments, it seems that certain types of applications would be much easier in one versus the other. One example that comes to mind is working with regions. The Mac toolbox can tell you if a point is in a region defined by any arbitrary combination of closed graphics figures. From what I know about X so far, it appears that only regions constructed from rectangles and polygons are supported. If I'm developing a drawing application where I need to know if the user clicked in a circle on the screen, I would hate to have to write the code to figure this out myself. John +--------------+ Department of Computer Science | | (409) 845-9979, 845-4306 Texas A&M University | John DeSoi | INTERNET: desoi@cs.tamu.edu College Station, TX 77843-3112 | | BITNET: jfd5947@tamvenus +--------------+ -- +--------------+ Department of Computer Science | | (409) 845-9979, 845-4306 Texas A&M University | John DeSoi | INTERNET: desoi@cs.tamu.edu College Station, TX 77843-3112 | | BITNET: jfd5947@tamvenus +--------------+
sarima@tdatirv.UUCP (Stanley Friesen) (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? 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 wouldn't be too sure. I suspect that MacApp is at least as complicated as X. At least in my impression of it from Booch's book it seemed that way. Of course your combining Xlib, Xt, and XView together makes it all seem more complicated. All you really need is XView and the graphics routines out of Xlib for most purposes. (Or alternatively one widget set, such as the Motif library, on top of Xt). I would suggest concentrating first on just one programmer's interface to X, rather than trying to learn all of them. [Some people, including me, think that XView is easier to learn than Xt]. Now reasons to run X. The most important to me is platform independence. This has two components: most applications need only be recompiled to run on a new platform; and the application and display may be on different machines, as long as they are on the same network. This last is a great benefit, since in a network environment it allows you to run apps that you do not have on your local machine exactly as if they were local. [Note that X is available for the Mac!!] -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
guy@auspex.auspex.com (Guy Harris) (01/30/91)
>> Now, finally in my opinion, the best of all worlds would be to get >> someone to [write] a Mac emulator or something for X. However, given >> the legal posturing of the industry these days, I'm sure that this >> would result in many billable hours being racked up. > >Perhaps one of our colleagues in Europe (where they aren't so >lawsuit-happy) will do it. There are a lot of good hackers over there >where they don't believe in stupid legal inanities the way they do over >here. I seem to remember an posting/message here that announced the present or imminent existence of a package that emulated the Mac toolkit - and perhaps other Mac ROM and System calls - on UNIX systems running X. I don't have that message handy, and I don't know whether the product came out or whether the aforementioned legal annoyances killed it or whether something else happened.
guy@auspex.auspex.com (Guy Harris) (01/30/91)
> However on the other hand, unlike the Macintosh *proprietary* > approach, X was designed to be policy-free and only specified the > mechanisms. Also, portability among different machines, operating > systems and even networking protocols was a design choice that > the Mac ignores (probably more of a business decision than a technical one). > If you specify policy in the window system, you probably > can get away with less code in your toolkit and less complexity, > but you lose the portability that allows a client pgm that was > developed on a Sun to be executed on a Cray and connected > to an X server on, say a Macintosh. At the purely technical level, I don't see what being policy-free has to do with portability. Were you to combine the policy-free (mostly) X code with some particular toolkit+window manager, say, that provided policy, and got that combination ported to the Sun and the Cray, then if that combination didn't depend on server features not present on the Mac server, you'd have the same portability as above. Note also that the WM networked window system done at Carnegie-Mellon as part of the Andrew project specifies more policy than does X - the equivalent of the "window manager" functions are built into the server, as is support for menus - and it's been ported to more than one platform as well, although it hasn't caught on (I don't think the source was freely available the way the X source was, although the Andrew *toolkit*, which runs atop WM or X and perhaps other window systems, is available). It may be that part of what got X *ported* to that many platforms was that, by not specifying policy, it didn't tick off as many vendors - although a lot of the porting wasn't done to make an official product.
tomt@maui.coral.COM (Tom Tulinsky) (01/31/91)
) (I would also point to the unrivaled
) clarity of the X documentation
??????????????????????
) and the availability of the X source
) code in its entirety.
Good point, esp. for an eductionaly project. Depends tho on how much
you want to learn about graphics programming and how much you just
want to use a tool.
) Note also that the essential documentation
) for much of X is free, the notable exception being the Asente &
) Swick Toolkit book. [Incidentally, will the *roff source for Asente
) & Swick be included free in R5, the way Scheifler & Gettys et al.
) is now?])
I must recommend that any beginner to X NOT try to learn it through
the MIT documentation but purchase the books by O'Reilly, Jones, and
something for his toolkit. Speaking of which, when are we going to
clue John in that if he choosing X is only the beginning of his
decisions? Maybe we should just refer him to the "Motif vs. Open
Look, is there a trend" thread of messages.
Coral
* ** Tom Tulinsky 508 460-6010
* ** Coral Network Corporation fax 508 481-6258
* ** 734 Forest St net: tomt@coral.com
*** Marlboro, MA 01752
** U S A
*********
NETWORKS lusk@tsc.cs.unc.edu (John Lusk) (02/01/91)
In article <9101301622.AA16048@maui.coral.com> tomt@maui.coral.COM (Tom Tulinsky) writes:
something for his toolkit. Speaking of which, when are we going to
clue John in that if he choosing X is only the beginning of his
decisions? Maybe we should just refer him to the "Motif vs. Open
Look, is there a trend" thread of messages.
Thanks. I'm following it all, goggle-eyed.
John.sarima@tdatirv.UUCP (Stanley Friesen) (02/01/91)
In article <9101301622.AA16048@maui.coral.com> tomt@maui.coral.COM (Tom Tulinsky) writes: >I must recommend that any beginner to X NOT try to learn it through >the MIT documentation but purchase the books by O'Reilly, Jones, and >something for his toolkit. Good recomendation. I have one beef though, most of the bookstores here are still only carrying the X11r3 versions! (I still cannot find the gray edition of volume zero in any bookstore, and the UCLA bookstore just this month got the X11r4 version of the Xt manuals) > Speaking of which, when are we going to >clue John in that if he choosing X is only the beginning of his >decisions? Maybe we should just refer him to the "Motif vs. Open >Look, is there a trend" thread of messages. Well, if I had my druthers, I would code every application I wrote to allow the end user to select the GUI. I suppose right now that probably means coding in C++ and using OI? [Actually I would also code in C++ by choice] -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
don@zardoz.coral.COM (Don Dewar) (02/04/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. ) There are actually many more reasons than that. There is hardware independence, defacto standards, and free software to name a few. X runs on many platforms. If I have two different machines, such as a 386 and a SPARC, running X, they can use each other as a resource seemlessly. For instance, last week one of my peers here, who has a 386 with X wanted to display a very nice color gif image using xgif. Unfortunately his monitor has only fair resolution. So, he used my SPARC's display to show the image. X has become a defacto standard UI platform under unix. So you get all the benefits of standards, that I will not enumerate. People are writing oodles of good free software. I know that there is free software for Macs, but the amount for X will surely eclipse that for the Mac very soon, if it hasn't already. X is a more free environment in general. Granted, the programming platform itself might be a little more difficult, but sometimes you have to work harder to get more. ) 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. The answer to this question depends alot on who the software is for. If is just for yourself, use what you feel most comfortable with. If it is for other people in an existing organization, look around you. Do you have alot of UNIX workstations, or are you getting them? If not, maybe you should stick with Mac. I notice your address seems to be that of an educational institution. You probably will want to be able to share your work with the world at large. If this is the case, use X. Using X and the build tools (imake) that come with it, allows other X users to build and run your programs easily. In addition, you might want to use X just for your own education. +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
stripes@eng.umd.edu (Joshua Osborne) (02/05/91)
In article <AUVDESO.91Jan29083053@auvc15.tamu.edu>, auvdeso@auvc15.tamu.edu (John DeSoi) writes: [...] > One example that comes to mind is working with regions. The Mac > toolbox can tell you if a point is in a region defined by any > arbitrary combination of closed graphics figures. From what I know > about X so far, it appears that only regions constructed from > rectangles and polygons are supported. If I'm developing a drawing > application where I need to know if the user clicked in a circle on > the screen, I would hate to have to write the code to figure this out > myself. If you have the SHAPE extention (it is in all the MIT X11R4 servers), create a round window and ask for button events in it. If you use the toolkit you can try to do it with the elipse ShapeStyle buttons, most likely it should take less then 5 min or so... (5 min more then a button shaped like a rectangle). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)