Quote:

My personal worry is that if that "MUI4" gathers any developers on the 68k side and they use the incompatible functions there... the result will be that those 68k programs won't work under MorphOS anymore.

Those developers are unlikely interested to port their software specially to MorphOS, because they think they're using the common standards. On paper 68k+MUI should work as it is on MorphOS, and has worked till today, but now when there's an incompatible branch available, that may change :/

So, in the worst case program ports gets leeched to MorphOS -> OS4/68k direction, but due the present and future incompatibilities programs coming the other way get blocked.

It really would be nice to have a common standard without separating branches. The best would have been that official MUI4 would have been ported to other platforms, but at least the different versions should have remained compatible... but as usual, the things go the worst way in the Amiga land.

>> They only wanted something that would allow a quick port of Odyssey.

> No, they wouldn't have taken the actions they took if they only wanted to pot Odyssey.
> AW can correct me if I'm wrong, but I'm pretty sure the OWB port and bounty were paid
> before this pirate MUI4 was released.

Bounty accomplishment and payment as well as Odyssey v1.23 port release happened after the initial release of MUI 4.0 for OS4:

(September 2011: MUI-OWB v1.9 for OS4 released)
December 24 2013: MUI 4.0 for OS4 released
December 25 2013: Odyssey v1.16 for OS4 released
December 27 2013: Odyssey bounty accomplished
early January 2014: Odyssey v1.23 open sourced
mid-January 2014: MUI 4.0-2014R1 for OS4 released
February 2014: MUI 4.0-2014R2 for OS4 released
March 15 2014: MUI 4.0-2014R3 for OS4 released
March 17 2014: Odyssey v1.23 for OS4 released

And indeed, Odyssey v1.16 for OS4 required the initial version of MUI4 for OS4 released just the day before, and Odyssey v1.23 for OS4 required MUI 4.0-2014R3 released only 2 days before.

> They [...] removed/replaced copyright

...notices.


Edit: corrected timeline

[ Edited by Andreas_Wolf 15.08.2016 - 02:07 ]

Quote:

It does appear that the desire to port Odyssey to OS4 was the primary driving force that prompted the MUI for OS4 programmers to create their unofficial fork of MUI4 for OS4. I agree that the action of porting their version of MUI4 to 68k does create the possibility for some problems, in that one of MorphOS advantages is how well it is able to run 68k Amiga programs, but the number of new 68k programs that are being created that most MorphOS users would want to run and no native PPC MorphOS version is available is probably very low.

The solution is in the hands of the MorphOS developers working on MUI5, as they are the only ones who can offer the correct code to remove the incompatibilities in the MUI4 for OS4 code, and that is not likely to happen, given the current state of animosity between the two groups of programmers.

I am not blaming the MorphOS developers working on MUI5 for any of this bad situation, just stating that they are the only ones who could fix it, and the MUI4 for OS4 guys might not care that it is fixed or not.

@jPV

You do have a point there. But from what I can read at the forums people don't seem too impressed with the 68k version. It's too demanding and buggy. The situation would have been different maybe in the late 90's when people bought PPC or 060 cards, but they are hard to find nowadays and really expensive. I think most 68k users today seems to be more about retro and are satisfied with 030 accelerators. Then this MUI 4 will be barely usable. I'm no programmer, but it seems that no optimization in the world could make this good enough for low end users who constitutes the majority of 68k users.

But things might change of course in unexpected ways. If that comes to that it might be a good idea for MorphOS Team to change those parts of the code that needs changing in order to keep compatibility.

But I seriously doubt it will come to that. More likely it will be mostly a thing for AOS 4. And if the MUI 4 Team do make changes that makes MorphOS MUI not working anymore, I guess Fab can threaten them that he won't release the next version of OWB until that is fixed, since it does go against the original intentions of the source code release. Assuming that Fab is working on OWB, which I do.

Personally, I think Fab may be a little preoccupied with his personal life.
1.25 is moving forward and the community has his sources for earlier revisions.
I think we have asked enough of the poor guy.
Time for others to step up.

> things might change of course in unexpected ways. If that comes to that it might be
> a good idea for MorphOS Team to change those parts of the code that needs changing
> in order to keep compatibility.

That would be a bad idea. Better would be releasing MUI5 for OS3 as suggested in comment #135.

> I guess Fab can threaten them that he won't release the next version of OWB until that
> is fixed, since it does go against the original intentions of the source code release.

