AmigaOS DevContest kicks off!

[Slash]

You develop on 3.9, then port and RELEASE on os4.0. In this way you can take part in the contest.

Then again, you forgot two simple things I stated before:

1) os3.9 and os4.0 APIs are quite similar. Os4.0 has some enhancements yes, but these doesn't broke retrocompatibility. It's somewhat like to port from linux 2.0 on i386 to linux 2.4 on i686.

2) many member of the grand jury of the contest have one (or more) A1 available and they're more than willing to help the contestants bugfixing their software before the deadline. So, the contestants do have that machine under the desk.

So, let me rephrase your statement: it is possible to work without easy access to the platform you're developing for. It's an Amiga, not your average PC.

Sorry, but it's not quite that simple. Believe me, I tried, it didn't work, so I bought an A1. Now, I haven't been working as hard on my project as I could have been but the porting of my old 3.9 code to 4.0 code is still in progress after 3 weeks, I've only skimmed the surface of the specific OS4 features.

Compiling a binary for OS4 is one thing, as Lando states, but then what... you give it to someone to test, it crashes, they tell you what and where, send you the Reaper Log, you send a new executable back which is possibly fixed, doesn't work... the circle continues. It is possible, but it's a pain in the backside!

Just because the APIs are 'similar' doesn't mean its just a matter of typing MAKE on OS4 with your 3.9 source code, it simply won't work. You could stuff a lot of #ifdef __amigaos_4__ in there I suppose.

Besides, if it's got to use ReAction how do you test that with a 3.9 app (ClassAct is not a solution here)? And use the OS4 specific features you're meant to be using as stated in the rules, application.library, AmiDock etc etc. Anyway, I'm a big fan of MUI and as it's in a native OS4 form now, I don't see why it should be banned.

I'm ranting... I'm off :-P

[itix]

@batman

I find this competition idea very good, but

1) os3.9 and os4.0 APIs are quite similar. Os4.0 has some enhancements yes, but these doesn't broke retrocompatibility. It's somewhat like to port from linux 2.0 on i386 to linux 2.4 on i686.

You are missing the point. OS 4.0 PPC API implements OS 3.0 API (except some OldOpenLibrary(), TaggedOpenLibrary() etc.) but there are also new API calls which are not available in 3.9. That is what makes this competition problematic (IMO + standard disclaimers here).

Cross compiling itself is not problem. Even StormC (the one that supports PPC ELFs) can generate OS4 compatible binaries if you know what you are doing.

[Linchpin]

Sounds pretty cool to me! Now to learn how to code ....


:roll:

[Batman]

Anyway, I'm a big fan of MUI and as it's in a native OS4 form now, I don't see why it should be banned.

two reasons for the ban:

1) stuntz almost screwed MOS with his greediness. Reaction (by the way, it is the sequel of ClassAct) doesn't have this problem because its creator gave all the copyrights to the AmigaOS IP owner long ago (and he still maintain it).

2) as fluffy mcdeath said before, the main problem with MUI "is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc. The lack of centralized ownership makes maintenance and installing a pain in the arse."

[Batman]

You are missing the point. OS 4.0 PPC API implements OS 3.0 API (except some OldOpenLibrary(), TaggedOpenLibrary() etc.) but there are also new API calls which are not available in 3.9. That is what makes this competition problematic (IMO + standard disclaimers here).

Maybe I'm missing the point here, but I had the possibility to give a rapid look to the SDK and I found that code suited for 68k could run without any problem and using only OS3.0 API (if well coded, of course).

The only differences are the way developers have to interact with gnu compilers and the new (compulsory) method for automagically opening and closing libraries and interfaces introduced with OS4.0.

[rayt]

Yeah mui should be released under gpl just as the did with ambient..

[KennyR]

Batman wrote:

1) stuntz almost screwed MOS with his greediness.

That's a very unfair statement

Stefan Stunz, like everyone else, wants paid for hard work, and he has done a lot. If he was greedy, he'd have left this tiny community a long, long time ago.

2) as fluffy mcdeath said before, the main problem with MUI "is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc.

