Zune for all platforms

[itix]

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.

Porting Zune to MorphOS must be the most ambitious project ever. It is not easy replace something what is an integral part of the operating system.

[itix]

How is the structure of MorphOS different from OS4 in this regard? OS4 allows MUI3.9 programs to run alongside ReAction programs. Why would this be different for MorphOS?

Because there already is MUI and it is part of the system. MUI failing to work you make the entire OS (the desktop, ASL, system tools) to fail.

And MUI being part of the system there is hidden stuff the system is using but not exposed for the public.

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

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

[itix]

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.

Yes I got it now. You didnt mean MUI compatible Zune but introduce Zune as new de facto GUI toolkit for all Amigas? MUI compatibility would not be necessarily addressed.

I can understand benefits but if you wish to introduce new GUI toolkit you have to make OS3 (WinUAE) users to adopt it. Failing to do so it will be just yet another GUI toolkit.

[itix]

Do they though, do they all have access to MUI3.8? As far as I understood, MorphOS has MUI4, OS4 has MUI3.9. It's only OS3 that has MUI3.8. Whilst it might seem like I'm being pedantic, the point is that these different versions of MUI are not fully compatible with each other. These incompatibilities leads to extra work for developers.

They are compatible if developers are using documented features only. IBrowse, Voyager and IProbe (HTMLview.mcc) are known to cause gfx glitches but they are using undocumented API calls or data structures. Undocumented methods and attributes however have remained compatible and still work if used properly.

[itix]

PS a bit off topic, MUI4 seems great because of its OOP roots but it's too bad that the entire system is not done that way a bit like NextStep or Cocoa API any plans about this? A bit more abastraction would make development shorter, MUI is only one piece of the puzzle.

Yes and no. MUI offers neat classes for other than just UI (i.e. Dataspace.mui) and more system structs in MorphOS are returned as OOP objects instead of plain structs. But I am not sure if BOOPSI is the best possible solution. Its ID based method dispatcher is bit clumsy sometimes.

[itix]

Zune actually started out on Linux IIRC. The port hasn't been maintained though.

Yes it indeed was but author gave up soon after releasing it to the public.

http://www.reocities.com/SiliconValley/park/3883/zune/snaps/z0115.html

[itix]

The only way to really survive is to give up legacy compatibility. The sooner the better!

I dont think you can "survive" Amiga platform (and is there any reason why should it survive?). The legacy is so strong in Amiga API it is impossible modernize it without designing everything from scratch.

[itix]

No. What I think of is MUI for Linux.

http://www.amiga.org/forums/showpost.php?p=660685&postcount=96

Well, kolla is having a point. MUI is tied to Amiga bitmaps and rastports not available in Linux so in order to write portable software you would need Amiga gfx APIs in Linux. This reminds me about GDI+ layer in Linux used in Mono to (partially) support Windows Forms.