The way to fix 'openamiga'...

[iamaboringperson]

 :-)
Hi, everybody!

@Karlos:
I agree with this. MUI is not being developed outside of AROS and MOS. Hyperion are providing it as a "crippled shareware" version only so that people can run their older stuff; they would rather ppl use Reaction on new programs. The AROS/MOS crowd have spent way too much time and energy to give up on their effort, so I believe that the only way for the largest number of people to be able to use any given program is if that program has been written to use some sort of GUI abstraction layer. The user would decide what GUI toolkit to use, not the coder. If this abstraction layer happens to be one of the Linux APIs like Qt, wxWindows or GTK, so much the better; it will make porting many Linux programs a lot easier, and also help attract Linux coders because they won't need to learn yet another GUI API.

This is something that is definitely needed, but it's too big for a weekend coder. We need a determined team who has the respect and credibility of all three sides (AROS, MOS and Hyperion), because they will need to work closely with all three. In my opinion this project is a lot more important than getting an office suite, because we need anything and everything that will prevent people from thinking that writing programs for the Amiga is too much of a hassle. What good is an office suite if that's the only program you have?

@The OpenAmiga crew: if you're looking for a good cause to back, consider backing this one!

i quite agree!
a good standard called BOOPSI came out with 2.x
this is very a very good start for a gui toolkit, i believe reaction is based on this
a good use of the opensource model would be to produce a range of (opensource) gadgets/images that are compatable with all the common BOOPSI gadgets(which might include reaction ones)
just simple boopsi classes at first, then various authors can write new ones that are 100% source compatable, but have all the customization features in the world
and a standardized OOP C++ set of libraries could be added(and that

a problem with chosing MUI, and (AFAIK) AHI, and some of those others, especialy cybergraphics, is that if this is ment to be for opensource/non propritety OS's as well,
since not every OS out there can get cybergraphics for it, and AmigaOS 4.0 is ment to come with Piccaso anyway
there need to be other abstraction models
and a way to write software that will work on more than just cybergraphics.library

IMHO listing a whole bunch of apps aint going to help!

and more people/groups need to be involved

[iamaboringperson]

8bit bitplane modes are DEAD !! No one sensible codes SW anymore that needs them, and
since Openamiga is more targeted at "modern" Amiga I would even say noone really uses them anymore.

i wouldnt say that
for backwards compatability with OS3.1 graphics.library, 8 bit support is needed, and doesnt cause much harm
all gui's support 8-bit for some very good reasons

even if the 8-bit functions were used as an indirect way to call the hi/true color functions
or perhaps even if implemented as macros in the includes

i know its nice to have all modern tech. and no legacy stuff, but 8-bit color is still usefull

[iamaboringperson]

OT: I had sex with my wife to be last night you boring twat. you have a nice wank loser?

i never ment the intro. to sound so negative, nor to get people upset
but if this is your attitude, ill leave it with you and/or you psychologist to deal with
no use me flaming back, with more irrelevant nonsense

i would rather talk about the technical side of things i.e. programming

[iamaboringperson]

If the flamefest continues, I'll lock the thread. Try to be just a little more mature guys. These forums are not a vent for raging testosterone.

so what made you lock the thread??

all i saw was one flame, and it was pretty harmles IMO

 :-)

[Kronos]

Seems you still don't understand ....

1) Cypergraphics:
MorphOS has it (DUH)
OS4 has it (CGX-emu found in P96).
AROS has a dummy lib which redirects/implements those function on their gfx.lib.

2)MUI:
MorphOS hast (DUH again)
OS4 has it (the unreg version is fully useable, you just can't change the look).
AROS has it in the form of Zune (which could also be used on OS4/MOS).

3)Boopsi/ReAction:
Would mean lot of reinventing the whell for something that is still inferior to MUI.

Want a opensource GUI-kit ? Use Zune !

3)8Bit:
Openamiga is aimed at NEW SW, and full compabilty with the old gfx.lib would only be
needed when someone would insist on usig planar modes, or is poking directly into
structures. Both are big NONOs for modern Amiga-SW, and that why there is more
harm than good in putting those into the openamiga-definition.

[mikeymike]

@ iamaboringperson

so what made you lock the thread??
all i saw was one flame, and it was pretty harmles IMO

After I made my first comment, someone replied again in a way that could only help to continue the flamefest.  I deleted their post and then locked the thread.  I would appreciate it if you didn't do things that might continue the flamefest on another thread (ie. quoting flame comments from previous thread).

