NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/5961

Text File | 1996-08-05 | 7.4 KB | 168 lines

Newsgroups: comp.sys.amiga.programmer
Path: EU.net!sun4nl!hguijt
From: [e-mail] (Hans Guijt)
Subject: Re: What the new Amiga-OS *must* have --> SAY *NO* TO FAT BINARIES!!!
Message-ID: <[e-mail]>
Organization: NLnet
X-Newsreader: TIN [version 1.2 PL2]
Date: Fri, 22 Mar 1996 16:56:22 GMT

>- A fat binary format is badly needed. Not only that it could hold both
>680x0 and PowerPC-Code, the most important thing that is

A fat binary format is *exactly* what we do not need.

- If you have a 680x0 machine you waste space by storing PPC code.
- If you have a PPC machine you waste space by storing 680x0 code.

Just why do so many think fat binaries are good? Because 'they' have them?

>- A more complex and driver-controlled graphics output system is badly
>needed. If you've seen the flexibility of Windows' GDI, you really know what
>is ment by "graphics primitives". If you want to program an illustration

ie. Windows is *really primitive*...

>program, you can use the same commands to draw curves, rotate text and use
>different pen types on the screen *and on the printer*. Try that on the
>amiga! Ever made printer output besides ascii-text? Then you know what I
>mean. And more fundamentally: more drivers are badly needed. Graphics
>Accelerator cards have to path (!) the system functions to get useable.

You use a rastport to print graphically. You can use all available graphic
primitives to draw into that rastport.

>- The GUI needs a complete rework. Not only that menus can't be controlled
>from keyboard, gadgets lack the feature of cycling through them by cursor

...menu's CAN be controlled from the keyboard.

>keys or tab and the cycle gadgets don't use a menu to choose what you want

Amiga's generally speaking come with a mouse. It can conveniently be used to
press gadgets and the like. The Windows system (tabbing through endless
gadgets) is extremely inconvenient. I work with it every day, so I say this
with some authority.

>(you have to emulate all these features with a bunch of commodities), the

You are talking about exactly *1* commidity here: CycleToMenu. If you want
it, it's a one time installation and it will work for the lifetime of your
Amiga.

>inner representation of the GUI system is totally out of date. IBM made an
>effort to reach user friendliness in 1991 with the Common User Access Style
>Guide. This guide contained notebook-like property boxes and containers (for
>icon boxes, tree views and a spreadsheet-like view). And Windows included
>most of them in 95. Not the Amiga.

No, the Amiga had them since time immemorial. *WE* are not stuck with string
gadgets that close your window when you press return (as happens far too
often in Windows applications).

I generally find that C= had very sensible ideas about how things should
work. The Amiga is the *only* windowing system that I know that has 'toback'
gadgets on every window. I positively HATE Windows for not having them: I am
always moving windows aside in the vague hope of finding other windows that
got hidden before. Of course, once you want that particular window back
you'll have to move the front window even further if you want to find the
original window again...

And I despise that 'clicktofront' feature. I find myself continuously
resizing stuff so I can read in one window and work in another.

And then there is the dropdown listboxes that always open *with the same,
wrong size*. And windows that open with their titlebar hidden below the
taskbar (yes, I use windows 95). And those scrollbars that totally fail to
represent the amount of information you have as well as your position in it
(yes, I know windows 95 should have proportional scrollbars. Unfortunately
it doesn't in any of the applications that I regularly use). And then
there's the fact that too many windows are just too small; I work in
1024*768 and find that most apps open as stamps in the upper left corner of
the screen. And it is totally font-insensitive despite what you have been
told. Support for resizing windows is non-existant. I could go on, but I
think this demonstrates sufficiently that you shouldn't believe everything
they or their styleguide say.

Their styleguide does not even specify the order of response gadgets! You
cannot intuitively cancel windows, you always have to scan it for the right
cancel button.

>This development is due to the imo genius way control elements are handled
>under Windows. Each element is a window (with the one you can drag around as
>the topmost) of a specified class, which can hold subwindows. And it's the
>window that receives messages for user I/O. So you can easily create a class
>that displays files in several columns, where each of these can be moved and
>sized with the mouse: the class window controls several subwindows, which
>are a "black box" for it, it just moves and sizes them by sending it
>standard messages. This is OOP. Boopsi?? lol. (even rofl ;) Crashes, hangs,

...and the application is responsible for resizing and moving the windows it
owns; therefore, if your application neglects its messages for a while you
CANNOT manipulate its windows. This is especially painful when you have
several response windows open on top of each other.

>low speed, C structures, harsh casts -- it's no pleasure to program that
>(even try to debug it!).

What you say about BOOPSI is complete bullshit.

No, you'd rather have that great windows API (GetWindowLong (Window, -16)
anyone?)...

>-- Introduce a resource format. This feature, normal in most operating
>systems, frees the programmer from hacking his dialogs in C-Code. Instead, a
>second person with designing abilities can create it, can add graphics,
>menus and keyboard short cuts and includes it in the program. The data can
>be changed even after the program is compiled. The resources are loaded only
>when needed. All changes can be made with a WYSIWYG editor, not with a text
>editor.

So you can change dialog boxes in Windows - big deal. Now try hacking *real
windows*. Oops - you can't.

>What about MUI or EGS? They're both very powerful GUI systems, but only for
>programmers, not for the ones in the Usability Department. You can't design

EGS isn't a GUI system, it's an RTG system.

>the GUI free, you must specify rules for each side of an element, so that it
>can be sized with the font or the window. This mostly results in jammed and
>ugly dialogues.

The GUI's produced by MUI are among the most beautiful I have seen on any
platform (including Windows, Windows 95, OS/2, EASE, GEOS, Motif, Solaris,
and others). Even better, they don't need wide expanses of screen just to
show a simple 'yes-no' style window.

>More important details concerning the user interface: A new standard font
>(throw topaz in the trashcan), a bigger sizing gadget, totally keyboard
>driven environment, local menus, notebooks and other class stuff, support
>for truetype and type-1 fonts, better color displaying and printing
>facilities, pen and filltype selection, and, finally, a new asl.library.

Support for truetype and type-1 fonts comes in the form of bullet-compatible
libraries. As a matter of fact support for these is already available from a
commercial source: if you buy WordWorth you get both libraries.

Pen and filltype selection? Mind explaining *where*?

New ASL? What should it contain?



>\///  Clemens Marschner [e-mail]
                                  ^^^

Damn, I should have known!

Don't bother replying - I know you are from AOL.


Bye,

Hans