slc@hoptoad.uucp (Steve Costa) (09/07/87)
An Informal Proposal...
Messages in this group at various times have suggested criteria that
"well-behaved" Amiga programs should meet. Having dealt with some
poorly behaved programs, especially those that hog the machine, I find
myself wishing that there were some way to encourage software publishers
to meet some standards of program behavior.
The thought came to mind that a group such as BADGE (Bay Area Developers
GroupE), or FAUG (First Amiga Users Group) could establish a review
committee to rate software and review programs ONLY on the merits of
meeting "behavioral" criteria. Rated software would be allowed to carry
a notice such as "This software carries a rating of AAA on the BADGE/FAUG
technical standards scale" (or whatever), with some kind of fancy symbol
to make it appear impressive. Surely this would be some kind of incentive
in a competitive market.
It would be important for the rating process that:
1. Review be easily available, so that nobody could complain that
there was any favoritism, or difficulty in getting their software
considered.
2. The technical standards be such that programmers of reasonable
technical ability could understand and implement them. After
all, how difficult is it to create software that doesn't require
you to re-boot each time you run it?
3. etc???peter@sugar.UUCP (Peter da Silva) (09/10/87)
> 1. Review be easily available, so that nobody could complain that > there was any favoritism, or difficulty in getting their software > considered. > > 2. The technical standards be such that programmers of reasonable > technical ability could understand and implement them. After > all, how difficult is it to create software that doesn't require > you to re-boot each time you run it? > > 3. etc??? 3. There should be some indication as to what environment the program runs in: STDIO: The program only uses 'C' stdio calls... can be expected to be ported to non-AmigaDOS environments. may be quite hard to verify if the source isn't available. Will be expected to run from AUX: DOS: The program only uses AmigaDOS calls... no Intuition or ROM Kernel calls... can be expected to be ported to Sinclair QL or the rumored new Atari. Will be expected to run from AUX: CLI: The program runs entirely from the CLI, and doesn't require mouse actions. Will be expected to run from AUX:. CON: The program uses CON: windows only. RAW: The program uses RAW: windows or sets * to raw mode. May be hard to distinguish from the next... console:The program uses console.device for all windows. WB: The program runs from the workbench. This does not conflict with CLI, as the program may be designed to work both ways depending on how it's called. WBA: Like WB, but the programs windows all use color 0 for background, color 1 for borders, and colors 2 and 3 for hilites. WBB: Like WB, but the programs windows use some other color set. SCREEN: The program opens its own screen. VIEW: The program uses viewports directly, or else opens a screen without front/back or drag gadgets. Amiga-M should still get you the workbench. LACE: The program uses interlace screens or views. None of these means a program is necessarily badly behaved... just that it does whatever it does. If the program needs to open its own screen and inhibit dragging, that's cool. Also there are considerable degrees of overlap. For example, a program may play with its own viewports yet run all its workbench I/O though the console.device (Videoscape 3D). A program can even use all STDIO and still open its own raw window (early implementations of HACK). Personally, I think that if (frex) a disk catalog utility opens its own screen, it's badly behaved. A text editor or terminal program can just get away with doing that if that's what it needs to do to run 24 by 80. It shuld ideally check the workbench size first to see if it can get away with a window. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
adh@well.UUCP (Allen D. Hastings) (09/12/87)
In article <680@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >dragging, that's cool. Also there are considerable degrees of overlap. For >example, a program may play with its own viewports yet run all its workbench >I/O though the console.device (Videoscape 3D). A program can even use all STDIO Just so nobody gets the wrong idea, VideoScape does its user interaction through Intuition (using a Preferences-like window full of gadgets), and uses an Intuition custom screen for graphical display, not just a raw viewport... >-- >-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter >-- 'U` <-- Public domain wolf. Allen Hastings
peter@sugar.UUCP (Peter da Silva) (09/20/87)
In article <3936@well.UUCP>, adh@well.UUCP (Allen D. Hastings) writes: > In article <680@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >... own viewports yet run ... trhough the console.device (Videoscape 3D). > Just so nobody gets the wrong idea, VideoScape does its user interaction > through Intuition (using a Preferences-like window full of gadgets), and > uses an Intuition custom screen for graphical display, not just a raw > viewport... Sorry about that. I'm not sure about this preferences screen stuff, though. The last time I watched someone do stuff, he seemed to be doing most of his work through a CON: type window. Which is perfectly cool. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?