Zune for all platforms

[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.

[takemehomegrandma]

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.

Nobody is suggesting that Zune development should stop, where did you get that from? Zune is - and should be - a MUI re-implementation, and of course it should be improved (this is one of many areas that AROS lags seriously behind, the only way to ever catch up is start developing). It should be improved to cover more and more of MUI's features so that eventually it behaves exactly as MUI does. AFAIK it has quite a bit to go, but this should be the goal. Then, when/if Zune is 100% MUI3.8 compatible (for example), then the same AROS program using this API could be recompiled for MorphOS, 68k Amiga OS or OS4 more easily. MUI is backwards compatible, OS's with MUI3.9 should be able to run MUI3.8 applications (and so on). But the added features in MUI4 aren't neglectable, it makes new kind of applications possible, better and easier. The right way forward is to put effort in developing the the various "MUI" implementations in Amiga OS 68k, AROS and OS4 towards MUI4, and not trying to turn the clock backwards a decade or more and expect everyone to write MorphOS 1.0 level applications (GUI-wise), and AFAIK, Zune has yet a bit to go to even reach that point.

[SamuraiCrow]

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?

Put simply, Zune and MUI are mutually exclusive on all systems including OS 3.  The Zune master library is called "muimaster.library" and for good reason:  It is an open-source replacement for MUI by design.

[Kronos]

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

While OT...

Guess your talking bout Ambient on SF.net ? That one is seriously out of sync with what is currently build into beta-release (and might get even more out of sync in a month or so).

[takemehomegrandma]

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.

No-where did I say otherwise, did I? Of course Zune should be developed forward. What I objected to was the idea of having a more or less incomplete MUI3.8 (or less) "Zune" ported to MorphOS and other OS's, expecting this limited (and perhaps somewhat different and perhaps not always 100% MUI compatible) API to become some kind of standard. The only standard is MUI, it's still evolving AFAIK, and Zune has to walk carefully in its footsteps until it catches up, carefully avoiding "branching out". Not the other way around. It will be great though for AROS once it's capable of compiling MUI3.8 level applications, and AROS developers using this API will be able to recompile their SW to other MUI3.8 (or later) enabled platforms more easily.

[HenryCase]

@jacadaps

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)?

The point is improved cross-compatibility.

@jacadaps

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.

Okay, let's get down to brass tacks here. What would Zune need, other than access to intuition.library and graphics.library, to become a 1st class citizen on MorphOS? What essential features are hidden?

@kickstart

maybe is better idea port MUI4 to OS4

I agree it would be nice, but MUI4 is closed source and tied to MorphOS, so it'll never happen.

@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.

That's what we're aiming for, ultimately, so let's look at the positive side. Even if Zune doesn't end up on MorphOS, for one reason or another, improving Zune still helps out MorphOS, if/when it becomes equal in functionality to MUI4.

So, to all MorphOS fans, putting aside your arguments on whether Zune can be ported, do you at least see the benefit of these bounties?

Quite frankly, I don't care if MorphOS gets Zune or not, it's no water off my back, but what I do care about is saving developers time and effort. Being able to target one set of libraries for all Amiga flavours (whether they be the closed-source version or open-source equivalents) will help us all, isn't that what's important here?

[vidarh]

No-where did I say otherwise, did I? Of course Zune should be developed forward. What I objected to was the idea of having a more or less incomplete MUI3.8 (or less) "Zune" ported to MorphOS and other OS's, expecting this limited (and perhaps somewhat different and perhaps not always 100% MUI compatible) API to become some kind of standard.

It's not very interesting before it's 3.8 compatible, that's true. But when it is, having a port makes a very big difference:

Anyone wishing to target MOS, AROS and AmigaOS at the same time will need their software to work with Zune to have it work on AROS.

If Zune is available on all three platforms, then they get a choice: They can target Zune on all of them, as the lowest common denominator, without worrying about incompatibilities, or they can target three different libraries with varying capabilities.

As long as the capability gap between Zune and MUI3.8 / MUI4 is big, I'm sure a lot of developers will choose the latter option because restricting themselves to Zune means either extra work or fewer capabilities, but as the gap closes I'm not so sure you won't start seeing some app developers preferring to target Zune instead.

 The only standard is MUI, it's still evolving AFAIK, and Zune has to walk carefully in its footsteps until it catches up, carefully avoiding "branching out".

The only standard in a fragmented market is what application developers choose to support. Zune has the advantage that it is the only one that has any hope at all of becoming available on all the platforms.

As it stands *there is no standard* - app developers have 3 different targets.

In other words: We'll see.

[Kronos]

@HenryCase

I think your are still not getting it....

Zune is NOT Zune, Zune is a (partial) replacement for MUI.

Therefore there is no app that opens "zunemaster.library" heck there probraly even is no "zunemaster.library" in the 1st place.

If you compile something "for zune" you are compile code written for MUI with MUIM_this and MUIA_that all over the sources.

Thats why you can't have MUI and Zune on the same system just like you can't run both CGX and P96 at the same time.

Zune should aim at improved MUI-compability and if a MUI prog written for MorphOS (not useing MUI4 enhancements) fails to compile&run under a Zune-based systems and this should be seen as a reason to fix Zune not for doing anything to MUI on MorphOS.

[SamuraiCrow]

@Kronos

Isn't that what I just said in post #32?

@Thread

Zune and MUI cannot coexist on one platform.  They all have the same names in the libraries and in the source codes.  Kronos is right.

[HenryCase]

