Welcome, Guest. Please login or register.

Author Topic: Wouldn't it be nice if...  (Read 3615 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Wouldn't it be nice if...
« Reply #14 on: September 19, 2003, 11:59:55 AM »
I would agree with Kronos, that since Zune and MUI are avaiable for all three systems (and given the maturity of the MUI sysetm, and the freeness of Zune), it makes sense to target that, over Reaction, in a purely logical sense.

Offline mdwh2

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 565
    • Show only replies by mdwh2
Re: Wouldn't it be nice if...
« Reply #15 on: September 19, 2003, 11:18:34 PM »
I think that having more choice is always a good thing, and an API that is available across various "Amiga" platforms is particularly good.

Though having said that, bearing in mind that MUI is available on OS4 and MorphOS, and AROS via Zune, I'm not sure that this idea would offer anything particularly new. It would be good for programmers who dislike MUI either from an API point of view (though this assumes that the new API is an improvement), or from the point of view of MUI itself.

Quote

Karlos wrote:
but think of the advantage to the common middle ground programmer who wants to write applications quickly, without having to choose one over the other (MUI in particular is not everybodies cup of tea).
I don't understand this point though. This doesn't make the choice any easier - since this new toolkit itself is a choice. The programmer still has to decide between MUI, Gadtools, Reaction, and this new API. As I say, having extra choice is good, but it's not like this new library would be the obvious best choice.
 

Offline whoosh777

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 114
    • Show only replies by whoosh777
    • http://www.whoosh777.pwp.blueyonder.co.uk
Re: Wouldn
« Reply #16 on: September 20, 2003, 01:12:48 AM »

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

 

Offline iamaboringperson

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 5744
    • Show only replies by iamaboringperson
Re: Wouldn
« Reply #17 on: September 20, 2003, 03:08:24 AM »
@whoosh777

(A bit OT)
Quote
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?
Okay, so you don't like GUI's, I can understand that.
However there are many users who will only use a computer that has a GUI. To many a GUI is what makes a computer easy to use.
You don't have to like it, just respect those who prefer a GUI.

Quote
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).
Sure! It's true that GUI's make portability worse. I accept that. But they provide so much more to the end user who doesn't care to learn about command line usage.
Quote
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.
I don't know of anybody here who thinks that programs that don't have a GUI aren't 'proper'.
They are just more accessable.
Quote
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),
There are two main problems with programming for 1.2 Intuition:
1. It is so much more difficult to write. GadTools made things easier. BOOPSI/ReAction(ClassAct)/MUI make it easier still. There is less programming to be done, which means more time to spend on the important bits (the background)
2. User acceptance. It's great that you have this really neat program that works from the shell and is highly portable. However there are many out there who only care for software that -  as they see it - they can use. That means a nice big pretty GUI.
Quote
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,
Sure. Same here. I want a program that does the job properly. But I migh also want an easy to use GUI. And the vast majority of computer users out there do want a GUI.

Quote
Regarding a GUI for entering parameters
I am quite happy just to enter the data into
a text file via Memacs TBH.
Great. So do that. Just respect the fact that there are other people out there who have more to do with their time than to edit text files all day, and learn the syntax for each new program.

Quote
Equally good for me would be a shell-run questions and
answers prog, like they used to use in the pre-GUI era.
That is so slow, and there is so much typing involved. Also, it isn't very real time. It just doesn't appeal to the average computer user, including myself.
Quote
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
You need to under stand that the GUI system offers the user alot more than just 'asynchronicity'. And it is possible for MUI based programs to spawn new threads anyway. It's up to the programmer.


This is off-topic anyway, and it might be an idea if you were to start a whole new thread about the issue of GUI V's CLI.
 

Offline iamaboringperson

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 5744
    • Show only replies by iamaboringperson
Re: Wouldn't it be nice if...
« Reply #18 on: September 20, 2003, 03:12:32 AM »
Quote

bloodline wrote:
I would agree with Kronos, that since Zune and MUI are avaiable for all three systems (and given the maturity of the MUI sysetm, and the freeness of Zune), it makes sense to target that, over Reaction, in a purely logical sense.
Sounds good. However I would like to see more options for the end user.

It would be nice to get this GUI abstraction library happening so that there are fewer problems for the end user who doesn't know which GUI system they want.
Or for the user who wants to use ReAction but can only find MUI apps.

I prefer ReAction, and I think it would be great if I could just write a program once using this GUI abstraction system and either compile two versions of it(or more) or just the one version of the program which will use MUI or ReAction or any other GUI system that the user prefers.

It's all about choice!
 

Offline iamaboringperson

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 5744
    • Show only replies by iamaboringperson
Re: Wouldn't it be nice if...
« Reply #19 on: September 20, 2003, 03:15:57 AM »
I think one great way to start this project would be to find just one or two types of gadgets(or whatever), and then write an abstraction library for it, and see how successful we are with just the one.

Then it can be expanded to all other gadgets, etc. one by one.

:-)
 

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: Wouldn't it be nice if...
« Reply #20 on: September 20, 2003, 11:43:28 AM »
@Ima...

To hell with the nay sayers :lol: I'm actually considering the deployment details of it already ;-)

