Re: Anybody here endure C/Cpp? (.h to .inc conversion)

websnarf_at_gmail.com
Date: 01/07/05 

Date: 6 Jan 2005 18:46:42 -0800

> Now, _THAT_ is a more than reasonable set of "minimum requirements",
> eh? EXE file is only 385KB and this does include two example
> bitmaps to show how it works (a large Jodie Foster backdrop and some
> picture of a galaxy...neither of which are small so, chances are,
> the majority of that 385KB is for these JPEGs, as they are actually
> inside the program itself)...

The 385K (or whatever it was) also included a multitasking kernel
(active only when running under DOS -- the program does a lot of silly
manual multitasking when running under Windows) a very inefficiently
coded JPEG decoder, a 65K DOS extender and other nonsense as well. But
on the other hand it was a bit of a stretch to call it a GUI. I just
got the primitves down, and needed to build an API for constructing
arbitrary Windows in a way that would be sensible from the application
level. Never got around to that. :)

I don't think I have the stamina to read through your entire post, but
I think the jist is that you think that the standard GUIs are
cumbersome or otherwise poorly designed. Of course, I agree, but you
have to understand that the authors are motivated to do what they did
-- Microsoft adds real weight to their proprietary value add by making
sure that writing a "GDI-clone" (and therefore Windows-clone) is not
really feasible. The X people were convinced that graphics should be
done on terminals seperated from the *REAL* CPU that you ran your
programs on. OpenVNC kind of makes each vendor's arguments look kind
of silly these days.

In any event, GUIs have still not provided interfaces comparable to
stdio in the area of "pipes", "redirection" and so on. Form has
superceded function -- and we have let this happen to ourselves. In
the years since writing that demo, I have come to the realization that
the real problem with GUIs is that their behaviours in programs in
compiled in by the software vendor and are not modifiable at all. At
the same time consider how much fun people have had "MODDING" games
like Half-life, DOOM/Quake, etc, or even skinning audio players like
WinAmp. You see, now that the computer industry has matured -- the
audience for any popular product contains *more* programmers than those
that originally *MADE* the program. And the most wretchedly limiting
thing I see in most applications is that they either have horrible
interfaces (mostly related to the complications of GUI programming, or
just idiotic interface design) or have not good way of interfacing with
other applications in a useful way other than manual cut-and-paste.

You see for DOS/UNIX command line application we can write
scripts/batch programs to control our programs to make them better than
they are by themselves. There's nothing like that for GUI based
applications -- and I think that its set the industry backwards by
quite a bit, and allowed it to be taken over by marketing people whose
job it is to convince you that their application's GUI is good.

This has lead me to believe that the right way for applications to
interface with GUIs is to be given an interface like HTML/javascript,
that must be presented in *EDITABLE SOURCE FORM*. This would first of
all, give more lee way for the OS's GUI support to deal with GUI
performance, and more importantly give curious/enterprising end-users
the capability to improve the GUI and/or link up applications in the
GUI description language.

But that's just my opinion. :) 

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Relevant Pages

  • Re: Ease of use (was: Re: Idiot (I know thats redundant) spammer
    ... 'Longhorn' GUI, and while by then there clearly *was* an existing interface ... If you want to talk about editing, the more apt comparison is between ... TECO was wonderful: I ...
    (comp.os.vms)
  • Re: What Mac can beat this for the same or less?
    ... HD Video Tuner ... Recall that the primary draw of OS X is its GUI, ... In Windows you should worry about this, as a 64 bit user interface is wasting resources; ... This means that if it is written by a half way experienced programmer, the GUI interface code is written seperately from the real working code, which makes this distinction a complete non issue. ...
    (comp.sys.mac.advocacy)
  • Re: command line vs gui
    ... "FJ>> command lines over GUI, even when using Windows. ... "FJ>> best of both worlds with an interface using charts/fields of text? ...
    (comp.os.linux.misc)
  • Re: Why I like Linux (but an not really satisfied)
    ... > hands down the best GUI ever, ever, ever (except for maybe BEOS, I never ... I will agree that Linux can be a pain in the ass sometimes. ... Windows, especially with Microsoft's own applications. ...
    (comp.os.linux.misc)
  • Re: Confusing stack effects
    ... so a Click&Go interface is nonsensical. ... somewhat more difficult to do with half a dozen self contained GUI ... What does Annie have to ... Or even assemblers? ...
    (alt.lang.asm)