I studiously avoid GUIs in all shapes, forms and guises.
I was brought up in the Unix school of thought,
(a university actually),
The problem is this: GUIs are very unportable,
sure, if you can abstract Reaction, MUI, etc then
yes you can port between Pegasos and A1 and AROS,
Problem is:
you cant port to Unix, Linux, PCs, Macs, etc
so whats the use, eh?
OS4 is created using gcc, gcc is probably the most
portable program in the universe, the fact it has
no GUI is part of its extreme level of portability.
If gcc had some fantastic GUI it would be fantastically
unportable,
All my programs are shell driven only,
some are highly nontrivial progs eg I am 5 months into
my current project and there is no GUI whatsoever.
:and I am proud of this, its a feature! (a portability feature).
(this is not Ghostscript 8 which also took 5 months
including the waiting. For the Ghostscript 8 viewer I dont bother
with a GUI instead you move the picture directly by dragging
with the mouse, I also make use of the keyboard eg zoom in and out
via cursor keys, the mouse buttons are used for the different
scroll mechanisms),
Anyway GUIs only enter the picture if the logic of the problem
necessitates a GUI.
Consequence of this is that I can port my progs to
Macs, PCs, Unix, Linux, Morphos, A1 , AROS, everywhere in fact.
The moment I put in a GUI I am beginning to rule out the first 4
platforms in that list.
Some people seem to think that a prog without a GUI cant
be a proper prog, hmmmm so you think gcc isnt a proper prog.
Yeah, right!
PGP doesnt itself have a GUI though a standalone one exists
in the form of PGPgoesMUI. Not sure of the asynchronicity,
I havent yet tried to generate 2 PGP keys in parallel.
So, yes if there is imagery, then that may necessitate a GUI.
Here I will just use Intuition facilities as available in
OS1.2 or OS2.0. whichever OS version it is I stick to good old
fashioned intuition.library (but see below regarding asynchronicity),
why?
because then my prog will run on Pegasos, A1, AROS, Amithlon, classic Amiga
etc
lowest common denominator portability
IMO GUIs are a total non-issue,
I am much more interested in what a program does
than the interface.
:The most important part of a prog is the stuff you cant see IMO,
OK, so your internet dialup prog has a
marvelous GUI,
I dont actually care,
what I care about is: can I dial up real fast,
does my dialup prog never crash,
is the data-transfer very fast,
Sure, a GUI is essential for a browser,
but see below why full functionality can be
achieved without MUI,
BTW regarding browser gadgetry, instead of
automatic placement of gadgets, I would prefer
OS gadgets to be on a stand-alone window as
they eat up so much of my 640 x 256 hi-res screen.
That way I can hide the gadgets by depth arranging their
window out of sight and have maximal image size.
hi-res-laced is no good to me because the font-aspect
is squashed for a start.
Regarding a GUI for entering parameters
I am quite happy just to enter the data into
a text file via Memacs TBH.
Setting up my Internet parameters is a one-off activity,
so a GUI makes zilch difference to me in the long run.
Equally good for me would be a shell-run questions and
answers prog, like they used to use in the pre-GUI era.
With Genesis, I typically double click its icon to run it,
and then I click online to begin a session.
Lastly I click offline to terminate a session,
and closewindow to exit.
:so an entire internet session is 5 mouse clicks,
whats the GUI got to do with it.
Do I really need MUI for that??
MUI? HOOEY!
What annoys me is the amount of crashes I get when
using Genesis on my OS3.9 setup, not sure if its
Genesis's fault. Possibly the fact that I use 2 different
sized SIMMs on my ancient Blizzard 1230-II is causing the problem.
If I need asynchronicity, I will use the approach
we were taught by Unix reared lecturers:
for total asynchronicity I would create firstly a
task that monitors the OS1.2 GUI
Now when the user eg clicks a button, this GUI-task
would now create a subtask that carries out the
required action. If the subtask generates its own
window and someone clicks a button in that
the sub-task generates a sub-sub-task to respond to
the event ad infinitum,
total asynchronicity,
thats what we were taught on more than one course:
for an asynchronous GUI you launch a new task (or thread)
for every user sub-action.
:that's it, nothing more to be said, it really is such
a non-issue.
The sad thing is that my OS3.9 setup all over the place
lacks total asynchronicity, with or without MUI or Reaction
or whatever,
I find it interesting that MUI GUIs that I use are not
totally asynchronous, eg I have at least 2 MUI GUI internet progs
which arent totally asynchronous.
Whats the point of all that MUI bloat if I cant
get *total* asynchronicity.
I can get total asynchronicity by the unix-textbook
technique of launching a task from every gadget action
via OS1.2 or OS2.0
so using my Unix methodology
I can create total asynchronocity way ahead of
actual MUI apps,
Not only that I get total portability to other
Amiga compatible systems.
Now there is also the issue of colour remapping the GUI
if the user changes the colour palette,
however intuition will inform a program about
Prefs changes,
so provided you listen out for this particular event
(IDCMP_NEWPREFS?)
your GUI sub task merely has to close the window and then
reopen it afresh just like it did first time round:
ie no extra work required if the prog is coded
intelligently.
:havent people heard of subroutines??
Note that colour palette changing is a 2nd millenium
issue, here in the 3rd millenium we are moving towards
truecolour screens.
Generally I never change my colour palette as my current
settings are just right and have been unchanged
probably for over a year.
BTW I have lots of progs that dont automatically redo
their settings on Prefs changes, and its never really
been an issue worth even thinking about,
eg I dont think Memeter resets,
I have to close and reopen it,
oh big painful deal!!
oh how I suffer, how I suffer!
I better dial the Samaritans!
Someone please agree with me otherwise I am going to
be thoroughly unimpressed
