Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: OlafS3 on September 19, 2011, 04:06:31 PM
-
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.
-
I think this is an excellent endeavour - there are too many issues already driving the different camps apart. I should be donating as soon as I get paid :)
-
But what would be the point of Zune on MorphOS, which already has the latest and greatest MUI ?
-
It would be the point that you can develope on one platform without caring about the different implementations and not wasting time with additional testing and workarounds.
-
But what would be the point of Zune on MorphOS, which already has the latest and greatest MUI ?
Well, if you only ever want your app to run on MorphOS then you are of course free to use MUI 4 and take advantage of its extra features. But it would be a good thing for anyone else who might like the idea of their software being available on all three platforms with a minimum of fuss...
-
...and for a moment I thought someone was porting my Windows 7 phone sync software to the Amiga. :D
-
@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! ;-)
-
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
I wonder would it be possible to simply write a wrapper layer which redirects calls from a Zune app to the underlying MUI4? I'm not the world's best programmer, so maybe I don't understand, but surely code could be written to use Zune calls where they live alongside MUI4, perhaps with a modified compiler. Or am I just being naive?
-
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.
-
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.
-
I wonder would it be possible to simply write a wrapper layer which redirects calls from a Zune app to the underlying MUI4?
Wasn't Bernd AfA doing something like this already with AfA_OS (http://amidevcpp.amiga-world.de/afaupload.php)?
-
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.
-
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.
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.
-
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
-
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...
-
@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.
-
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.
-
@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)?
-
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.
-
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?
-
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! ;)
-
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.
-
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.
-
Why re-invent the wheel for like the third of fourth time
-
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
-
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.
-
MUI is all time classic, maybe is better idea port MUI4 to OS4, zune on morphos is a step back imho.
-
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
-
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.
-
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.
-
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.
-
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).
-
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.
-
@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?
-
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.
-
@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.
-
@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
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?
-
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.
-
Are there any MUI 3.8 apps that do NOT work in MUI4/MOS?
-
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?
-
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.
-
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.
-
@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.
-
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?
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.
-
With a Zune compatibility layer on MorphOS and OS4,
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.......
-
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.
-
Please entertain redefining Zune as cross-platform GUI toolkit.
I can entertain redefining my right ear as my left leg.... probraly very entertaining but won't get me very far ....
Zune is what it is and IF it wants to become a cross-platform GUI toolkit of it's own merit it would need to drop mimiking MUI (read zunemaster.libtrary ZUNEM_ and ZUNEA instead of MUI this and that).
Problem is there would be 0.0 Zune SW at that moment.....
Mind setting up ZUNE-MUI and ZUNE-ZUNE in parallel under AROS and developing ZUNE-ZUNE further independently from MUI might make sense and in this scenario porting ZUNE-ZUNE to MorphOS would atleast not be completly pointless.
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 hope you all the best of luck!
And yes, I agree, MUI 4 has been good to me! ;)
-
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 (http://aminet.net/package/dev/gui/Feelin_common).
-
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.
No, when Zune reaches MUI3.8 level, anyone wishing to target MorphOS, 68k Amiga OS, AROS and OS4 should have their software work with MUI3.8!
If by then any MUI3.8 applications doesn't compile for/run on Zune, then Zune is broken or lacking stuff, as simple as that. It's the MUI API that needs to be intact, regardless the underlying software (be it Zune or anything else).
This confusion of API's and underlying software sounds very familiar to the "oh, but MorphOS is not Amiga because it doesn't have the Amiga sources" nonsense, completely disregarding the fact that the very same Amiga API is completely re-implemented by using *other* sources, and it works just fine!
Not only would it be impossible (or have to be done in a very weird way, as already explained by others) to run Zune in parallel with MUI4 on MorphOS, or "MUI3.9 + some 3rd party MUI4 additions" on OS4 for that matter, it would also be *totally redundant*, since all MorphOS developers, and OS4 developers too, can *already* target their software for the MUI3.8 API (http://aminet.net/search?query=mui38) if they really want to. No need to squeeze in some Zune SW with a hammer and a shoehorn, that provides a fraction of the functionality compared to what's natively available, and in a worse way. Crazy!
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.
In that case, it will be MUI3.8 that will be the common denominator. Zune is merely a re-implementation of MUI. In practice, this will mean MUI on MorphOS and Zune on AROS, both using the same API (if Zune is done right). Why is this so difficult to understand?
-
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.
Then fulfill Zune's purpose, and make it a true MUI API re-implementation on AROS! For a start, the MUI 3.8 API (http://aminet.net/search?query=mui38) would be something to aim for...
-
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.
Are you suggesting *a brand new* GUI toolkit, reminding of some very old MUI API but incompatible to MUI to various degrees, and *ahelluvalot less capable*? And you think this would be better than giving Zune true MUI compatibility?
Wow.
Well, go ahead and do it, relese your "Zune" for MorphOS and OS4, see how many will use it, and learn the true meaning of "redundant" the hard way...
-
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 (http://aminet.net/search?query=mui38) 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.
-
Then fulfill Zune's purpose, and make it a true MUI API re-implementation on AROS! For a start, the MUI 3.8 API (http://aminet.net/search?query=mui38) 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
-
You will be able to use a lot of MUI code with Zune when it's fully MUI3.8 compatible
You should be able to use *all* MUI3.8 code when Zune is fully MUI3.8 capable, right?
This is exactly what this thread is about! Read the bounty description for yourself:
http://www.power2people.org/projects/profile/61
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?
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?
-
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.
-
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.
Backwards compatibility to MUI3.8 API, as the lowest common denominator?
-
takemehomegrandma, can you please tell us which MUI applications you have coded or are developing?
-
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.
-
takemehomegrandma, can you please tell us which MUI applications you have coded or are developing?
Maybe takemehome... not develop mui applications but he can give opinions, no need to develop.
-
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.
Are these incompatibilities documented somewhere, like in a chart or something? Eh, formatting lost below, use your imagination...
Feature name works in MUI3.8 works in MUI3.9 works in MUI4.0
Thing 1 yes missing yes
Thing 2 yes yes flaky
Cat yes yes yes
Hat missing yes yes
etc...
Then we all know (1) what to avoid for full cross-platform, and (2) what to fix in our OS of choice's MUI.
-
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.
-
Are these incompatibilities documented somewhere, like in a chart or something?
Feature name works in MUI3.8 works in MUI3.9 works in MUI4.0
Thing 1 yes missing yes
Thing 2 yes yes flaky
Cat yes yes yes
Hat missing yes yes
etc...
Then we all know (1) what to avoid for full cross-platform, and (2) what to fix in our OS of choice's MUI.
I expect Zune developers to have some kind of list like this as their roadmap towards MUI4? If they haven't mapped out the differences between the MUI versions and current Zune, they ought to be quite lost. Maybe they could post it on the bounty page? Would also be a good way of doing progress reports to show how Zune is developing over time...
-
I agree why does someone have to be a MUI Dev to post opinion or underestand what the issues are.
If you understand Software degv, APIs or just common sense you would understand.
The most obvious thing is that everyhting in Zune is called the same, the classes, the methods, the properties etc etc.
Then you won't even need to re-compile. Like you dont have to re-compile system friendly 68k software on MorphOS.
Zune should just be an API re-imp of MUI, simples, anything else is a waste of time.
-
I expect Zune developers to have some kind of list like this as their roadmap towards MUI4? If they haven't mapped out the differences between the MUI versions and current Zune, they ought to be quite lost. Maybe they could post it on the bounty page? Would also be a good way of doing progress reports to show how Zune is developing over time...
I suppose this is a starting point...
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=5805&forum=4&post_id=54683#forumpost54683
-
@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.
-
By non-coder do you mean non-mui coder or just non-coder?
-
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.
-
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)?
In the Morphos site "and AROS (http://www.aros.org/) for providing the source base of many components, including but not limited to DOS, Intuition, GadTools, Locale, Commodities."
Then Morphos devs said that they gave back source code to Aros. So if intuition rely on MUI internals on Morphos then its not a problem as you gave back the corrected/modified source code to Aros, or Am I missing something?
Kamel
-
Am I missing something?
See APL section 1.9.
-
See APL section 1.9.
I'm no good at licence terms, but is this not more related to the section below ?
Kamel
3.2. Availability of Source Code.
-
I'm no good at licence terms, but is this not more related to the section below ?
Kamel
3.2. Availability of Source Code.
I can't see how it would be. 1.9 specifies which files actually fall within APL, which is the key here.
-
@kamelito
Then Morphos devs said that they gave back source code to Aros. So if intuition rely on MUI internals on Morphos then its not a problem as you gave back the corrected/modified source code to Aros, or Am I missing something?
The MorphOS devs haven't violated the terms of the APL. They aren't required to share every change they made to the AROS code, APL is not like a GPL licence in this way.
@all
Can we get back to discussing the bounty please. Who is interested in donating (if not straight away, then later)? If you're not interested in the Phase 1 bounty, would you be interested in supporting later Zune Fix bounties?
http://www.power2people.org/projects/profile/61
-
@kamelito
The MorphOS devs haven't violated the terms of the APL. They aren't required to share every change they made to the AROS code, APL is not like a GPL licence in this way.
@all
Can we get back to discussing the bounty please. Who is interested in donating (if not straight away, then later)? If you're not interested in the Phase 1 bounty, would you be interested in supporting later Zune Fix bounties?
http://www.power2people.org/projects/profile/61
I already donated 20 bucks. If I was a good developer in need of money, I'll be waiting until the money from the zune enhancement bounty is moved to the new bounty. I suppose that the Power2P guy do have the email addresses of the one who haven't moved their money yet, so why not asked them to send a mail explaining all that?
Kamel
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.
PSS I didn't say they violate AROS APL I was just trying to understand it.
-
In my opinion, starting with the MUI3.8 target was like asking folks to drop back to kickstart/workbench 2.04 standards (limited AGA/RTG/locale support, etc.)
If you want to gain support of _all_ Amiga-like platforms for an improved Zune, you should try to offer something that they don't already have. If you're directly targeting MUI4, you might expect support from the communities that don't have that level of MUI API compatibility available to their platform.
One could ask app developers what they think should be in a hypothetical MUI 5.x, feature list and then take that info along with examining the currently available MUI3.9 and MUI4 implementations to shape the Zune development plan.
-
In my opinion, starting with the MUI3.8 target was like asking folks to drop back to kickstart/workbench 2.04 standards (limited AGA/RTG/locale support, etc.)
If you want to gain support of _all_ Amiga-like platforms for an improved Zune, you should try to offer something that they don't already have. If you're directly targeting MUI4, you might expect support from the communities that don't have that level of MUI API compatibility available to their platform.
One could ask app developers what they think should be in a hypothetical MUI 5.x, feature list and then take that info along with examining the currently available MUI3.9 and MUI4 implementations to shape the Zune development plan.
Nobody wanted to accept the original bounty because it was a lot of work for say maybe not enough money. (even if money is not everything here). The decision was taken (see aros-exec.org forums) to create a multiple phases bounty. The first one aimed at 3.8 compatibility. The others will take care of MUI 4 and more. Kamel
-
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.
-
The severe lack of understanding and constant jumping to conclusions is really hurting this cause, and therefore holding back the entire Amiga community.
-
One could ask app developers what they think should be in a hypothetical MUI 5.x, feature list and then take that info along with examining the currently available MUI3.9 and MUI4 implementations to shape the Zune development plan.
MUI is still under development AFAIK, so let the Zune re-implementation coneinue being a re-implementation of MUI (3.8/4.0) and nothing else, and then when/if MUI reaches some MUI5 level, only *then* have a look at it! ;)
-
Why re-invent the wheel for like the third of fourth time
Because Stefan Stuntz and the MorphOS devs are a bunch of wussies.
-
Nobody wanted to accept the original bounty because it was a lot of work for say maybe not enough money.
Money is not the issue. The main problem is that the effort is rather pointless. MUI4 is a closed environment moving target for a close to nonexisting plattform. Why bother with it? In my view, AROS and Zune should ignore whatever goes on in MUI4 and MorphOS and rather dictate its own future on its own merits, this so called "catch up" game doesnt help anyone. The sooner AROS breaks away from MorphOS and AmigaOS4, the better.
-
Money is not the issue. The main problem is that the effort is rather pointless. MUI4 is a closed environment moving target for a close to nonexisting plattform. Why bother with it? In my view, AROS and Zune should ignore whatever goes on in MUI4 and MorphOS and rather dictate its own future on its own merits, this so called "catch up" game doesnt help anyone. The sooner AROS breaks away from MorphOS and AmigaOS4, the better.
1. Not having a proper MUI re-implementation would affect Amiga compatibility in a very negative way (as it already does), making it more difficult to develop- or port applications for all 4 platforms, instead of easier (which seems to be the spirit of this bounty). MUI is the common denominator.
2. Since time and effort has to be spent on development *anyways*, why not spend it towards making it easier to port Amiga, MorphOS and OS4 applications to AROS (which, again, seems to be the spirit of this bounty), instead of creating a GUI that's something obscure and incompatible to Amiga, available only to the dozen of AROS devs and handful of users?
-
Money is not the issue. The main problem is that the effort is rather pointless. MUI4 is a closed environment moving target for a close to nonexisting plattform. Why bother with it? In my view, AROS and Zune should ignore whatever goes on in MUI4 and MorphOS and rather dictate its own future on its own merits, this so called "catch up" game doesnt help anyone. The sooner AROS breaks away from MorphOS and AmigaOS4, the better.
While I do agree that AROS would benefit in the long run from going it's own way with Zune, I don't agree it's time yet. Catch up first. Then port, so it's available "everywhere", making it a much more desirable target. Only if/when Zune is there is it really worth talking about extending it and try to make Zune more desirable than the original MUI.
-
While I do agree that AROS would benefit in the long run from going it's own way with Zune, I don't agree it's time yet. Catch up first. Then port, so it's available "everywhere", making it a much more desirable target. Only if/when Zune is there is it really worth talking about extending it and try to make Zune more desirable than the original MUI.
OMG, not another pointless branch-out just for the sake of it! Haven't we had enough of those...? Is this the true long-term goal of the bounty project? Would be *very* interesting to know that now, because it suddenly feels a lot more pointless and futile...
-
+1
My vision would be to have a kind of framework (set of libraries) that exist on all platforms and make it easy to port applications and games (parallel to existing libraries), so everyone can decide if he only wants to program for one platform or all. Then you could also have bounties for common applications like web browsers and the divide would not do any harm. I think starting with Zune and 3.8 compatiblity is a good begin, but zune could and should evolve further. And words like "dictating" are not helpful because this word only create resistance. I would call it an "additional offer".
-
I think starting with Zune and 3.8 compatiblity is a good begin, but zune could and should evolve further.
You know what has evolved further than MUI3.8? MUI4! Of which some of its functionality is now being brought to OS4 by third party developers on the OS4 platform, for the purpose of making it easier to port/write cross-platform applications. Does that ambition sound familiar...?
-
OMG, not another pointless branch-out just for the sake of it! Haven't we had enough of those...? Is this the true long-term goal of the bounty project? Would be *very* interesting to know that now, because it suddenly feels a lot more pointless and futile...
Who is talking about a "pointless branch-out"? Zune first needs to reach parity. But once Zune reaches parity, a decision needs to be taken: Let MUI dictate the pace, or move forward even if it means adding functionality that's not already there in MUI.
If MUI keeps moving forward at a good pace and delivers what is needed, then great. If not, letting Zune stagnate out of fear of future incompatibilities would be bad. In that case it would certainly not be pointless. I don't think anyone wants Zune to add new incompatible functionality for no good reason.
In any case, that is far down the road. First we need MUI3.8 compatibility and then MUI4 compatibility, which will both be beneficial regardless of where Zune goes next.
But this is another reason why ports of Zune to MOS and AmigaOS are important. If/when Zune reaches that point, *if* the decision is made to evolve Zune without waiting for MUI, then 1) people can opt to use Zune on all the platforms if they wish and/or 2) further enhancements to Zune can be more easily re-used on the other OS's if they would like to copy the improvements.
-
So what you are describing is re-inventing the wheel again , and branching out past MUI4.
Shouldn't MUI set the pace its been the dipso facto standatrd on amigalike OSs for quite some time now.
Is this a jelaousy thing, because MorphOS has MUI4 and everybody else stuck in the past?
Is there some agreement between MorphOS and MUI dev that MUI4 can not be used on AOS4 or AROS?
-
Is there some agreement between MorphOS and MUI dev that MUI4 can not be used on AOS4 or AROS?
Of course the MUI API can be re-implemented (just like the Amiga API was re-implemented on MorphOS)...
-
Is there some agreement between MorphOS and MUI dev that MUI4 can not be used on AOS4 or AROS?
Not in those exact words, but pretty much, yes.
Besides, why hold yourself back with closed source solutions (which mean waiting for permission for a port), when the possibility exists to have the improvements we want without the politics?
-
Wasn't there some talk of porting Zune to Linux at some point?
That would be great as being able to recompile MUI apps to run natively on Linux would open up a whole new world of opportunities.
-
Wasn't there some talk of porting Zune to Linux at some point?
That would be great as being able to recompile MUI apps to run natively on Linux would open up a whole new world of opportunities.
Zune actually started out on Linux IIRC. The port hasn't been maintained though.
-
Wasn't there some talk of porting Zune to Linux at some point?
Interesting idea. I'm looking at wxWidgets for AmigaOS (Thanks to AmiCygnix too!), and the thought of the reverse crossed my mind as well, to port Amiga apps on other wxWidgets platforms and have them look as native there as possible. (biggest benefit imho between wx and qt/gtk/etc is that wx intends to have an app look native on every OS it supports, not to look like you're running a qt app on MS Windows etc.) How beneficial is that? Not sure, if the Linux/Windows/etc peeps will be super excited, but it's an easy thought to think about anyway.
Anyone that does do a Zune/MUI/Reaction/whatever to other platforms, consider wrapping to wxWidgets on those platforms to maximize how many you get to without looking weird on them. :)
-
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
-
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
Thanks, my memory isn't as bad I thought! :)
-
Sheesh, why did I unignore you...
1. Not having a proper MUI re-implementation would affect Amiga compatibility in a very negative way (as it already does), making it more difficult to develop- or port applications for all 4 platforms, instead of easier (which seems to be the spirit of this bounty). MUI is the common denominator.
No it is not, stop fooling yourself (and others). MUI _could_ be common denominator, but with its current licensing, that is just not possible.
2. Since time and effort has to be spent on development *anyways*, why not spend it towards making it easier to port Amiga, MorphOS and OS4 applications to AROS
Why not break free from the legacy and legal nonsense that *anyways* hinders MorphOS and OS4 from ever becoming interesting outside inner circles? Seriously, why on earth let closed, narrow minded and retro focused projects dictate what a free and open source operating system is to become?! I'm not an "Amiga developer", but I was, I'd develop for AROS and screw the rest. AROS is _the only_ chance this... "plattform", has. Both MorphOS, with all its brilliance and yadida, and OS4, have locked themselves up in corners from where there is no escape. The only way to really survive is to give up legacy compatibility. The sooner the better! Geh, I'm repeating what I wrote more than a decade ago already... wtf am I doing here anyways. :roflmao:
-
Zune should just be an API re-imp of MUI, simples, anything else is a waste of time.
No, au contraire - letting MUI dictate AROS development is a waste of time.
-
Its ID based method dispatcher is bit clumsy sometimes.
This qualifies for me as the understatement of the year (TM) ;)
greets,
Staf.
-
While I do agree that AROS would benefit in the long run from going it's own way with Zune, I don't agree it's time yet.
Yet? Are you serious? The ideal time to do it has already passed a long time ago, it's been the sooner the better for years already.
What you really would want to do, is to make the platform desirable for people also _outside_ our teeny weeny constantly shrinking community.
-
IMNSHO it should be done like this:
1) Get Zune to fully implement all publicly known MUI 4 functionality to achieve 100% source code compatibility.
2) Make Zune work on OS 3.x, OS4, AROS and MorphOS.
3) Once all that is achieved stop tracking MUI 4 and do whatever the feck the Zune developers like whilst keeping Zune working on all four platforms.
-
You know what has evolved further than MUI3.8? MUI4!
Nonsense. MUI4 is as locked up and messy as 3.8. The few technical improvements are few and of little importance.
-
But once Zune reaches parity
That will _never_ happen, you know.
-
Shouldn't MUI set the pace its been the dipso facto standatrd on amigalike OSs for quite some time now.
Hm, what do you mean? I really don't know that many MUI apps that are "standard" on neither OS4 nor AROS.
Is this a jelaousy thing, because MorphOS has MUI4 and everybody else stuck in the past?
Heh, MorphOS is stuck in the past just as much as everyone else here. MUI4 is just marginally better than MUI3.8 or Zune. All of them are way old in terms of design.
Is there some agreement between MorphOS and MUI dev that MUI4 can not be used on AOS4 or AROS?
Pretty much, which is why this entire MUI as a common platform is a total waste of time.
-
That would be great as being able to recompile MUI apps to run natively on Linux would open up a whole new world of opportunities.
This is just nonsense, for so many reasons.
MUI is bound by "the Amiga way", which is totally different from "the UNIX way" that Linux follows. I have never heard anything about using MUI on Linux, it's totally pointless anyways, there is no "AmigaOS" compatibility layer in Linux (and for a reason, noone needs it). What you think of is probably various efforts to create bridges between toolkits used on X11 and MUI, to make porting of X11 applications to Amiga systems easier by using MUI.
-
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.
-
This is just nonsense, for so many reasons.
MUI is bound by "the Amiga way", which is totally different from "the UNIX way" that Linux follows. I have never heard anything about using MUI on Linux, it's totally pointless anyways, there is no "AmigaOS" compatibility layer in Linux (and for a reason, noone needs it). What you think of is probably various efforts to create bridges between toolkits used on X11 and MUI, to make porting of X11 applications to Amiga systems easier by using MUI.
No. What I think of is MUI for Linux.
http://www.amiga.org/forums/showpost.php?p=660685&postcount=96
-
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.
-
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.
Which is what I wanted back in the 90ies, which is what Apple did :)
(http://amiga.nvg.org/moro/os40.gif)
-
IMNSHO it should be done like this:
1) Get Zune to fully implement all publicly known MUI 4 functionality to achieve 100% source code compatibility.
2) Make Zune work on OS 3.x, OS4, AROS and MorphOS.
3) Once all that is achieved stop tracking MUI 4 and do whatever the feck the Zune developers like whilst keeping Zune working on all four platforms.
Bingo.
@kolla
You've clearly got your own agenda that is little to do with Zune. Suggest you make your own thread to share your ideas.
-
Which is what I wanted back in the 90ies, which is what Apple did :)
(http://amiga.nvg.org/moro/os40.gif)
Very nice!
Similar to the Q/Box idea from what little I remember of it.
Doing what you suggest with a mixture of Haiku and AROS code would be the dream desktop for me.
-
Very nice!
Similar to the Q/Box idea from what little I remember of it.
Doing what you suggest with a mixture of Haiku and AROS code would be the dream desktop for me.
My pic is old, it's dated May 16th 1998 in my filsystem.
-
IMNSHO it should be done like this:
1) Get Zune to fully implement all publicly known MUI 4 functionality to achieve 100% source code compatibility.
2) Make Zune work on OS 3.x, OS4, AROS and MorphOS.
3) Once all that is achieved stop tracking MUI 4 and do whatever the feck the Zune developers like whilst keeping Zune working on all four platforms.
This!
-
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.
Zune Phase I has been assigned. :)
http://aros-exec.org/modules/newbb/viewtopic.php?post_id=63321#forumpost63321
-
Which is what I wanted back in the 90ies, which is what Apple did :)
(http://amiga.nvg.org/moro/os40.gif)
This is lovely, except for the part where "Java Virtual Machine" connects to "AmigaOS 4/5 Applications." No, for the love of God, no! It'd be enough work to move the software base from one outdated API, but to add in another which also happens to be controlled by territorial, lawsuit-happy douchebags? Keep that stuff as separate from the OS as possible :/