Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: eliyahu on January 02, 2017, 01:16:35 AM
-
The MUI for AmigaOS (http://muidev.de) development team is proud to announce the immediate release of version 5.0-2016R3 of the Magic User Interface for AmigaOS4/PPC and AmigaOS3/m68k. The release archives can be found in the download section (http://download.muidev.de/).
Like all former releases a keyfile is required to enable all available settings. Old keyfiles from MUI 3.8 can be used without any restriction.
Please note that MUI5 for AmigaOS3/m68k is definitely targeted at powerful systems with a fast CPU and a fast graphic board. Although it is still possible to run this release on a real 68k machine an emulation like WinUAE is very highly recommended. Also colormapped screens with 256 colors at most are still supported, but MUI5 makes heavy use of fancy truecolor images and effects which cannot be provided on colormapped screens with the full range of possibilities.
These are the most important new features of MUI5:
- inline editing in List objects
- built-in hooks for multicolumn lists
- built-in handling of sortable list columns
- support for fixed (initial) width list columns
- new Textdata class to support UTF8 encoded text (via codesets.library)
- new reordering methods for Group and Family class
-
IIRC, MUI is vital for some applications.
I always found it depended on the application, to a certain extent, as well as the MUI core.
Have things changed a lot with respect to that?
-
IIRC, MUI is vital for some applications.
I always found it depended on the application, to a certain extent, as well as the MUI core.
Have things changed a lot with respect to that?
Don't use these new versions with the older classic/68k apps. They require very high system requirements and are not 100% backward compatible. Also it is simply absurd that they "require a keyfile" to the original version, when it has been well documented that original keyfiles are no longer available. :(
-
OK, OK. No need to shout.
MUI was always a bit problematic to get right, and somewhat processor dependent, and I hadn't expected that to change much... but it's nice that the people with the wild horses for processors and sideways crazier modern solutions are being allowed to gallop.
Occasionally getting thrown out of the saddle, true, but that's always the case with bleeding edge technology. :D
-
Thanks for this new update!
-
OK, OK. No need to shout.
I get super frustrated with these posts about "a new version". They pop up every few months. Almost as often as some poor schmuck, freshly back to the Amiga community after decades away, posts about all the problems they're having. They think "ooh, I'll just download the latest version", not knowing how many issues it causes. IMHO every post about "a new version" should include a warning about this. Or at least give people a heads up, you know? :(
-
Heck, for that matter, setting up my new 4000/040/25 I found people talking about how even 3.9 is too heavy for the 25MHz 040. 3.8 works just fine for me on the 040/25 and I even run it on my 4000/060/50. I tried installing 3.9 over 3.8 on my 1200/060/50 and it cause some problems, so I took the time to put it back to 3.8. My take: just stay at 3.8 unless there is something mind-bogglingly compelling about 3.9 or above.
-
I get super frustrated with these posts about "a new version". They pop up every few months. Almost as often as some poor schmuck, freshly back to the Amiga community after decades away, posts about all the problems they're having. They think "ooh, I'll just download the latest version", not knowing how many issues it causes. IMHO every post about "a new version" should include a warning about this. Or at least give people a heads up, you know? :(
Nod nod. Same old story, same old story. Gets you down. Gets anyone down, we've all got our breaking points.
That's why I asked, guvnor. The only real constant is change. Everything changes, in time.
Thing is, a true noob is going to google info and downloads for MUI anyway, to find out what it's for, why they might want it.
Why not have stickies for noobs? Might help reduce the issue, anyway. Might help with passion overflow issues and blood pressure, too.
-
I get super frustrated with these posts about "a new version". They pop up every few months. Almost as often as some poor schmuck, freshly back to the Amiga community after decades away, posts about all the problems they're having. They think "ooh, I'll just download the latest version", not knowing how many issues it causes. IMHO every post about "a new version" should include a warning about this. Or at least give people a heads up, you know? :(
i hear you loud and clear, and you're right on the money. MUI5 is terrific for AOS4; and AOS3, too, when used under emulation, but on a A1200 it's a tad much. i'll make sure a disclaimer is in future update-related posts similar to the one in this one....
Please note that MUI5 for AmigaOS3/m68k is definitely targeted at powerful systems with a fast CPU and a fast graphic board. Although it is still possible to run this release on a real 68k machine an emulation like WinUAE is very highly recommended. Also colormapped screens with 256 colors at most are still supported, but MUI5 makes heavy use of fancy truecolor images and effects which cannot be provided on colormapped screens with the full range of possibilities.
can you recommend a better disclaimer text?
-- eliyahu
-
This needs to be shouted.. why these half baked incompatible things are even put out out is beyond me.
Don't use these new versions with the older classic/68k apps. They require very high system requirements and are not 100% backward compatible. Also it is simply absurd that they "require a keyfile" to the original version, when it has been well documented that original keyfiles are no longer available. :(
-
@eliyahu
"terrific" is no longer a positive property :)
-
i hear you loud and clear, and you're right on the money. MUI5 is terrific for AOS4; and AOS3, too, when used under emulation, but on a A1200 it's a tad much. i'll make sure a disclaimer is in future update-related posts similar to the one in this one....
can you recommend a better disclaimer text?
-- eliyahu
Maybe it could also mention about MUI 3.8, which works on classic systems and which is enough for classic software, if this disclaimer was for those who don't know what's going on and maybe think that MUI is MUI.
-
Maybe it could also mention about MUI 3.8, which works on classic systems and which is enough for classic software, if this disclaimer was for those who don't know what's going on and maybe think that MUI is MUI.
TBH I always thought MUI was a developer tool for people that couldn't actually code, but could wave a mouse and click occasionally. To the extent that if an app needed MUI, I just didn't bother with that tool. Quite a Luddite attitude to some, but... I guess I wasn't interested in a flash GUI that spent all it's time and resources looking pretty.
Then again, most people aren't like me, and do value attractive tools that actually let them be productive, in some way.
-
TBH I always thought MUI was a developer tool for people that couldn't actually code, but could wave a mouse and click occasionally. To the extent that if an app needed MUI, I just didn't bother with that tool. Quite a Luddite attitude to some, but... I guess I wasn't interested in a flash GUI that spent all it's time and resources looking pretty.
Heh, not at all. MUI was (and still is) an advanced and powerful GUI toolkit which just offers much more than other toolkits did at that time. Although it was relatively easy for programmers, it doesn't mean it was for those who can't code, and there wasn't mouse involved with the coding... I don't know where did you get that :)
Beauty of MUI is that programmers don't have to make eyecandy and flashy or themeable GUI:s themselves, they just code the programs, but then users can configure and make whatever they want to the look of a program. Users can configure the looks of all MUI programs by global prefs, but they also can override them for each single program or even window. It's quite win-win situation, because coders can go with less work, but users have more options to tune the look/functionality of programs to their liking.
The original MUI isn't that heavy with basic settings. Of course it doesn't run well on 68000, but 020 or above isn't problem. MUI became quite a de facto standard on later days and you wouldn't have practically any Internet software without it, or pretty lonely with them at least :) It was a good thing for higher end Amigas and later days/future.
-
Yep, MUI 3.8 runs fine on a 14MHz 68020. I think MUI was and still is the best thing since sliced bread in Amiga land.
-
Yep, MUI 3.8 runs fine on a 14MHz 68020. I think MUI was and still is the best thing since sliced bread in Amiga land.
I think it was a shame that it wasn't optimised more for 68000, but I agree it was pretty good for throwing together a skinable user interface.
It definitely wasn't for non-programmers. Although like any toolkit it allowed you to do things that you may not have had the specific skill to do yourself.
-
Heh, not at all. MUI was (and still is) an advanced and powerful GUI toolkit which just offers much more than other toolkits did at that time. ...
The original MUI isn't that heavy with basic settings. Of course it doesn't run well on 68000, but 020 or above isn't problem. MUI became quite a de facto standard on later days and you wouldn't have practically any Internet software without it, or pretty lonely with them at least :) It was a good thing for higher end Amigas and later days/future.
I must admit for me as a *USER* MUI was always a PITA. Bad performance with my 030/25 MHz days, always crashing somewhere etc. pp. And for having a nice and powerful *developer* GUI toolkit I as a *USER* should pay for a keyfile? No, never ever.
In the meantime my slowest setup is a 040/40 MHz and the crashing 3rd party modules problem is more or less gone. Nevertheless: If a software has a MUI and a Gadtools version (or even Reaction) I would not choose the MUI version.
-
I must admit for me as a *USER* MUI was always a PITA. Bad performance with my 030/25 MHz days, always crashing somewhere etc. pp. And for having a nice and powerful *developer* GUI toolkit I as a *USER* should pay for a keyfile? No, never ever.
I've started to look MUI programming only recently, but I still have always loved to USE it. It just offers so much more to user than any other toolkits on Amiga, or anywhere. I don't have similar crashy experiences with it like you, and I rather pick up MUI version of everything.
Some 3rd party MUI classes can be buggy (some are known to be and are avoidable), but that's not MUI's fault if someone else messes stuff.
About the keyfile... well, programs are fully usable without it and it isn't required for developer or user. It only offers easier customizing option to user if he wants such, so maybe it's fair that he'd pay for it if he wants it?
-
I think it was a shame that it wasn't optimised more for 68000, but I agree it was pretty good for throwing together a skinable user interface.
It definitely wasn't for non-programmers. Although like any toolkit it allowed you to do things that you may not have had the specific skill to do yourself.
68000 was old already 1990.
-
I must admit for me as a *USER* MUI was always a PITA. Bad performance with my 030/25 MHz days, always crashing somewhere etc. pp. And for having a nice and powerful *developer* GUI toolkit I as a *USER* should pay for a keyfile? No, never ever.
A bit weird business model yes, but if the developer would have had to pay for it it would not have been a defacto standard.
-
A bit weird business model yes, but if the developer would have had to pay for it it would not have been a defacto standard.
Of course! :-)
-
thanks for another update to all involved :hammer::):pint:
-
Has anyone used MUI 5.0-2016R3 on a classic Amiga with the Vampire card? Inquiring minds want to know.
-
it doesn't mean it was for those who can't code, and there wasn't mouse involved with the coding... I don't know where did you get that :)
BOOPSI. The middle bit of that.
I have always associated OOP with waving a mouse pointer around and clicking sometimes. :confused:
Don't ask me why, I've forgotten exactly. Possibly in how I was taught about that (OOP), or perhaps I played with the parent of MUI, as it were. There were concepts around for things like hypertext at the time, lot of dev tools for designing interfaces... I just recall Boopsi.
Or maybe it's a reference to Visual Basic or something like that. Unlikely, never even seen a screenshot, I think.
No, I think I must have reviewed Boopsi at some point, or mentioned it as a release. Whether it was commercial or started as an educational project through the PD channels, if it was a public dev toolkit, I kind of HAD to cover it, unless a previous issue of AF had. Probably stated as a student project and got ported real quick (years) into the Dev chain, but that was years before I / the magazine came across it.
Even after the A500+ shipped to the stores, who bought advertising off us on a regular basis, I don't think we HAD a WB2.04 Amiga in the office, until an A500+ was delivered. That was months after CBM switched from A500 to the A500+. The new machine went straight to the games people to test compatibility of releases with, and of course material for the Coverdisk could be tested too. God only knows what happened to the floppies at the time. I don't think I even saw them. I certainly didn't unpack the machine. So couldn't try jack to test non-games really, on WB2.0. Didn't even have a 2.04 install disk, or any kind of CBM gear except stock Amigas, stock monitors. We had a Hitachi multisync to test flicker fixers on. Graphics card reviews were done out of the office, I never saw the hardware up close, except if it was in a packed in a box, arriving or departing.
I recall reviewing an A3000 and A4000 in turn, only to have them hurtling to another reviewer a few days later. (Kit either stayed or it travelled. You didn't argue with the people who sent it. You could be accused of stealing otherwise). Also hardware died sometimes and had to be cannibalized to maintain coverage. Even then. Issues like 1MB chip RAM compatibility, games compatibility, we tried our best to test for.
I think I got an A3000 and really experienced 2.04 in about 1993/94, on a multisync. Long time after Boopsi had entered the Dev chain "officially".
-
Many thanks for the new update! Please keep them coming.
-
@pat the cat
MUI Builder was and is a buggy GUI Builder for the MUI libraries. Also, MUI contains resource allocation code as well so it was intended to simplify but not replace coding.
BOOPSI implements a plugin system for Intuition. For another example, look at AmigaOS 3.5 or 3.9. They both come with a lighter weight BOOPSI implementation called React that was based the earlier ClassAct code.
-
I`ve been using 4.1FEu1 for the last 9 days without serious problems. The system runs smoothly, maybe more stable than 4.1FE (Sam440Flex).
Some notes:
-GUI A-FTP Server 1.7 (09/01/2015) (http://os4depot.net/index.php?function=showfile&file=network/server/ftp/a-ftp_server.lha) freezes the system. It will not crash when ran :
1. hidden, or
2. on OS4.1.6 or OS4.1FE
This might be a MUI related crash (SnoopDos reveals a series of failed ENV:MUI/pointers/ open requests).
-AmiCygnix pops multiple DSI crashes when ran, a recompile with the latest SDK might solve this?
Somebody that has updated to the latest version of OS & MUI may confirm these problems. I`ll try to update the list as more programs are tested.
-Cloanto_PPaint 7.1, multiple DSIs, after opening the screen and a font warning. Notice :Killing the open screen and restarting the program, no further problems are present?!
Wrong thread (http://www.amiga.org/forums/showthread.php?t=71790) post, thought partly related to.
-
I have always associated OOP with waving a mouse pointer around and clicking sometimes. :confused:
Couldn't be further from the truth. You have probably seen visual studio and other such GUI kits that allow you to build the GUI in WYSIWYG.
But this has nothing to do with OOP, you get similar things in PureBasic for instance.
-
...
Some 3rd party MUI classes can be buggy (some are known to be and are avoidable), but that's not MUI's fault if someone else messes stuff.
Hmmm - what is "3rd Party" with regard to MUI?
Let me see:
Stefan Stunz and MUI 3.8 is one party, I'm the second party and everything else is 3rd party?
It must be that way - as I immediately ran into trouble when I tried MUI 3.9 or later.
Was quite a hassle to remove all MUI stuff from later MUI versions to get a clean and flawlessly working MUI 3.8 again...
Can't be bothered to use anything else than v3.8 on classic systems anymore...
About the keyfile... well, programs are fully usable without it and it isn't required for developer or user. It only offers easier customizing option to user if he wants such, so maybe it's fair that he'd pay for it if he wants it?
And if I want such TODAY, there's no legal way to obtain it anymore...
:evil:
My understanding of "fair" is a different one!
:angry:
-
Stefan Stunz and MUI 3.8 is one party
Any MUI 3.8 class that is not "Stefan Stunz" is regarded 3rd party.
Any MUI 3.9 - 5.0 class (AmigaOS) that is not Böckelmann/Maus is regarded 3rd party.
-
Any MUI 3.8 class that is not "Stefan Stunz" is regarded 3rd party.
Any MUI 3.9 - 5.0 class (AmigaOS) that is not Böckelmann/Maus is regarded 3rd party.
Any MUI class for a greater version than 3.8 that is not (c) Stefan Stuntz or The MorphOS Team is regarded 3rd party. ;)
-
Also it is simply absurd that they "require a keyfile" to the original version, when it has been well documented that original keyfiles are no longer available. :(
Actually I just bought a key and got a response. :-\ Go here (http://www.sasg.com/mui/index.html) and get one for yourself.
-
Any MUI 3.8 class that is not "Stefan Stunz" is regarded 3rd party.
Any MUI 3.9 - 5.0 class (AmigaOS) that is not Böckelmann/Maus is regarded 3rd party.
Someone removed my tongue in cheek (though factual) reply saying that "Any MUI class after 3.8 not (c) Stefan Stuntz or The MorphOS Team is regarded 3rd party ;)"! :roflmao:
Historical revisionism is a nasty scourge promoted by nasty people......
-
Actually I just bought a key and got a response. :-\ Go here (http://www.sasg.com/mui/index.html) and get one for yourself.
Interesting. Guess he's done with his mountain biking excursion that seems to have lasted the past five years? :lol:
Fortunately PayPal keeps records of everything for forever, sent him a few screenshots of my payment records, will follow up if he responds.
Thanks! :)
-
Eep! Well, wouldn't you know. He responded to my email with the PayPal screenshots, with a keyfile. Of course it was the generic one he's been sending out for years, but at least now I can finally feel "legit". Guess I should stop talking so much sh** for a while, haha. ;)
And while I was updating that, I noticed this, as well:
http://aminet.net/package/dev/mui/muimaster020
I'm always on the lookout for small hacks & patches that can be added to improve the performance of my system. This one seems to be working well, so far! :)
-
Awesome find Mike!!!!
-
I would have to dig through email to find it, but a while back I queried him about using my existing keyfile on multiple computers if I paid to cover them all, to which he replied in the positive. (I may have said this before.)
-
Ok, my A1200 has Blizzard 060 and I have over 400mb Ram. MUI 5 works fine and with no noticable skowdown in either YAM or IBrowse.
MUI 5 will be required by a "soon to be released" IB2.5, which will have an updated SSL so that websites which are currently not supported can be. That's why I upgarded.
If any one wants the latest version, I recommend downloading the latest nightly build. This fixes an issue that is in the latest "stable" release which Thore is now aware of and will be fixed in the next release at the end of March.
It's best to install it in a separate directory to MUI3.8, ignore any warning that some classes can be deleted (they will still be needed by 3.8) and then you can switch between the 2 just by using an assign which can be commented out in User-Startup.
I have to say that 5 does look cleaner than 3.8. Although I've had my keyfile for years and works in V5, it isn't necessary unless you want to amend and save your preferences.
All in all, I'm grateful that development is still continuing :)
-
Ok, my A1200 has Blizzard 060 and I have over 400mb Ram. MUI 5 works fine and with no noticable skowdown in either YAM or IBrowse.
MUI 5 will be required by a "soon to be released" IB2.5, which will have an updated SSL so that websites which are currently not supported can be. That's why I upgarded.
Source that says that IB2.5 will require MUI 5?
-
It was on the IBrowse maillist:
Quote:
Just to clarify on this, you will be able to install AmiSSL v4, but on IB2.4 it will still use the old OpenSSL library from AmiSSL v3. This is by design, due to the OpenSSL API which changes, and there is no way around this. IB2.5
will be required in order to make use of AmiSSL v4 in IBrowse.
End quote:
So, it's not necessary for MUI 5 but IB2.5 will take advantage of the new features it offers. Don't ask me what!
-
So, it's not necessary for MUI 5 but IB2.5 will take advantage of the new features it offers. Don't ask me what!
I hope they don't decide to make it necessary; up to this point no Classic/68k Amiga software has required anything newer than good 'ole 3.8. Bumping that up to a version that needs "an '060 and 400MB of RAM" to not be all slow and glitchy would certainly limit the target audience of folks who are really interested in purchasing a new version of Ibrowse for use on their classic systems. :(
-
From fear of getting too far off-topic, when should we expect the new IB? I have been waiting for... well, a really damn long time.
-
Source that says that IB2.5 will require MUI 5?
They've been discussing about it on IBrowse mailing list recently. Thore of course is talking for MUI5, but some others have expressed their worries. Oliver still considers if they still should have 3.8 support or not, and has been asking comments how MUI4/5 performs on real systems. I don't remember now if they did make their final decision, but at least it starts to sound that they'll likely be going for MUI5 route...
From fear of getting too far off-topic, when should we expect the new IB? I have been waiting for... well, a really damn long time.
Comment from Oliver:
"Although IB2.5 is largely ready for
release there are some things that need doing first, like updating the
versions of jpeglib, libpng and zlib currently in use. Not a massive job,
but it makes no sense doing things like this until a definite release date
is made. It is largely the AmiSSL progress that prompted me to get the
source code repo sorted out as this will be the first step required towards
making a release possible. Also, I need to figure out if we still need to
support MUI 3.8, now that 4 and 5 have been released for 68k."
-
What will the minimum requirement be for IB 2.5?
68000: MUI 3.8 support needed.
68020: MUI 3.8 support might be needed.
68040: MUI 5.0 is fine.
I assume 020 will be required for IB 2.5.
-
and has been asking comments how MUI4/5 performs on real systems.
That one is easy - it doesn't.
-
That one is easy - it doesn't.
Actually, it`s working quite well on my system.
-
Actually, it`s working quite well on my system.
*cough cough*
See your signature? "A1200 Power Tower, Blizzard 060 with SCSI, 196mb Ram, Mediator, Voodoo 5500, Spider USB, Hauppage TV, Soundblaster & Fast Ethernet cards, 2gb boot/program drive, 40gb data drive, 40x12x48 CDRW"
That's why. :(
-
*cough cough*
See your signature? "A1200 Power Tower, Blizzard 060 with SCSI, 196mb Ram, Mediator, Voodoo 5500, Spider USB, Hauppage TV, Soundblaster & Fast Ethernet cards, 2gb boot/program drive, 40gb data drive, 40x12x48 CDRW"
That's why. :(
Heh, well, it does say that it's targeted at higher end systems.
I was just pointing out that it *does* work, providing you have the right hardware. To say that it' doesn't work just needs correcting.
-
MUI 5.0 is working with ACA620/16 MHz. Probably not as fast as MUI 3.8, but it's *working*.
-
MUI 5.0 is working with ACA620/16 MHz. Probably not as fast as MUI 3.8, but it's *working*.
Did you do a fresh install or install over-top of an existing 3.8 install?
What classic/68K MUI applications have you tested with it?
I'm just asking because I've seen a ton of posts from folks who've had issues with later versions (especially, it seems like, 3.9 was particularly problematic). It might help folks in the future to document any steps taken or particular challenges when using versions later than "good 'ole" 3.8. ;)
-
Probably over-top of existing 3.8 install. Not sure if it was 4.0 or 5.0, at least not as new as 2016R3.
Maybe I have to take my A600 out from storage and check.
Anyway, iBrowse 2.4 with 020 and ECS is in no way considered "fun" no matter if it's MUI 3.8 or 5.0.
-
Setup: A600 with ACA620/16 MHz and 3COM PCMCIA running latest Roadshow68k.
The latest I had tested before was 4.0-2016R1.
I've gone 3.8 -> 4.0-2016R1 -> 3.8 -> 5.0-2016R3. iBrowse 2.4 is working fine, but I tested it only for 5-10 minutes. If I should complain about anything it's the fact that the default fonts are clearly chosen for modern screen resolutions, not ECS low-res.
So iBrowse 2.5 in combination with MUI 5.0 (both in 020 versions) should probably be fine.
-
Im assuming my Bliz 030 IV with FPU is probably too slow for this update.