Zune for all platforms

[HenryCase]

@OlafS3
Thanks for creating this topic.

@Daedalus
Great to hear you're supportive. :-)

@JJ
As Daedalus has pointed out, the idea behind this series of bounties is driving enhanced cross-compatibility.

Also, it's worth pointing out why this bounty was created. Whilst the goal for Phase 1 is bringing Zune to be equal to MUI3.8, that is not the end goal.

The Zune Fix series of bounties intends to replace the Zune Enhancement bounty by breaking the goals of the Zune Enhancement bounty into more manageable steps. The main aim behind the Zune Enhancement bounty was having an open-source, cross-platform replacement for MUI that is equal to MUI4.

In other words, whilst Zune Fix - Phase 1 has moderate goals, the main aim of the Zune Fix bounties is far more ambitious. Imagine all platforms being able to improve each others software library. We've only been in competition with each other because of what happened in the past, together our software libraries can grow much faster. Why duplicate work when you don't need to?

That's not to say all platforms will merge into one, they can still differentiate in other areas, but for developers who want to target all Amiga platforms, fixing up and porting Zune will be a godsend.

I hope you will consider donating to the bounty.

@all
One thing that hasn't been mentioned yet is that kas1e (the developer behind many OS4-centric projects) has offered to help out whomever takes on the bounty with advice about MUI, so the developer will have support from others.

Anyone with funds in the Zune Enhancement bounty can move them to the Zune Fix - Phase 1 bounty by contacting André Siegel via bounties@power2people.org. This is what's recommended on the Power2People site also:
http://www.power2people.org/projects/profile/54

To people who haven't donated yet, here's a reminder of the link you need:
http://www.power2people.org/projects/profile/61

Go on, you know it makes sense! ;-)

[HenryCase]

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.

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?

Besides, MUI4 is just a front end for functions provided at the low-level of the OS. It's the set of tools given to build a GUI. To use an analogy, it's the paintbrush, it's not the canvas.

[HenryCase]

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.

Who said anything about MUI failing to work. MUI will still work. Zune can run alongside MUI, it's easy. Look at this MorphOS documentation:
http://library.morphzone.org/MorphOS_API_and_Its_Organization

graphics.library, is responsible for low-level graphics functions like drawing pixels and other primitives, copying rectangular blocks of display, scrolling etc. Many programs do not use it directly.

intuition.library, delivers intermediate level graphics interface objects like screens and windows. Interfaces to user input devices (mouse and keyboard to name a few). Provides very basic user controls (gadgets). Provides also BOOPSI (Basic Object Oriented System for Intuition), a language independent object oriented programming framework, used commonly by other components.

MUI is built on top of intuition.library, which is built on graphics.library. Zune will also be built on top of intuition.library. There is no technical reason why it can't be. Hope this helps you understand.

@all
If you recognise any of the names of the people in the Zune Enhancement bounty contributors, please PM them so they can at least be made aware of the the changes to the Zune bounties:
http://www.power2people.org/projects/profile/54
Thanks.