That's not even an argument - who doesn't distribute the class with their app? Maintaining MUI classes isn't what it used to be, especially with MUI 3.9 (never, ever had a problem with it). And what is it exactly that stops people releasing 3rd party ReAction classes you need to track down and install? Both ReAction and MUI and modular, and so have absolutely the same weaknesses in being modular.

One difference though - MUI is a lot easier for people to develop for. If you want more devs for OS4, you should be making it easy for them, not dragging them down into dogma that wouldn't have been out of place on a 1998 UseNet MUI vs. ClassAct flamewar and making it harder.

[Slash]

The only differences are the way developers have to interact with gnu compilers and the new (compulsory) method for automagically opening and closing libraries and interfaces introduced with OS4.0.

Not true, but if you believe you're right then I'm not going to continue arguing with you :-)

[itix]

Maybe I'm missing the point here, but I had the possibility to give a rapid look to the SDK and I found that code suited for 68k could run without any problem and using only OS3.0 API (if well coded, of course).

Depends how it is coded. If you use mainly ANSI C functions there are less problems. But it is still possible to write code that compiles perfectly for 68k but goes wrong for PPC target (68k varargs...).

Even hooks can cause headache. In older OS4 kernel versions you had to use 68k stub to get working PPC dispatcher for MUI (this was fixed later, i dont know what was issue), how one is expected to sort them out without proper test environment? What if you made a typo and you call GetInterface() by wrong name? When testing on OS3 you cant spot these things and GetInterface() calls wont show up in SnoopDos either. There are just many issues... Everyone is free to try and do what he wants, though.

[Kronos]

Bout MUI:

MUI does exist in a useable and free form for all major "Amigas", you may not allways be able to use the setting in the unregged version, but thats all there is.

This version wouldn't disappear even if Stunzi decides on a drama-tantrum, it's native and new apps can be coded for till the sun make BOOOM.

In such a case you would have 2 kinds of SW:
1) things that aren't developed anymore, those also don't need a newer version of MUI.

2) things that are still developed, those could be reworked (with relativ ease) to one of the MUI-clones (Zune or even Feelin).

ReAction on the other side is only available for OS4 and (in an allredy moothballed version) 68k. There also next to no chance that the ReAction-API would survive the introducion of real MP without changes. You can just forget about binary-compability in that case.

All in all I would say that the future of ReAction is atleast as uncertain as of MUI, and that doesn't even take into account that most active&productive coders detest it.

MUI-classes also don't have to be a problem, just write:


- all used classes must be native and distributed with the main archive (unless found on OS4-CD).

- add blacklist for problematic classes here

[Batman]

    Batman wrote:

    1) stuntz almost screwed MOS with his greediness.

That's a very unfair statement

I don't think that was unfair, if you view those event from a MOS user point of view...

That's not even an argument - who doesn't distribute the class with their app?

Many 68k apps still relies on two well known and freely available MUI custom classes. The developers assumed their user already installed them, and it's a very very bad of coding, IMHO.

Maintaining MUI classes isn't what it used to be, especially with MUI 3.9 (never, ever had a problem with it).

I don't have MUI 3.9, so I cannot express my opinion. Can you explain the improvement in maintaining MUI classes apart from the necessary mental re-education (in siberian camps hopefully) of developers not used to check for custom classes during install/load phase?

And what is it exactly that stops people releasing 3rd party ReAction classes you need to track down and install? Both ReAction and MUI and modular, and so have absolutely the same weaknesses in being modular.

One difference though - MUI is a lot easier for people to develop for. If you want more devs for OS4, you should be making it easy for them, not dragging them down into dogma that wouldn't have been out of place on a 1998 UseNet MUI vs. ClassAct flamewar and making it harder.

Maybe you're right. But some time ago I discussed about one of ReAction developer about improvement in the upcoming release, and I realized that what REALLY differentiates ReAction from MUI is not the easeness of use, but the documentation and support provided for it: MUI has better one.

[Cymric]