Sorry, you lost me here.

> Assuming that Fab is working on OWB, which I do.

OWB/Odyssey development is happening elsewhere today, it seems.

https://github.com/deadwood-pl/OdysseyWebBrowser

It has not been Fabs style to make a lot of noise about what he is doing. So yes, I assume he is working on it in the background.

Quote:


WTF... Do you even have a clue the original intentions of the source release? The provision was added so that fab could retain quality control over Odyssey(IE someone does a poor porting job or makes changes that causes user experience issues) it has nothing to do with MUI. I know because I worked with fab on designing the bounty in the first place.

I withdraw my statement.

> as far as I know the public version is not on the same level as the version used in MorphOS.

Available since MorphOS 3.0 on http://www.morphos-team.net/downloads:

http://www.morphos-team.net/files/src/3.0/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.1/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.2/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.3/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.4/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.5/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.6/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.7/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.8/ambient.tar.bz2
http://www.morphos-team.net/files/src/3.9/ambient.tar.bz2

It seems that they have renamed their Mui to Mui5 now. I can't imagine why ...

They did it with 3.8 to avoid misunderstandings that OS4MUI is not on the same level as MOSMUI.

Quote:

https://muidev.de/blog/5.0-2016R1

Sigh.

Quote:

This is really unbelievably stupid!

brazenly

Quote:

Because they are arseholes. Logic doesn't enter into it I'm afraid.

> They did it with 3.8 to avoid misunderstandings that OS4MUI
> is not on the same level as MOSMUI.

Seems I'm too daft to get it, so would you please rephrase? Who did what with MUI 3.8 to what end?

Quote:

Pirate MUI4 is now called Pirate MUI5? Wow.

How's MorphOS-NG coming along again? Just cut all ties with PPC already. Drop X5000 support since the thing doesn't seem like it will ever be released anyhow. Cut off the opportunities for these leeches to pilfer the hard work of the MorphOS Team.

[ Edited by redrumloa 29.08.2016 - 20:48 ]

> Just cut all ties with PPC already. Drop X5000 support [...]. Cut off the
> opportunities for these leeches to pilfer the hard work of the MorphOS Team.

How will cutting ties with PPC and dropping X5000 support prevent anybody from "pilfering" version numbers from MorphOS components?

Quote:

They aren't just pilfering version numbers, but also stealing code. Once on X86-64 legacy compatibility is broken, right? I'd imagine components like MUI would have to be largely re-written or replaced. At the very least there wouldn't be a perception by a causal user that a X86-64 MorphOS component named MUI X.X would be the same as a PPC OS4 component named MUI X.X.

Quote:

I think he talks about MUI being changed to version 5 in MorphOS 3.8 (if it happened then, haven't checked and don't remember myself)?

MorphOS MUI became version 5 with 3.8, yes.

>>> They did it with 3.8 to avoid misunderstandings that OS4MUI
>>> is not on the same level as MOSMUI.

>> Seems I'm too daft to get it, so would you please rephrase?
>> Who did what with MUI 3.8 to what end?

> I think he talks about MUI being changed to version 5 in MorphOS 3.8 [...]?

Ah yes, thanks. This makes sense.

> They are [...] stealing code.

You mean they are proactively "stealing" current MorphOS MUI5 source code? As far as I've understood Henes' statement he gave 10 months ago (see link in coment #129), they were inadvertently given access to 2006 MUI4 source code at one point in time, and they're developing their own code on that "stolen" base since then. I can't imagine they have access to current MorphOS MUI source code. Why would the MorphOS team allow that? Or am I mistaken?

> Once on X86-64 legacy compatibility is broken, right? I'd imagine components
> like MUI would have to be largely re-written or replaced.

You mean current MUI source code won't compile and run on MorphOS on x86-64? I don't know if that'll be the case. The MorphOS team would have to answer that, I guess.

MorphOS team member geit said:

"if the classic API compatiblity sails over the cliff most of the stuff will require more or less just a recompile."
http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=11382&start=38

...and...

"Parts where software hacked/accessed system structures need to be rewritten for sure, but beside that it simply should work."
http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=11382&start=51

> At the very least there wouldn't be a perception by a causal user that
> a X86-64 MorphOS component named MUI X.X would be the same as
> a PPC OS4 component named MUI X.X.

I don't share your optimism here. Why wouldn't a "causal user" think it's the same component, compiled for OS4/PPC in one case and for MorphOS/x86-64 in the other case?