Re: Wiseman and McGhie are Ranting Again

In article <#L#sh1OvFHA.2348@xxxxxxxxxxxxxxxxxxxx>, Jeff Wiseman
<throwawayacct223@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

> Elliott Roper wrote:
> > In article <#LQ5JwHvFHA.664@xxxxxxxxxxxxxxxxxxxx>, Jeff Wiseman
> > <throwawayacct223@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >>The analogy is that Word is like a bacteria in a healthy body
> >>when it is run over Darwin. The prioritizing algorithm of Darwin
> >>sees this process that wants to just keep running because of its
> >>silly "idle loop" design, and so it will attempt to protect the
> >>rest of the system by dropping Word's run time priority in stages.
> >
> >
> > You are being hard on Word here. It is not so much an idle loop as an
> > 'event loop'. Nearly everything with a GUI has something like an event
> > loop in it. It is horrible, but that's the way it is. If Word is
> > waiting for input, it will use very little CPU. Looking at top forces
> > you to believe that it is scheduling itself to run more than it ought
> > to, probably looking for stuff from other bits of Office in a dumber
> > than normal way, but it is never sitting in a hard loop as you claim.
>
>
> In your response to John, you also discussed issues of this
> nature imposed by the GUI implementation. I must admit a lot went
> over my head as the days of me working as a real time embedded
> systems software engineer was quite a ways back. Most
> applications I worked on tended to work directly off the standard
> input and output in a Unix type system. Keystrokes were handled
> via interrupts in the device driver and sent to the application
> grouped statistically. Although applications could be set up to
> poll for everything, the correct way was for the application to
> block while waiting for a semaphore or message in a task queue.
> When this occurred, that task was totally dormant pulling no CPU
> cycles whatsoever until it was passed the appropriate event from
> the OS itself.
>
> However, using a GUI to essentially replace the I/O device
> drivers obviously will have issues I'm not familiar with. A
> device driver by its hardware interrupt nature must run at top
> priority in the system. I'm guessing that a formalized GUI (e.g.,
> the finder, Openwindows, X11, etc.) is forced to have large
> software components that must deal with multiple priority
> components to handle the data flow control issues. Are these the
> reasons you make the above comment? Because certainly from a
> command line, all applications can be made (if the developer is
> smart enough to choose it) to fully block when waiting for any
> events.
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.
>
> 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.

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.

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.

> > PS I like your and John's discussion about users getting into a working
> > pattern. It helps to explain how proponents from each camp stay
> > polarized.
>
>
> I was going to elaborate a bit on that but I figured Sunday was
> over in Australia anyway :-)
>
<snip 'consider unlearning stuff'>
> Another thing is that superficial components of a problem seem to
> get so much more weight in making decisions sometime. The Aqua
> based finder in the new OS X may be more cosmetically appealling
> to newcomers than say a Windows XP desktop. Is that alone really
> enough to base a decision on? I'm more interested in how much of
> the OS has been built in an orthogonally structured fashion. That
> way it will have fewer bugs, the bugs that are there will be
> detected and removed more easily. This kind of an OS is
> strengthened over time. A poorly structured OS will only have a
> future of increased entropy. Structure begets structure, entropy
> follows entropy.

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
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.
>
> I would rather have a more limited GUI knowing that what's
> underneath it is more solid. I want my life to be easier, it
> would be awfully disappointing to realize how easy or intuitive
> something could be by just changing how you think of it.
Heh! We would have found it by now if it were there. Actually one of
the pleasant aspects of GUI working are the diverse alternatives. Once
in a while it is pleasant to use the mouse. The programs you get to
really know and love often have several ways of doing the same job.
You just have to watch the different answers to users' problems on this
list.
>
> Case in point, trying getting a light user/newby to understand
> what a hanging indent is and that you don't use multiple spaces.
> If the application makes this easy to learn and apply (like
> MacWrite, or Clarisworks used to be) It's easy for the person to
> cross over. Trying to use the paragraph styles and formatting to
> set up hanging indents in Word are still scary to ME!

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.
>
> This is the basis for so many of my rants with MS products. Items
> that are not intuitive and have severe penalties and side effects
> when not totally, fully, and extensively implemented, will NOT
> be learned by many, many people because they will give up and
> even reject the product itself (if they are given the
> choice--many are stuck with Word because they have no choice as
> John has pointed out before). If a product is structured
> cohesively, it will tend to be intuitive such that if a newby
> made a guess as to where he would find an answer or how to do
> something, if after trying it finds he was correct, it fosters
> confidence such that they will more easily try even more new
> concepts. If they spend 4 frustrating hours and then STILL fail
> due to some inane obscure gotcha in the product, they will give
> up and probably never try searching for or trying any new aspect
> of that product on their own again!

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.

Word on the Mac is between a rock and a hard place. It is built on
Carbon and has to work like its cuz on the PC, and work like it used
to.

It would be nice if the XML-ish next version of Word could be
compatible with Core Data... wheee! is that a pig circling overhead?

Not the least of Office on Mac's problems is the Windows frameworks
are not standing still either. There will be a lot of original work
needed to map new Windows stuff to new Mac stuff as they try to keep
the two in line. It must be something like herding cats.

> > 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.

>
> For example, the object pardigm should be maintained everywhere
> possible since that is how we think....
<snipped good Excel example>
> Get the point? :-)
Oh yes. Like the famous yokel said "I wouldn't start from here"

--
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248
.

Relevant Pages

  • Re: Splash Screens , how could something so basic still be hard?
    ... You say that there "is no message pump to allow for further GUI ... Note that by "there is no message pump", I mean that because of the way the code is written, no message pump is working while the "splash screen" is displayed. ... In a normal Forms app, there would be a message pump loop, and there's no reason to believe that in those examples, one doesn't exist. ... The same technique is possible in Windows, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: MFC & Guis
    ... The fact that so many GUI wheels are reinvented by so many devs is an ... Users of Windows software form expectations ... > to learn to use your app. ... > while the client areas exhibit behaviour specific to the application domain. ...
    (microsoft.public.vc.mfc)
  • Re: How to make Forth interesting?
    ... trying to deny that I wrote and distributed lots of software ... I think GUI is a good example. ... Humm, Windows Forth ... to the flash files etc. to create flash images for the target ...
    (comp.lang.forth)
  • Re: Linux, X, ld, gcc, linking, shared libraries and stuff
    ... going beyond solely the application side of things to the GUI / OS ... messages" then Windows could not just not deliver any mouse messages to the ... know what best "treatment" or "prescription" to give someone to get healthy ... adverts "imply heavily" that if you chew their chewing gum, ...
    (alt.lang.asm)
  • Re: A little musing on Linux ( was Re: Zip files to multiple floppies)
    ... > various distributions Of linux have made me think a little harsh about ... > and troubles far more than Windows. ... The amount of extra work to program a gui ... Mounting filesystems for example - windows computers only ...
    (Fedora)