The entire MUI vs. Reaction discussion is quite pointless: the end result is the same. To my knowledge Reaction is not available for older platforms, so if you want to develop your application, you'll need an AOne to begin with. That makes the prize a little weird to say the least. In fact, the jury writes: " ...  First, if your app runs in 68k with no Enforcer hits, there is great chance that it runs on OS4, it's a start. Then, you can make a public call to ask help from OS4 owners to betatest for you, or even to code with you. We are a community. Work together. ..." Yeah. Right. Excuse me while I laugh. This coding by proxy is a nightmare. No machine, no development. Period. Especially when you consider the second problem I have with this contest:

It stresses uniqueness and usefulness to an uncomfortable degree. The jury does not want 'another simple utility', or 'seen-many-times software'. Pray tell, what can one think of which hasn't been done on other platforms numerous times already? I understand that the jury wants high quality programs, which is perfectly understandable. But unique programs take a long time to develop, if only because of their feature lists. I also fear the jury has fallen into the trap of thinking that an Amiga is somehow special, that somehow pixies will magic away the fact that it is running stock standard hardware.

Of course anyone has the right to lay down sets of rules for contests. But I agree with other people in this thread that the limitations will harm the contest more than result in Good Stuff. At this point I would be thrilled with any new application for OS4, rather than expecting people to create killer apps straight away.

My two eurocents.

[Rogue]

Even hooks can cause headache. In older OS4 kernel versions you had to use 68k stub to get working PPC dispatcher for MUI (this was fixed later, i dont know what was issue)

The issue where hooks that where called directly, not via Utility/CallHookPkt. If this stayed within the 68k emulator, it wasn't a problem, but if the custom class was PPC native and the call was made by a 68k program then this wouldn't work. It has been fixed in the meantime.

About MUI, I didn't make the rules (in fact Hyperion has nothing to do with the contest), but plainly there are three major complaints I have with MUI (which can all be circumvented but mostly aren't):

- Rendering done on App context means that if the app is busy it will not "visually" react to input, unless the app is multithreaded (OTOH it will not crash input.device on a buggy class).

- Due to MUI's configurability, some apps look crap unless you use the same configuration as the author. Discipline is required on the authors behalf to at least test the app with the default MUI config.

- Due to the myriad of different custom classes and the fact that lots of functionality is duplicated, it is sometimes difficult to keep up-to-date with an application's requirements for custom class versions. MUI could use some sort of automatic update server that keeps all classes available (say, via Aminet) and automatically installs missing classes.

But if I start a program and the first thing I need is to install half a dozend custom classes, I quickly loose interest.

[itix]

- Due to the myriad of different custom classes and the fact that lots of functionality is duplicated, it is sometimes difficult to keep up-to-date with an application's requirements for custom class versions.

That is quite much due to lack of new MUI releases during past years. Since list.mui was not advancing nlist.mcc was made. Then came betterstring (and newstring + textinput), betterbalance, nlisttree (listtree.mcc author disappeared) and dozen crappy toolbar classes. But MUI 3.9 added many new features and more is coming.

There are also many MUI custom classes because MUI is simply popular.

[lempkee]

mui...popular...  ok if u say so.

i used and still use MUI because i must.

i know mui is easier to develop for and much more powerfull in certain sections but reaction can get there in time.

Anyway i must admit that mui has gone from dog slow to superfast in the 68k -> ppc step and for that im not complaining at all.

So much better to use a standarized gui system than the likes of mui as if you guys actually tried to do a professional skin for all your apps or whatever that use mui...well then you guys would see that one cant get every app to look the same and thats bad.

[Rogue]

That is quite much due to lack of new MUI releases during past years. Since list.mui was not advancing nlist.mcc was made. Then came betterstring (and newstring + textinput), betterbalance, nlisttree (listtree.mcc author disappeared) and dozen crappy toolbar classes. But MUI 3.9 added many new features and more is coming.

That doesn't help the problem, though. Yes, there is always a problem when there is no central steering committee, and yes, MUI 3.9 added more features, it still doesn't cure the big issue though that you always have to download a heap of custom classes to actually get something to run, and hope that interdependencies don't kill you.

There are also many MUI custom classes because MUI is simply popular.

This also doesn't invalidate my original point.

And there is still the other issues. Granted, well-done applications like e.g. IBrowse do not suffer from the "identical config as the author" problem, but many of them do.

And I am not saying Reaction is superior or more powerful or anything like that.