Re: Wiseman and McGhie are Ranting Again

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Elliott Roper wrote: 
When you set up your application's GUI interface, you register with the
OS all the events you are interested in and then wait. The operating
system will schedule you whenever one of them occurs in one of your
windows. That part of the OS is the windows manager and is typically a
monster.
When you get control, you run about looking at why you were scheduled
and decide what to do about it. That is your event loop. You may say
you were interested in time expiry as well. Then you do whatever is
needed and wait.

I kinda thought that was what you were getting at. In the custom systems that I was involved in building, we got around all those problems by restricting the unblocking of a task to a single event type--the receiption of a message on a pipe. All messages were defined to have a "message type" field so as soon as the task came unblocked and called up its message, it simply passed it to a case statement--basically a simple state machine to process the event. Even interrupts were simply converted to messages by the task and sent to itself. This solves a magnitude of glare conditions by GUARANTEEING that all events are processed exactly in the order that they occurred IN REAL TIME. It also had the advantage that during state changes, events still in the pipe/queue that were no longer valid could be selectively purged appropriately during the state transition.

And this was all done on a "Unix" type environment (e.g., SCo Xenix, etc). The upshot was the need to disallow programmers from using the "other" legacy signalling mechanisms in the OS. Unix has become efficient enough that sending a message to a pipe is just as fast as sending a signal or trap. Forcing the programmers to use the single generic message event concept solved an entire host of problems of the nature which you describe. The problem is that most OSs out there now are not trimmed up this way as there is too much concern about "legacy" applications that have all of this confusion of inter-task communication types that need to be maintained.

It CAN be done, I've worked on teams that have done it but the Legacy beast is a hard one to kill in marketing (and as Mr. McGhie has pointed out on occasion, if there's no money coming in, there is no payroll for programmers...)