I don't expect to have a great deal of time to work on it however :-(
int p; // A
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Wouldn't it be nice if...
« Reply #21 on: September 20, 2003, 12:03:05 PM »
I would like to point out that part of the goal of Zune is to port it to Linux... Although that has be side lined for the time being so as to get it fully functional and fully integrated into AROS.

Anyway, if Zune is ported to Linux... then your MUI apps can be ported to any UNIX... and possibly to a Winbox too!!!

Offline bhoggett

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1431
    • Show only replies by bhoggett
    • http://www.midnightmu.com
Re: Wouldn
« Reply #22 on: September 20, 2003, 01:38:19 PM »
@whoosh777

Nope, sorry, I don't really agree.

I would say that GUI interfaces should be separate add-ons to most applications, rather than built-in, but otherwise keyboard-only driven apps have limited appeal.

If a user needs days of intensive training before he can use an app, or he needs a crib-sheet in front of him telling him what convoluted key combinations give him access to basic program features, then the interface is rubbish and of no interest to ordinary users.

Keyboard control should be an option, not a requirement. So should a GUI wherever possible, as experinced operators will find keyboard operation more efficient than a mouse controlled one.
Bill Hoggett
 

Offline iamaboringperson

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 5744
    • Show only replies by iamaboringperson
Re: Wouldn't it be nice if...
« Reply #23 on: September 20, 2003, 07:52:24 PM »
@bloodline

That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)
 

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: Wouldn't it be nice if...
« Reply #24 on: September 20, 2003, 09:26:55 PM »
Quote

iamaboringperson wrote:
@bloodline

That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)


Also, people like myself who actually like reaction but would like to support MUI also.
int p; // A
 

Offline jaokim

  • Full Member
  • ***
  • Join Date: Jun 2002
  • Posts: 205
    • Show only replies by jaokim
Re: Wouldn't it be nice if...
« Reply #25 on: September 20, 2003, 11:50:49 PM »
Well, isn't the thing we need some sort of graphical development tool alá Delphi or Visual#?, in which you can chose to make it MUI/Zune/ReAction-compatible.

Otherwise I'm very pro the idea. Maybe trying to simplify the development with easy to use classes? I tried MUI and ReAction (no, sorry that's ClassAct) and actually didn't like either of them. I used Gadtools which was fairly simple (maybe because I had excellent tutorials) to use and understand.

I dont know if you mean doing a new .library (oh no, not another GUI-engine) or just something like opengui.h with functions. The latter option would be my bet, you could just compile the source and then link it with the appropriate openguiMUI/ReAct.o-file.
 

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: Wouldn't it be nice if...
« Reply #26 on: September 21, 2003, 01:12:59 AM »
@jaokim

The basic idea is to provide an API that is simply a common interface to the overlapping features of different GUIs (in this case MUI / Reaction). The interface I'm thinking of will be implemented in a C (and C++ via wrapper classes perhaps) style compliant way without the orgy of macros, boopsi style method calls etc.

The idea is that you include only this header (not anything for MUI or Reaction) and use only this interface for your applicaton.

There are two realistic alternatives for this

1) A statically linked library that you build into your project. It uses conditional compilation to generate the appropriate code for each system.

+ easy to implement and test
- underlying GUI developer materials are required
- GUI becomes 'hard coded' into application
- Impossible for end user to choose gui

2) A shared library that you open and it itself delegates to the underlying GUI

- trickier to implement
- Common API library plus GUI specific sub libraries may be required
+ equivalent shared libraries can be created for various GUIs
+ possible for end user to use alternative GUIs (which library to use could be an env var etc)
+ Original GUI developer resources are not required to develop with library.

As you can probably tell, I'm inclined to go for option 2...
int p; // A
 

Offline iamaboringperson

  • Hero Member
  • *****
  • Join Date: Jun 2002
  • Posts: 5744
    • Show only replies by iamaboringperson
Re: Wouldn't it be nice if...
« Reply #27 on: September 21, 2003, 04:13:08 AM »
I think this project would be great if written with "Borland C++ Builder"/ "Visual Basic" style development tools in mind.

This would be esspecialy good if done in C++

I think when designing this GUI builder programs should be considered
 

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: Wouldn't it be nice if...
« Reply #28 on: September 21, 2003, 12:14:38 PM »
-edited-

@Ima - sorry didn't parse youre last sentence correctly (expected ',' found 'GUI') :-P

For a minute I misinterpreted you as saying:

"I think when designing this GUI, builder programs should be considered"

I was about to say "What GUI? I'm not writing a GUI...."

To address your point, if we had a single GUI builder program that catered for both reaction and mui, there may not be any point in this API anyway other than for runtime compatibility...

Dont get too carried away with C++. The API should cater for both, not everybody is a C++ fan and the amiga shared library system isn't exactly ideal for C++ code.

For C++ support, a seperate header that exposes the API interface through wrapper classes is about as good as it will get. This will also probably incur a small linker library too.
int p; // A
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Wouldn't it be nice if...
« Reply #29 from previous page: September 21, 2003, 12:43:56 PM »
Quote

iamaboringperson wrote:
@bloodline

That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)


-Edit- Generalised my statment.

Then I think one should be asking oneself, why one would hate MUI...?  :-D