@HenryCase

I think your are still not getting it....

Zune is NOT Zune, Zune is a (partial) replacement for MUI.

Therefore there is no app that opens "zunemaster.library" heck there probraly even is no "zunemaster.library" in the 1st place.

If you compile something "for zune" you are compile code written for MUI with MUIM_this and MUIA_that all over the sources.

Thats why you can't have MUI and Zune on the same system just like you can't run both CGX and P96 at the same time.

Zune should aim at improved MUI-compability and if a MUI prog written for MorphOS (not useing MUI4 enhancements) fails to compile&run under a Zune-based systems and this should be seen as a reason to fix Zune not for doing anything to MUI on MorphOS.

Au contraire, mon frere, it is you that has missed my point. As I said before, I don't care if MorphOS gets Zune or not, as long as the goal of improved cross-compatibility is reached.

One suggestion I made was renaming the header/class files for Zune. If that's all that's needed to allow Zune and MUI to live alongside each other, then it's an acceptable compromise IMO.

Please bear in mind that changing a header/class file only involves altering one line of code, the functions contained within the header/class file can still be named the same. To explain, imagine if Application.mui is equivalent to Z_Application.mui. As long the compiler found the functions it needed in Z_Application.mui, then there needs to be no further changes, so it's really easy for applications to move to using Zune. A function called MUIA_Application_Window will still be found in Z_Application.mui (if this is the route taken), the compiler doesn't care that it isn't what the original application writer may have envisioned, if it is functionally identical.

Also remember that the compiled program will not keep a record of our name for the function, but merely where to find it and how to call it.

Again, putting aside technical arguments, do you agree improving Zune will be a good thing for MorphOS, even if just indirectly?

[itix]

Quite frankly, I don't care if MorphOS gets Zune or not, it's no water off my back, but what I do care about is saving developers time and effort. Being able to target one set of libraries for all Amiga flavours (whether they be the closed-source version or open-source equivalents) will help us all, isn't that what's important here?

I only said replacing MUI4 in MorphOS by Zune would be the ambitious project =P If you can replace it, good, but MUI 4 is a system component like Exec or Intuition. Don't expect replacing system component is an easy task.

[billt]

Are there any MUI 3.8 apps that do NOT work in MUI4/MOS?

[Daedalus]

I don't think the aim was ever to replace MUI4 on MorphOS, and I really don't think it's anywhere near as big a deal as some of the arguments are making out. With a Zune compatibility layer on MorphOS and OS4, it makes it very easy for a developer to write an app for all three platforms. MorphOS itself and all the existing and future MOS-only apps can still use MUI4 for what they need, muimaster.library and what not, and any apps compiled with Zune header files can use the similar-but-different z_muimaster.library. It doesn't interfere with the system at all, but offers an extremely easy route for porting apps between all systems. What's not to like there? Or do some people have a fear of not having a "pure" system or something?

[itix]

One suggestion I made was renaming the header/class files for Zune. If that's all that's needed to allow Zune and MUI to live alongside each other, then it's an acceptable compromise IMO.

Just implement zunemaster.library and install Zune custom classes in SYS:Classes/Zune. No need to mess with header files.

To explain, imagine if Application.mui is equivalent to Z_Application.mui. As long the compiler found the functions it needed in Z_Application.mui, then there needs to be no further changes, so it's really easy for applications to move to using Zune.

Actually no need to because MUI/Zune classes wont appear in BOOPSI class list.

Also remember that the compiled program will not keep a record of our name for the function, but merely where to find it and how to call it.

The problem is you have to recompile programs to use Zune this way. Existing 68k software would not be able to use Zune, neither would existing MorphOS software use Zune.

On Amiga 1200 on the other hand if Zune was used to replace MUI it indeed makes sense but of course Zune must be binary compatible.

[itix]

I don't think the aim was ever to replace MUI4 on MorphOS, and I really don't think it's anywhere near as big a deal as some of the arguments are making out. With a Zune compatibility layer on MorphOS and OS4, it makes it very easy for a developer to write an app for all three platforms. MorphOS itself and all the existing and future MOS-only apps can still use MUI4 for what they need, muimaster.library and what not, and any apps compiled with Zune header files can use the similar-but-different z_muimaster.library. It doesn't interfere with the system at all, but offers an extremely easy route for porting apps between all systems. What's not to like there? Or do some people have a fear of not having a "pure" system or something?

I think idea would be that users on OS3/OS4/AROS would replace MUI's muimaster.library to Zune's muimaster.library. Developers would not have to recompile their software but user can decide whether use MUI or Zune.

[HenryCase]

@Daedalus
Thank you for understanding.

@itix
Firstly, I'm glad you support improving Zune in principal.

Actually no need to because MUI/Zune classes wont appear in BOOPSI class list.

I'm not sure you understand what I was getting at. The goal is to make it easy to develop Zune programs that run on all Amiga systems. This includes using source code that makes reference to MUI methods and attributes in source code. If you have to change the name of each method and attribute, this could be a lot of work. Fortunately, this is not what you need to do, you only have to alter the class name slightly, and then everything else falls into place. I hope my point is clearer now.

The problem is you have to recompile programs to use Zune this way.

I don't see that as much of a problem, you'd probably have to rework other code to port it to another Amiga system anyway, but the change from MUI to Zune will be very minimal (would probably take under 10 minutes to just alter some class names for any Amiga program). Plus, as long as Zune takes off as a cross-platform GUI solution, this only needs to be a one time code alteration.