iamaboringperson wrote:

OT: I had sex with my wife to be last night you boring twat. you have a nice wank loser?

i never ment the intro. to sound so negative, nor to get people upset
but if this is your attitude, ill leave it with you and/or you psychologist to deal with
no use me flaming back, with more irrelevant nonsense

i would rather talk about the technical side of things i.e. programming

I'd rather do the actual programming as opposed to talking about it.  Do you want to help?

[whoosh777]

I dont care about GUIs, whether one is present or absent
makes no difference to me, what matters is what the
actual prog does.

I have 3 very useful progs:

1. gcc

No GUI, probably *the* most useful prog in the universe,

I dont like it but its very useful, without it there would

be no OS4 for instance.

because it has no GUI it is very very portable,

in fact it is the most portable prog in the universe,

so portable it can even port itself!

Name me one other prog that can do that?

You can port unix, Linux, OS4 with it, not bad for a GUI free prog.

2. make,

this is  a unix prog, vital for ports, no GUI, good!

without it its a p.i.t.a to port things though some people

have managed without it.


3. Memacs:

very good text editor, the unix version of this is even better

gnu-emacs: even has a built in language emacs-lisp, so you can

write customised clever functions.


The Amiga version has a menu, but I find keyboard short cuts

much faster:

search and replace? ESC-q
search ?  control-s
insert file ?  control-x control-i

and so on. By the time you have located the menu command I could have done

5 keyboard commands.

The only GUI thing I miss on Memacs is an input-file-requester, I've heard

there is an Amiga port of gnu-emacs that has this and that it was done

with asl.library.



What I really cant stand are progs that have wonderful GUI's and
do sod all.

nice GUI shame about the features!

I would rather have nice features but shame about the GUI.


If I were to use GUIs myself I think I would write my own one,

that way I would ensure portability. If you use an external one

then the problem is that 5 years down the line everyone will

have abandoned that path, and you will be stuck with complicated

+ interesting + unusable source code.




People complain about progs that use their own GUI,

I say smart move! Your prog will port everywhere.




People keep sobbing for standardisation of interface,

I have no sympathy for you!:


the "standardised approach" of today is in a rubbish dump tomorrow.

I remember once writing some shareware prog, and someone

criticised my docs saying they should be more standardised,

they should be in amigaguide. Well amigaguide wonderful though it is

 never took off.


OS2.0 with its gray wb was someones bright idea of standardisation,

standardisation is so mind numbingly boring. Please dont ask for this,

who is going to standardise, what qualifies them to do it,

please dont even think about it. Standardise the OS by all means

but not the interface.




One cross platform portable GUI mechanism that exists is HTML,

eg this website, perhaps people who want a portable GUI should

use that?  not sure how you would incorporate it into a prog,

maybe create a browser-compiler: input html output binary code??

:do this by customising an existing browser.




Regarding 8 bit planes, bit planes in general were a bad concept

they are slow to read, slow to write and probably slow from a

h/w POV: the video hardware has to read from eg 8 different

locations (1 for each bitplane) so its inefficient eg from a

memory caching POV. So all round bitplanes were stupid.




However if you have an AGA only machine like mine then thats the

only option.


Its a good idea though to try to create your own

abstraction layer and work through that.



Byte per pixel, or byte per component is a much better approach

in every way. Byte per pixel eg for grayscale has the advantage

of tripling the data rate eg frame rate. Its also 3 times as fast

to render + read, problem is its in gray.



:I think using any OS directly is a dangerous move.

One day even Windows will be in a glass case in a museum:

Bill Gates must one day retire, without him MS will disintegrate!

Windows==Bill Gates, its like Virgin==Richard Branson.


When these bosses retire their companies will disintegrate.


Alongside Windows in the museum will be Linux in another case,

the caption will read "early man OS's".


Windows is also based on deliberate impermanence, they deliberately

keep moving the goalposts to force everyone to keep buying.




Its best to put a private abstraction layer between your prog and the

external OS:

prog ---- OS-abstraction ----- actual OS

That way to port your progs reduces to porting the abstraction layer.

So regarding GUI's you just need your own private GUI abstraction.

You dont actually need to abstract the GUI, but just abstract the

function of the GUI.

eg the abstraction of an input-string-gadget in C might even be

char *input_string(void) ;

or something.



Remember the GUI should be 1% of your prog, 99% of a prog should be