[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

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

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

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

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

[HenryCase]

Personally, I think that the Zune compatibility layer should just be a hosted version of AROS for PPC AmigaOS and PPC MorphOS.  Then you could run the same binaries on each system without worry.

The downside being a performance hit.

By the definition of Zune (read MUI-replacement) at any point where such a compability layer would be needed it should be considered a bug in Zune.......

Please entertain redefining Zune as cross-platform GUI toolkit. Then you'll see your talk of bugs in Zune is totally missing the point.

[HenryCase]

Problem is there would be 0.0 Zune SW at that moment.....

You will be able to use a lot of MUI code with Zune when it's fully MUI3.8 compatible, which opens it up to quite a lot of Amiga software, in addition to the programs that already exist on AROS.

Edit:
In a way you are proposing Wine as a cross-platform-API for *nix and Win and are then demanding that Windows should be adapted to quirks&shortcomings of Wine......

I never demanded any changes to MUI, so your point is invalid.

Then fulfill Zune's purpose, and make it a true MUI API re-implementation on AROS! For a start, the MUI 3.8 API would be something to aim for...

This is exactly what this thread is about! Read the bounty description for yourself:
http://www.power2people.org/projects/profile/61

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.

Well, yes and no. You've understood part of the plan, but missed the other part. Simply put, there are two goals that the latest Zune bounties hope to kickstart:

1. Be as compatible as possible with MUI (preferably the latest and greatest version).
2. Be a cross-platform toolkit, running on all Amiga platforms.

The close compatibility to MUI is going to be a benefit for Zune for many reasons. Firstly, you can make use of existing source code. Secondly, coders familiar with MUI don't have to acquire new skills to use Zune. Thirdly, it helps build bridges between Amiga platforms.

Please note that these bridges will be built even if Zune stays on AROS only.

However, to make the life of coders even easier, we also have the second goal, which is to bring Zune to other platforms. Not as the default option for that platform, but as a choice. The only benefit at first will be allowing coders to target one GUI toolkit for all Amiga platforms, to make their lives easier and to thereby increase the software quantity and quality on Amiga platforms.

Now with all this talk about how we're going to do this that and the other, we've gotten away from the key topic in this thread, which is a bounty to improve Zune. I hope you will agree with me that taking Zune to the level of MUI3.8, and then subsequently MUI4, will help MorphOS even if Zune is not ported to MorphOS. This is because it will help make porting programs between these two Amiga platforms easier. Ports of Zune to OS4 and OS3 will only improve things further.

So you see, focusing this discussion about Zune on MorphOS is missing the bigger picture, which is improving Zune = good times for all. Capiche?

@all
Now that this thread is back on track, can we start talking about this bounty please?
http://www.power2people.org/projects/profile/61

Been good to see it grow over the past couple of days, got to $515 already. If we could get the remaining $430 from the old bounty we'd be looking at close to $1000 for Zune Fix Phase 1, which I'd say would be a good incentive for a developer to pick it up. Does anyone know who the remaining Zune Enhancement bounty donators are?
http://www.power2people.org/projects/profile/54

Thanks in advance for your help.

[HenryCase]

Then fulfill Zune's purpose, and make it a true MUI API re-implementation on AROS! For a start, the MUI 3.8 API would be something to aim for...

Are you slow? This is exactly what this thread is about! Read the bounty description for yourself:
http://www.power2people.org/projects/profile/61

[HenryCase]

You should be able to use *all* MUI3.8 code when Zune is fully MUI3.8 capable, right?

Yep. Apologies for understating. ;-)

Yes I get that much, MUI3.8 re-implementation. But what I don't quite understand is why Zune should be ported to Amiga OS, MorphOS and OS4, when all these platforms *already have* MUI3.8? AROS is the only one lacking this, and this is what Zune aims to fix, right? Then the MUI3.8 API will be everywhere, right? So why port Zune anywhere?

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.

If MUI4 was open-source, we wouldn't be needing to have this conversation. As it stands, improving Zune is the best bet to being able to offer a toolkit that all Amiga developers can target if they want to port to all Amiga platforms. Note that I don't care if Zune is ported to MorphOS, as long as MUI and Zune work identically to each other then it doesn't matter what the toolkit being used is called. I'm not attached to the name of the toolkit, I'm attached to the idea that developers can target all Amiga platforms easily.

Edit: OK, after thinking about this one more time, I now realize that it must be as a way of improving 68k MUI on Amiga OS 68k by simply replacing it, as development goes on further and tries to catching up with MUI4, right?

That is one benefit of this work on Zune, yes. Not the only benefit, but something worth mentioning certainly. Thanks for taking the time to consider the possibilities that this work on Zune could bring.

[HenryCase]

Backwards compatibility to MUI3.8 API, as the lowest common denominator?

If that works then that's fine, though this cross-compatibility does not seem to be reliable, from listening to Amiga devs. Plus, whilst it would be a great starting point, it would restrict access to future improvements, which brings us back to improving Zune.

[HenryCase]

@kickstart

Maybe takemehome... not develop mui applications but he can give opinions, no need to develop.

@JJ

I agree why does someone have to be a MUI Dev to post opinion or underestand what the issues are.

If I understood correctly, the reason Rebel-CD32 asked what MUI applications takemehomegrandma has worked on is because takemehomegrandma was implying he had an in-depth knowledge of MUI (implying you can code for MUI3.8 features without incident).

To have an in-depth knowledge of MUI, you need to have coded using it, end of. Learning about the real challenges of creating cross-platform programs only come from practical application of the tools. So whilst you're entitled to an opinion on the challenges coders face, if you're a non-coder forgive me if I take your opinion with a pinch of salt.

@takemehomegrandma

I expect Zune developers to have some kind of list like this as their roadmap towards MUI4?

We only need a map of features for MUI3.8 at the moment, as stated before the plan is to get to MUI3.8 compatibility first, investigation about MUI4 can wait until later.

[HenryCase]

By non-coder do you mean non-mui coder or just non-coder?

Both apply, but a coder that hadn't used MUI would understand it less than a coder that had, so whilst I'd be more likely to pay heed to the advice of a coder over a non-coder, I'd respect the opinions of a MUI coder even further.

In other words, in terms of understanding:

Less understanding - - - - - - - - - - - More understanding
Non-coder - - - Coder that hadn't used MUI --- MUI coder

I'd say the reasons for this are pretty obvious.