Zune for all platforms

[HenryCase]

The problem is that Zune tries to be a MUI clone, meaning it replaces MUI's libraries, classes, etc. with its own and you can't normally run multiple versions of amiga shared libs, GUI classes, etc. at the same time for compatibility with specific app version dependencies (where binary app X needs version Y but breaks with version Y+1 and higher.)

So you're saying that the MorphOS developers made no allowances for having multiple versions of MUI running concurrently alongside each other? I find it hard to believe that the MorphOS devs would voluntarily give themselves such a limitation. Are you saying not even applying Zune as a set of statically-linked libraries is possible?

At any rate, improving Zune will still make porting between Amiga platforms easier, so nothing of value is lost.

A workable morphos version of zune would basically install nothing to  some little bit for zune internals that practically nobody really uses,  because they prefer to use the already port-ably defined MUI functions.

Which version of MUI is available on all platforms?

I think it was kind of silly to update the Zune bounty without a volunteering developer to steer it towards what they thought they could and would do.

Read this thread and you'll see we did have developers guiding the new bounty:
http://aros-exec.org/modules/newbb/viewtopic.php?start=0&topic_id=6301&viewmode=flat&order=ASC&type=&mode=0

[Daedalus]

The problem is that Zune tries to be a MUI clone, meaning it replaces MUI's libraries, classes, etc. with its own and you can't normally run multiple versions of amiga shared libs, GUI classes, etc. at the same time for compatibility with specific app version dependencies (where binary app X needs version Y but breaks with version Y+1 and higher.)

A workable morphos version of zune would basically install nothing to  some little bit for zune internals that practically nobody really uses,  because they prefer to use the already port-ably defined MUI functions.

This is what I was saying about maybe a Zune API with something like _zune_ prefix, so instead of opening mui.library or BetterString.mcc, you open _zune_mui.library or _zune_BetterString.mcc. Surely a simple prefix like that could be implemented as a compiler directive in a modified compiler, and so would require a minimum of porting effort. The _zune_ libraries could then either pass through to the relevant real MUI library, or implement their own routines if incompatible.

This would also allow it to run on OS4, just in case there are issues with the modified MUI3.9 included in Update 3...

[HenryCase]

@Daedalus
Surely it's much simpler than that though.

When you write a program using MUI, you need to reference the MUI header file(s). As long as the Zune header files are named differently, it doesn't matter that the functions contained within them are named the same as their MUI equivalents, as the compiler will link to the functions you intended to use.

Perhaps the view that MUI and Zune cannot co-exist is being put forward by non-coders?

@all
We're allowing this thread to be derailed, the bounty is the main topic, please help us drive Zune forward for the benefit of all the Amiga community:
http://www.power2people.org/projects/profile/61
Thanks.

[SamuraiCrow]

I think the point is, that opening "muimaster.library" will point to MUI on a MorphOS machine and Zune will be unnecessary.  You'd have to rename the library so it would be incompatible with MUI apps everywhere expecting to open "muimaster.library".  In short, the best solutuion would be to make Zune compatible with MUI for all AROS flavors and OS 3 since there's no point in registerring Zune, and OS 4 could use a future Zune that is compatible with MorphOS' MUI versions.

BTW, I'd appreciate some help with MUI Builder some time.  I have little experience coding GUIs and would like to add support for the NList family of MUI Custom Classes.

[jacadcaps]

@Daedalus
Surely it's much simpler than that though.

When you write a program using MUI, you need to reference the MUI header file(s). As long as the Zune header files are named differently, it doesn't matter that the functions contained within them are named the same as their MUI equivalents, as the compiler will link to the functions you intended to use.

Perhaps the view that MUI and Zune cannot co-exist is being put forward by non-coders?

While you could prepare a Zune that'd run alongside MUI on MorphOS, you would indeed need to compile all apps for it with modified headers so that all classes would use a different name (a prefix, like some "non-coder" here suggested could work, but not in the compiler but in headers obviously This of course means that you cannot compile a single binary that'd run using Zune or MUI depending on what's installed. You cannot replace MUI with Zune on MorphOS because MorphOS (for instance, intuition.library) relies on its internals heavily (structures, private methods, attributes, etc). Since those methods are, well, private, they wouldn't be available in Zune. And what would be the point of having two libraries alongside doing virtually the same (but Zune doing obviously less than MUI 4.0 and being poorly integrated)?

[jacadcaps]

So you're saying that the MorphOS developers made no allowances for having multiple versions of MUI running concurrently alongside each other? I find it hard to believe that the MorphOS devs would voluntarily give themselves such a limitation. Are you saying not even applying Zune as a set of statically-linked libraries is possible?

I suggest you read up on the early AmigaOS design concepts like shared libraries and BOOPSI. Since MUI uses both, it obviously cannot run alongside another set of libs/classes unless they would all use a different name (say, a prefix). That'd also mean only programs compiled for the cloned one specifically would use the clone. What would be the point of this? Static linking is against the public class concept, you'd have to modify the client sources a lot in order to be able to use a statically linked Zune (for instance, all places where subclasses are initialized).