Also, this "horrible" circumstance that the GUI introduces and you refer to--is it a common issue in all GUIs that you know of? For example, would this issue exist in typical Unix GUIs as well (e.g., the Openlook Window manager or other Solaris interfaces, X11 windows, and even something like Aqua over Darwin? 


Yes, it is almost universal. I preferred VWS on VMS, where ASTs were
delivered right to the door, in chronological order, but that was
thrown out years ago in favour of X11/DECWindows/Motif like all the
others used, where you scuttle about your event loop, emitting
callbacks willy-nilly, possibly in a different order from the user's
actions.


Ok, so it does appear that its the same problem in that there are too many ways to report and process those events (i.e., like in Unix, signals, traps, messages, etc). I assume that by AST, you are referring to Asynchronous Traps? I also assume that your comment was referring to how in VMS only processing ASTs as events you are guaranteed real time sequencing? My point is that you CAN have that in the Unix environment but it requires the OS wide restrictions and programmer constraints that I just pointed out. You would be amazed at how well this works. However, everyone wants Unix to stay Unix. And these WERE custom GUIs (albeit much simpler than the current Finder, etc.)


Either way, it is in contrast to the CLI way, where you simply do not
have to worry about the pesky customer from one return to the next.


Well true, but maybe that's only because CLI based applications typically don't have a widely divergent set of event types to deal with. It would seem to me that that is basically the only real difference is the much wider range of event types the GUI itself has to handle and all of the real time implications. E.g., the one thing that I always hated the most about Windows was when you lost control of the cursor or it's movement across the screen wasn't smooth. You sometimes couldn't move it when a process started spinning and the "feel" of that was always disturbing to me (in general, the Mac never really did this). This doesn't have to be this way but it requires a significant infrastructure change and we are again back up against both the Legacy beast AND the programmer's ability for a proper implementation to be realized.


Cramming CLI thinking into a GUI is often unsatisfactory. If the
computation takes a long time, the interface goes to pot. If you
counter that by scheduling threads, you end up writing a mini operating
system inside your application to keep the little snivellers apart.


Yes, as just mentioned above. The other issue is that most programmers think procedure when you really want folks that are fluent in state manipulation at the top of the application itself. Unfortunately is not a common skill. Although there are many programmers that can partion software modules into fairly cohesive sections, not many know how to partition a massive state machine in to its cascaded Mealey and Moore type components (although as folks become more proficient in the object paradigm this is changing some). If your entire application task is reduced to nothing but a state machine's event handler (which I declare is the "correct" solution here), you are really going to need people who know how to do it effectively.

BTW, I suspect that the multi-threading type programming is actually a bottom-up approach to the partitioning of a high level application state machine to deal with the real time issues, but again, with so many people thinking in terms of linear processing instead of pure event handling, this type of design becomes more of an art form than a science. Hence the complexities that you have already referred to.


I think both Windows and Mac OS X each suffer equally in this regard.
Unix never progressed beyond X11 for GUI stuff. It is still a


I thought that Motif was kinda the next step since it sorta sat on top of X11, didn't it? In recent years Sun's Solaris started having lots of applications that insisted on the Motif stuff. Again, not as familiar as I'd like to be but I thought Motif had actually gotten past the X11. Is X11 still the only really solid standard in that area? Has Motif been dying?


multi-user CLI minicomputer operating system. The NT kernel is much the
same, without the multi-user history. Neither sits well with its GUI.
NT's entropy is Win32, dumped uncermoniously into the kernel, mixed
with ActiveX and released as a security nightmare. OS X's is the unix
file system, stunted at birth by lack of metadata, and totally bereft
of structure. How its proponents can claim this to be a feature has
always escaped me.


Heh! Ever try setting up a desktop on a Sun? what a nightmare! Once it's set up, you're ok, but don't try to change it. The tools that Sun provided just to do things like add an application to a tool bar was the only thing that I saw which would consistently crash the entire workstation.

The issue as you point out is, of course, the metadata concept is an object that contradicts the basic standard IO data structures of UNIX. We're back to the Legacy beast again. It's hard to add he metadata concept since it really needs to replace some things IMHO.


Trying to get Word to do *anything* with typographic elegance is almost
impossible, but here you have a point. Look at the way specifiying
numbers and specifying indents are intertwingled in Word.



Heh, "interwingled" is right!


Indeed. What you need is a decent framework underneath it all. You can
see the difference when applications are built on the Cocoa Framework
by developers who are not fighting it. Look at OmniOutliner or
OmniEverythingElse or TextEdit or Pages or Xcode itself to see how the
structure builds on itself. With Core Image and Core Data this will end
up as powerful stuff.


Right. What you are seeing here in those frameworks is a natural slow but sure evolution toward the inherent "objectness" of the problem domain for a GUI. Unfortunately, the Legacy sits underneath, in the case of Mac OS X, it is a Unix clone. Now if they can just retrofit those concepts into the OS itself--sorta like when Microsoft tossed the DOS layer in order to allow it windows objects to run freely (not all of the Window objects would map nicely through the DOS--not to mention the layering problems). Obviously, one of the things this would do for Darwin is integrating the metadata in a native fashion as you've pointed out already. The "objectness" of the way data is viewed in the abstract would be more closely modeled in the OS's implementation.


The other I was showing someone a few neat Mac tricks
(keyboard nav mostly) and he was mildly impressed. Then he counterd
with a virtuoso display on his Windows lappy, and so was I.


I will not deny that the interface flexibility--especially customization--on the PC can be quite extensive. However, were all of those "tricks" simply logical extensions of things you already knew, or were they special exception capabilities that were put in just to provide some kind of useful trick?


I think he was holding his raquet the right way. 


I have come very close to using a racket on a PC...


Oh yes. Like the famous yokel said "I wouldn't start from here"


But the million dollar questions are "Can you GET there from here?" and if you can, "Will marketing LET you?"
:-)


--
Jeff Wiseman
to reply, just remove ALLTHESPAM
.

Relevant Pages

  • Re: A clean OS?
    ... If we do that, the Windows ... > "vague configuration parameters", ... >> faster with a GUI. ... > And that's an option in Unix, whereby it's not an option in Windows, ...
    (alt.computer.security)
  • Running a program on a different computer over the network
    ... I have a modeling program that runs on UNIX, and a GUI for it on ... Windows that does input validation. ... Cons: Extremely inelegant; security issues; requires files to be ...
    (comp.programming)
  • Re: File upload script
    ... SFTP, remote, local, web-based, commandline, GUI, from Windows, from ... Mac, from UNIX? ...
    (perl.beginners)
  • Re: A clean OS?
    ... start/stop say Apache much faster than a Windows NT Admin ... >> the website virtually hosted in the conf file. ... or make more mistakes in a GUI because pointing and clicking is so ... And that's an option in Unix, whereby it's not an option in Windows, ...
    (alt.computer.security)
  • Re: kde vs gnome
    ... I can't find the word 'KDE' in the post you've replied. ... >> claiming, for example, that Kde is a Windows clone. ... they really know the GUI is attracting. ... Because it's Unix? ...
    (comp.unix.bsd.freebsd.misc)