Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!cs.utexas.edu!sun-barr!newstop!texsun!texbell!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.windows.news Subject: Re: Toolkits, toolkits, toolkits ... Message-ID: <7391@ficc.uu.net> Date: 21 Dec 89 21:20:46 GMT References: <8912162135.AA03025@iris.rand.org> <4290@crdgw1.crd.ge.com> <7352@ficc.uu.net> <4301@crdgw1.crd.ge.com> <7363@ficc.uu.net> <18637@bellcore.bellcore.com> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 108 In article <18637@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: > There is simply no use comparing something like stdio with a a > graphical user interface. There are two "tricks" behind stdio: 1) > let's imagine that files are just bytestreams and 2) the printf vararg > hack. So what sort of "tricks" do we need to solve the window programming problem? > These are nice tricks to be sure, but are something of an > overabstraction. How many times have you seen the query, "how do you > read a single character from the terminal" in comp.lang.c? And I'd expect that in a real high-level windowing environment you'll get the same sort of question. And the same sort of answer: "You don't do that". In the case of C, you use curses. Stdio is the wrong tool for hacking with the screen. It's too high a level of abstraction. In the case of windowing, you design the user interface at a higher level of abstraction. But don't force the whole program into that mould. > Hmmm. Let's see if we can find a simple abstraction for windowing... I don't know either. But I think it's a much more important problem than deciding what windows should look like. The examples I gave were deliberately simple... > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); > Looking kinda like a widget call isn't it? Maybe. But you don't want to design your program around the UI, like you have to with widgets. > Good points all. That is why I like to download all of my UI code > into the server and interface to it using stubs crafted to the > specific functionality of the interface. Looked at NeWS's "cps" yet? Yeh, it's a nice metaphor. I'm not sure it's the best one for today's systems, though. It's got quite a bit of overhead, and you're not going to be able to cram much of a postscript interpreter into 640K if you need your apps in there as well... > > Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's > > way too low level for something like this. > Mon ami, have you REALLY looked at the X widget interface? Nobody is > suggesting you write an interface using Xlib. The interface is not so bad. You still have to design the whole program around it, though, or you'll end up pissing off users who want to work instead of wait. That level of abstraction belongs in the server. Not the program. No matter how it's hidden. Here we have my "desirable" example: > > "I want a window big enough to hold the following > > objects: a text pane containing this text, and a > > selector for YES and NO. Tell me when someone selects > > YES or NO, and don't bug me otherwise", This stuff here was my "undesirable" example. Of course this is what systems like X give you. They hide it, but your program still has to be able to get back to the user or none of this will happen: > > "Draw a rectangle here, now put these characters in > > this font here, and then draw these rectangles... > > (lots deleted) now tell me when anyone clicks in my > > window. Oh, OK, erase this rectangle and redraw it > > here, and blit this rectangle up by the size of this > > font, put these characters here, and tell me what > > you want me to do next..." > There is a minimum complexity to a windowing interface unless you > accept that some of the inherent capabilities of the device will be > unaccessable. I accept that some inherent capabilities of the device will be unacessible at this level of abstraction. Similarly, most of the hardware UNIX runs on is quite capable of, oh, lightweight processes, asynchronous I/O, real time response, and so on. But people are wiling to give all this up so they can use a higher-level metaphor. Your argument here is beginning to sound like the ones advanced by PCware programmers who NEED to get to the raw hardware. Remember, form liberates. > Yes, simplifying models are quite useful, but they are > not always appropriate to the task at hand. This is why an > object-oriented interfacing approach is a Good Thing. But it makes your programs huge. The program itself should have as little of the user interface as possible as an integral part of itself. If you need to go to a lower level, do it. But first make the easy things easy. "Hello World" in a windowing system shouldn't be more than 10 lines of code. Oh, and yes. I would LOVE to play around with Display Postscript. But it's never going to show up in today's PCs, and the way things are going it's gonna be a long time before it'll show up in any. Standards aren't just for the elite. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com