Which version of MUI is available on all platforms?

AmigaOS 3.x and 4.x have MUI 3.8/9, MorphOS is based on MUI 4 and won't work with anything older.

[OlafS3]

You would not program MUI-Applications but ZUNE-Applications. And it will not be used by everyone but by programmers who want to support different platforms without additional effort. It is a toolkit that is available on all platforms and compatible to MUI. Programmers who just want to support one platform are free to do that. On OS 3.x both (MUI and Zune) run on the same machine and why should that not be possible on other platforms?

[takemehomegrandma]

The Zune-project on power2people is splitted in several projects.

phase 1 is making it full compatible to MUI38.
http://www.power2people.org/projects/profile/61

In the next phase it will be ported to MorphOS and AmigaOS to have a common standard for applications.

Please donate and support the efforts.

What do you think? I hope for more common bounties to reduce the split in the community.

The "common standard" already is MUI, it will never be Zune. Current version is MUI4, which is an *integrated component* of MorphOS (an OS component required for MorphOS to run, older versions won't work). MUI4 sets the standard, the agenda, if you want a common denominator. On OS4 and AmigaOS, MUI 3.8/3.9 is available as add-on package/bundle. A lot of work has recently been put into bringing some MUI4 features into the OS4 version of MUI3.9, hence it's possible to port Fab's excellent web browser Odyssey, and also other MorphOS stuff, to OS4.

I think this is the path to go for AROS - aim for making Zune MUI4 compatible instead of expecting people to go back and satisfy with a MUI3.8 (i.e. MorphOS 1.0 IIRC) level API. There is a reason to why development goes *forward*, and that's because it brings a lot of new goodies to the table! And once you tastes the sweet's, there is no going back!

[jj]

I am obviously missing the point here, but what I meant and what has been clarified is that Zune in of no use on MorphOS.
 
Much more sense would be to implement MUI4( if thats possible) on AROS and AOS4 or to make ZUNE a compelte clone of MUI4 and replace MUI on AOS4 and AROS with Zune.
 
I can not see either of these things happening  to be honest.

[OlafS3]

i have a different view. When you want to support different platforms you need a reliable environment and not new features. Zune will not stop at this point and there is no reason not to improve it. Even if not everyone welcomes it now, it should be done and when it is really available everyone can decide if he takes it or not.

[jj]

Why re-invent the wheel for like the third of fourth time

[kamelito]

The "common standard" already is MUI, it will never be Zune. Current version is MUI4, which is an *integrated component* of MorphOS (an OS component required for MorphOS to run, older versions won't work). MUI4 sets the standard, the agenda, if you want a common denominator. On OS4 and AmigaOS, MUI 3.8/3.9 is available as add-on package/bundle. A lot of work has recently been put into bringing some MUI4 features into the OS4 version of MUI3.9, hence it's possible to port Fab's excellent web browser Odyssey, and also other MorphOS stuff, to OS4.

I think this is the path to go for AROS - aim for making Zune MUI4 compatible instead of expecting people to go back and satisfy with a MUI3.8 (i.e. MorphOS 1.0 IIRC) level API. There is a reason to why development goes *forward*, and that's because it brings a lot of new goodies to the table! And once you tastes the sweet's, there is no going back!

I hope that MUI4 is more updated than Ambient, latest commit for this one is August 2010.
Kamel
PS Don't shoot me I'm trying to buy a Powerbook for MOS 3

[vidarh]

I think this is the path to go for AROS - aim for making Zune MUI4 compatible instead of expecting people to go back and satisfy with a MUI3.8 (i.e. MorphOS 1.0 IIRC) level API. There is a reason to why development goes *forward*, and that's because it brings a lot of new goodies to the table! And once you tastes the sweet's, there is no going back!

I don't see anyone arguing for sticking to 3.8. The point of the bounty is to bring Zune *forward* to MUI 3.8 compatibility as a first step. Getting to 3.8 would already be a big step in the right direction and make it a lot easier for app developers to target OS4, AROS and MOS in one application.

Then MUI4 compatibility can be a next step. At that point an OS4 port becomes desirable too.

[kickstart]

MUI is all time classic, maybe is better idea port MUI4 to OS4, zune on morphos is a step back imho.

[jj]

I agree, if Zune gets to the standard that you can write an app in MUI4 and it just work in Zune without any other work then it will be brilliant.
 
At that point get it ported to AOS4 whatever, I was just pointing out that to the OP that it is usless for MorphOS

[Rebel-CD32]

This is one of the most important bounties for the future of Amiga software development, and it's great that the bounty terms have been redefined. I don't see why anyone would have a problem with it, Zune won't replace MUI4 in MorphOS, but the software created for Aros will be more easily ported to MorphOS.