actually doing things: non visible, lots of data movement + processing.


For many progs a GUI is purely there to input data:
this data may be boolean (click on gadget),
string (eg file name), or number (eg no. of iterations),
its not a big deal.

Obviously GUIs are more central for graphics progs where the prog has to

track the mouse, but there are so many progs other than art progs.

BTW what exactly is the prog you want the GUI for?

then we can have some "context" for discussing the GUI problem.


whoosh777

[iamaboringperson]

mdma

I'd rather do the actual programming as opposed to talking about it. Do you want to help?

id like to help(without being abused), however if its about listing programs, id say there is not much more that needs to be done,

if its about creating specifications for libraries and ABI's etc... i would certainly like to help
but what should be posted on the site, for now are the types of executable/ABI's that each OS(AOS/MOS/AROS)uses, that would be very helpful

and as somebody else suggested, an OOP GUI abstraction library, to help with better portability between GUI systems, so that each OS or user may chose their own GUI and programs will still be easily portable
that idea to get QT stuff from other platforms ported sounds good... if its possible

[iamaboringperson]

whoosh777

GCC i dont care so much for, but its a matter of personal choice IMO
i would probably prefer a comercial compiler, and including GCC as standard would only discourage other third party compiler producers - OK for AROS, probably not for AOS/MOS but thats just my opinion

MEMACS definintly should be made standard :-P

[downix]

and as somebody else suggested, an OOP GUI abstraction library, to help with better portability between GUI systems, so that each OS or user may chose their own GUI and programs will still be easily portable
that idea to get QT stuff from other platforms ported sounds good... if its possible

The problem with this is that you would then be reinventing the wheel when such an OOP GUI library already exists for all of the platforms:  MUI.

Some folk will go "MUI is commercial, can't use that" and forget about Zune, which could be ported to AOS4 simply, to replace the shareware MUI with a fully compatable replacement.  (MOS comes with the full MUI already, so that is not an issue)

And no, ReAction is not based on BOOPSI, but on ClassAct.

But the idea behind OpenAmiga was to create specifications.  What is there now is a preliminary list only.  Want to define more, or work out more, then join in!

[KennyR]

I hate GCC too. It's bloated, takes aaaaages to compile, and doesn't produce the best code. Not to mention that it's a total pain in the ass to install. I'd rather use SAS/C any day.

That said, GCC is unique in that it's the most compatible compiler. It'll work for all systems and produce any kind of file you want, ELF, EHF, whatever. It also makes porting *ix apps quick and easy. It's the perfect choice of a standard.

[Kronos]

Remember the GUI should be 1% of your prog, 99% of a prog should be

actually doing things: non visible, lots of data movement + processing.

Sorry, but that is BS  :-o  :-o  SW is for doing things easier than doing them by hand.

This means that every SW needs an usable and understandable UI, and for most things
that make use of todays CPUs a graphical UI is the best solution.

Thise GUI has to offer the user all functions of the SW and have some safenet for false input.

It also needs to be easy to use, which can't be reached when every apps uses
different methods to reach the same goal. Thats why there should be a limited number
of GUI-kits for any OS, and that why there should be some basic style-guide in place.

[Karlos]

downix wrote:
The problem with this is that you would then be reinventing the wheel when such an OOP GUI library already exists for all of the platforms:  MUI.

I agree that MUI is fine as it stands but I feel you are missing our point here.

An abstraction layer has many benefits. For MUI and reaction both, such a layer would be very thin.

Enforcing MUI as an interface is not a good idea - plenty of people don't like it, it may not be ideal under one or other versions of the OS (ie OS4).

Having to use MUI or Zune on a system which already has GUI results in an underutilisation of that systems existing abilites and increases the memory overhead of the program (having to load MUI resources etc). Reinventing the wheel as you yourself describe it :-)

By contrast the abstraction layer would be relatively small since it relies on the underlying native GUI to do all the work.

One overwhelming advantage, as codesmith pointed out would be to use an API which is source compatible with one of the Linux APIs which would reduce the work required to port software.

I feel this idea has a lot of potential, but that's my humble opinion :-)

[iamaboringperson]

Karlos, i agree...

it would be especially nice with C++ interfaces for all of these

more choice of GUI for the programmer... the OS developer... and the end user...

plus it would be easier and more like other platforms(like borland c++ builder) to develop on

what i would really like is a dev. system like borland C++ builder
that would really help software development on the amiga
just do long as it is MUI/gadtools/reaction independant