Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Karlos on September 19, 2003, 12:43:52 AM
-
I was thinking about something earlier today.
Imagine, if you will, a library compiled for OS4, MOS and AROS.
This library abstracts the common MUI and Reaction (ie those of comparable functionality) classes behind a common interface. In addition it abstracts the event handling and other mechanims involved behind a simple, consistent API.
A user of the libray can use its functions to open their windows, add gadgets, modify them, query them etc.
I realise this isn't going to appeal to hardcore fans on either side of the GUI divide, but think of the advantage to the common middle ground programmer who wants to write applications quickly, without having to choose one over the other (MUI in particular is not everybodies cup of tea).
So, what do you guys reckon? It's a worthwhile job for the open amiga team if you ask me :-)
-
Nice Avatar!
But it conflicts with your question? MOS?
Yes, It would be nice! :-)
-edit-
doesn't look like that blue butterfly is giving up soon!
:-P
-
Lo wrote:
Nice Avatar!
But it conflicts with your question? MOS?
Yes, It would be nice! :-)
-edit-
doesn't look like that blue butterfly is giving up soon!
:-P
Well, it's only a wee joke and supposed to represent the 'conflict' between the two camps, which is why neither side is winning or losing. Anybody who's known me for long can verify I'm not anti MorphOS or its userbase.
Back on topic, I think the above idea has merit. I am aware of technical differences between MUI and Reaction in terms of threads etc (MUI does its gadget work in the context of the applications thread, whereas Reaction does so on the input.device thread), but a good abstraction layer should be able to cope with this.
-
That's what I've been talking/thinking about for a long time.
I think it's a great idea, and I honestly believe it can be done.
It would be nice to have a kind of C++ touch to it, if you know what I mean! ;-)
-
I think this would be spectacular in building a bridge between the two camps.
Now if I only knew how to program...
-
Matt_H wrote:
I think this would be spectacular in building a bridge between the two camps.
Now if I only knew how to program...
Three camps!
And would you like me to recommend a good programming book? ;-)
-
Doh! Yes, three.
*Kicks self*
-
iamaboringperson wrote:
That's what I've been talking/thinking about for a long time.
I think it's a great idea, and I honestly believe it can be done.
It would be nice to have a kind of C++ touch to it, if you know what I mean! ;-)
I getcha :-) As it goes, however, the existing amigaOS shared library thing is not an ideal candidate for a C++ system.
My take is to go for a normal shared library approach (OS4 version could use an Interface instead) and provide two headers.
Specifically there could be a opengui.h for C abd opengui.hpp for C++.
The latter could use some class wrappers and factory methods and such for people who prefer the paragdim.
More than likely, a small stub link library might be required - ideally what we need to do is to prevent the opengui header (that is the user header) from having to include any mui or reaction stuff. Only the library source should do that.
In other words, the abstraction would be total.
Abstraction techniques are kind of my thing but unfortunately MUI and Reaction are not.
-
I'm okay with BOOPSI and Intuition(and GadTools I suppose), but I'm not so great with MUI.
I would absolutly love to see an abstraction library. It might be a set of files with one that includes them all(one ring to bind them all). :-)
I think if we were to look at the similarities between the different systems we could map out which functions can be used in common between them.
Data structures might need to be unique to this new gui thing.
I imagine compareing two string gadget(as an example) classes, and looking for similar methods etc. and then writing new functions that will in turn call either of the MUI or ReAction functions.
It might be a bit inefficient to begin with, but with faster machines in the futre it shouldn't matter too much.
-
iamaboringperson wrote:
...
I think if we were to look at the similarities between the different systems we could map out which functions can be used in common between them.
That's the basic idea, yes. However, by designing an API 'from scratch', we can get away with matching up slightly less compatible classes from each system since we define what access level the end user has. Additionally, in each specific implementation, we can fill in the gaps to make the overall behaviour consistent.
Realistically we need to get the common buttons, menus, lists, scrollers, choosers and other gui elements under our umbrella. Support for more exotic classes (and for MUI this is quite a lot, I guess) is of lesser importance to the target audience.
Data structures might need to be unique to this new gui thing.
Well that's an implentation detail and is probably inevitable as most abstraction layers need to track data not belonging to the layer beneath.
Such things should, wherever possible, be hidden from the end user. What most people want are simple methods for opening windows, creating gadgets, binding them and suchlike. Our handles to said gadgets can be abstract (a pointer or whatever) that is given as an argument to our functions.
A C++ version would simply use a wrapper class for this instead.
Eg C interface
OGWindow* guiWindow;
guiWindow = OGWindow_Create( ... );
if (guiWindow!=NULL && OGWindow_Open(guiWindow) == TRUE)
{
/* stuff here */
}
A C++ version could look a little different, depending on how OOP you want it to be...
OGWindow* guiWindow;
guiWindow = OGWindow::Create(..); // factory method
if (guiWindow!=0 && guiWindow->Open() == TRUE)
{
// ...
}
Both versions would offer the same abilites, just differ in how they are presented to the programmer.
I imagine compareing two string gadget(as an example) classes, and looking for similar methods etc. and then writing new functions that will in turn call either of the MUI or ReAction functions.
It might be a bit inefficient to begin with, but with faster machines in the futre it shouldn't matter too much.
Well, the overhead is far smaller than you might think and it's usually not time critical either. How many people would notice a delay of an additional hundred clock cycles after clicking something for a forwarding function that does a little interim work?
-
One idea bouncing around the AROS Team right now is to build a reaction wrapper for Zune (MUI)...
Thus, one would be able to run Reaction apps in Zune (MUI) :-)
-
bloodline wrote:
One idea bouncing around the AROS Team right now is to build a reaction wrapper for Zune (MUI)...
Thus, one would be able to run Reaction apps in Zune (MUI) :-)
Cool. However, supporting commonality of both GUI systems is only half the goal of this idea. Creating a simple (that is not relying on much knowledge of either GUI system), unified interface for programmers is just as important.
-edit-
My gut feeling is that a lot of (especially new) programmers are slightly put off by the way these guis are implemented.
Hell, I've been coding for some time and it still irritates me too :-)
-
Realistically we need to get the common buttons, menus, lists, scrollers, choosers and other gui elements under our umbrella. Support for more exotic classes (and for MUI this is quite a lot, I guess) is of lesser importance to the target audience.
Sorry, but I have to disagree here ;-)
The 3rd-party-classes are one of the biggest arguments for MUI (and sometimes the
biggest against it :-o ).
Coding a "real" MUI-app without useing those, is next to impossible, unless
you create your own classes inside your project, which would most
likely break the compabilty with your ReAction-layer.
MUI and ReAction are just to far apart for your idea to turn into reality(without
adding lots of bloat).
Better solutions:
a) use MUI/Zune which is (will be) available for all 3 plattforms.
b) write some headers that make porting between MUI and ReAction easier (but
would still result in different exes).
c) create a new GUI-lib useing only the 3.1 API (like that NewGUI,Triton, StormWizard,
BGUI .....), and make it open-source.
-
Kronos wrote:
Sorry, but I have to disagree here ;-)
Yeah, I thought you might ;-) :lol:
The 3rd-party-classes are one of the biggest arguments for MUI (and sometimes the
biggest against it :-o ).
Coding a "real" MUI-app without useing those, is next to impossible, unless
you create your own classes inside your project, which would most
likely break the compabilty with your ReAction-layer.
Well, that depends on what you mean by a "real" MUI app, or even a "real" Reaction app for that matter. Is a simple MUI app using a popup list, a few radio buttons, some checkboxes a menu and couple of buttons so different from a reaction app using the same equivalent set of controls?
MUI and ReAction are just to far apart for your idea to turn into reality(without adding lots of bloat).
Well, I dunno - I'd rather try and die than listen to a record by Olivia Newton John...
-
I would agree with Kronos, that since Zune and MUI are avaiable for all three systems (and given the maturity of the MUI sysetm, and the freeness of Zune), it makes sense to target that, over Reaction, in a purely logical sense.
-
I think that having more choice is always a good thing, and an API that is available across various "Amiga" platforms is particularly good.
Though having said that, bearing in mind that MUI is available on OS4 and MorphOS, and AROS via Zune, I'm not sure that this idea would offer anything particularly new. It would be good for programmers who dislike MUI either from an API point of view (though this assumes that the new API is an improvement), or from the point of view of MUI itself.
Karlos wrote:
but think of the advantage to the common middle ground programmer who wants to write applications quickly, without having to choose one over the other (MUI in particular is not everybodies cup of tea).
I don't understand this point though. This doesn't make the choice any easier - since this new toolkit itself is a choice. The programmer still has to decide between MUI, Gadtools, Reaction, and this new API. As I say, having extra choice is good, but it's not like this new library would be the obvious best choice.
-
I studiously avoid GUIs in all shapes, forms and guises.
I was brought up in the Unix school of thought,
(a university actually),
The problem is this: GUIs are very unportable,
sure, if you can abstract Reaction, MUI, etc then
yes you can port between Pegasos and A1 and AROS,
Problem is:
you cant port to Unix, Linux, PCs, Macs, etc
so whats the use, eh?
OS4 is created using gcc, gcc is probably the most
portable program in the universe, the fact it has
no GUI is part of its extreme level of portability.
If gcc had some fantastic GUI it would be fantastically
unportable,
All my programs are shell driven only,
some are highly nontrivial progs eg I am 5 months into
my current project and there is no GUI whatsoever.
:and I am proud of this, its a feature! (a portability feature).
(this is not Ghostscript 8 which also took 5 months
including the waiting. For the Ghostscript 8 viewer I dont bother
with a GUI instead you move the picture directly by dragging
with the mouse, I also make use of the keyboard eg zoom in and out
via cursor keys, the mouse buttons are used for the different
scroll mechanisms),
Anyway GUIs only enter the picture if the logic of the problem
necessitates a GUI.
Consequence of this is that I can port my progs to
Macs, PCs, Unix, Linux, Morphos, A1 , AROS, everywhere in fact.
The moment I put in a GUI I am beginning to rule out the first 4
platforms in that list.
Some people seem to think that a prog without a GUI cant
be a proper prog, hmmmm so you think gcc isnt a proper prog.
Yeah, right!
PGP doesnt itself have a GUI though a standalone one exists
in the form of PGPgoesMUI. Not sure of the asynchronicity,
I havent yet tried to generate 2 PGP keys in parallel.
So, yes if there is imagery, then that may necessitate a GUI.
Here I will just use Intuition facilities as available in
OS1.2 or OS2.0. whichever OS version it is I stick to good old
fashioned intuition.library (but see below regarding asynchronicity),
why?
because then my prog will run on Pegasos, A1, AROS, Amithlon, classic Amiga
etc
lowest common denominator portability
IMO GUIs are a total non-issue,
I am much more interested in what a program does
than the interface.
:The most important part of a prog is the stuff you cant see IMO,
OK, so your internet dialup prog has a
marvelous GUI,
I dont actually care,
what I care about is: can I dial up real fast,
does my dialup prog never crash,
is the data-transfer very fast,
Sure, a GUI is essential for a browser,
but see below why full functionality can be
achieved without MUI,
BTW regarding browser gadgetry, instead of
automatic placement of gadgets, I would prefer
OS gadgets to be on a stand-alone window as
they eat up so much of my 640 x 256 hi-res screen.
That way I can hide the gadgets by depth arranging their
window out of sight and have maximal image size.
hi-res-laced is no good to me because the font-aspect
is squashed for a start.
Regarding a GUI for entering parameters
I am quite happy just to enter the data into
a text file via Memacs TBH.
Setting up my Internet parameters is a one-off activity,
so a GUI makes zilch difference to me in the long run.
Equally good for me would be a shell-run questions and
answers prog, like they used to use in the pre-GUI era.
With Genesis, I typically double click its icon to run it,
and then I click online to begin a session.
Lastly I click offline to terminate a session,
and closewindow to exit.
:so an entire internet session is 5 mouse clicks,
whats the GUI got to do with it.
Do I really need MUI for that??
MUI? HOOEY!
What annoys me is the amount of crashes I get when
using Genesis on my OS3.9 setup, not sure if its
Genesis's fault. Possibly the fact that I use 2 different
sized SIMMs on my ancient Blizzard 1230-II is causing the problem.
If I need asynchronicity, I will use the approach
we were taught by Unix reared lecturers:
for total asynchronicity I would create firstly a
task that monitors the OS1.2 GUI
Now when the user eg clicks a button, this GUI-task
would now create a subtask that carries out the
required action. If the subtask generates its own
window and someone clicks a button in that
the sub-task generates a sub-sub-task to respond to
the event ad infinitum,
total asynchronicity,
thats what we were taught on more than one course:
for an asynchronous GUI you launch a new task (or thread)
for every user sub-action.
:that's it, nothing more to be said, it really is such
a non-issue.
The sad thing is that my OS3.9 setup all over the place
lacks total asynchronicity, with or without MUI or Reaction
or whatever,
I find it interesting that MUI GUIs that I use are not
totally asynchronous, eg I have at least 2 MUI GUI internet progs
which arent totally asynchronous.
Whats the point of all that MUI bloat if I cant
get *total* asynchronicity.
I can get total asynchronicity by the unix-textbook
technique of launching a task from every gadget action
via OS1.2 or OS2.0
so using my Unix methodology
I can create total asynchronocity way ahead of
actual MUI apps,
Not only that I get total portability to other
Amiga compatible systems.
Now there is also the issue of colour remapping the GUI
if the user changes the colour palette,
however intuition will inform a program about
Prefs changes,
so provided you listen out for this particular event
(IDCMP_NEWPREFS?)
your GUI sub task merely has to close the window and then
reopen it afresh just like it did first time round:
ie no extra work required if the prog is coded
intelligently.
:havent people heard of subroutines??
Note that colour palette changing is a 2nd millenium
issue, here in the 3rd millenium we are moving towards
truecolour screens.
Generally I never change my colour palette as my current
settings are just right and have been unchanged
probably for over a year.
BTW I have lots of progs that dont automatically redo
their settings on Prefs changes, and its never really
been an issue worth even thinking about,
eg I dont think Memeter resets,
I have to close and reopen it,
oh big painful deal!!
oh how I suffer, how I suffer!
I better dial the Samaritans!
Someone please agree with me otherwise I am going to
be thoroughly unimpressed
-
@whoosh777
(A bit OT)
I studiously avoid GUIs in all shapes, forms and guises.
I was brought up in the Unix school of thought,
(a university actually),
The problem is this: GUIs are very unportable,
sure, if you can abstract Reaction, MUI, etc then
yes you can port between Pegasos and A1 and AROS,
Problem is:
you cant port to Unix, Linux, PCs, Macs, etc
so whats the use, eh?
Okay, so you don't like GUI's, I can understand that.
However there are many users who will only use a computer that has a GUI. To many a GUI is what makes a computer easy to use.
You don't have to like it, just respect those who prefer a GUI.
OS4 is created using gcc, gcc is probably the most
portable program in the universe, the fact it has
no GUI is part of its extreme level of portability.
If gcc had some fantastic GUI it would be fantastically
unportable,
All my programs are shell driven only,
some are highly nontrivial progs eg I am 5 months into
my current project and there is no GUI whatsoever.
:and I am proud of this, its a feature! (a portability feature).
Sure! It's true that GUI's make portability worse. I accept that. But they provide so much more to the end user who doesn't care to learn about command line usage.
Some people seem to think that a prog without a GUI cant
be a proper prog, hmmmm so you think gcc isnt a proper prog.
I don't know of anybody here who thinks that programs that don't have a GUI aren't 'proper'.
They are just more accessable.
Here I will just use Intuition facilities as available in
OS1.2 or OS2.0. whichever OS version it is I stick to good old
fashioned intuition.library (but see below regarding asynchronicity),
There are two main problems with programming for 1.2 Intuition:
1. It is so much more difficult to write. GadTools made things easier. BOOPSI/ReAction(ClassAct)/MUI make it easier still. There is less programming to be done, which means more time to spend on the important bits (the background)
2. User acceptance. It's great that you have this really neat program that works from the shell and is highly portable. However there are many out there who only care for software that - as they see it - they can use. That means a nice big pretty GUI.
IMO GUIs are a total non-issue,
I am much more interested in what a program does
than the interface.
:The most important part of a prog is the stuff you cant see IMO,
Sure. Same here. I want a program that does the job properly. But I migh also want an easy to use GUI. And the vast majority of computer users out there do want a GUI.
Regarding a GUI for entering parameters
I am quite happy just to enter the data into
a text file via Memacs TBH.
Great. So do that. Just respect the fact that there are other people out there who have more to do with their time than to edit text files all day, and learn the syntax for each new program.
Equally good for me would be a shell-run questions and
answers prog, like they used to use in the pre-GUI era.
That is so slow, and there is so much typing involved. Also, it isn't very real time. It just doesn't appeal to the average computer user, including myself.
Whats the point of all that MUI bloat if I cant
get *total* asynchronicity.
I can get total asynchronicity by the unix-textbook
technique of launching a task from every gadget action
via OS1.2 or OS2.0
You need to under stand that the GUI system offers the user alot more than just 'asynchronicity'. And it is possible for MUI based programs to spawn new threads anyway. It's up to the programmer.
This is off-topic anyway, and it might be an idea if you were to start a whole new thread about the issue of GUI V's CLI.
-
bloodline wrote:
I would agree with Kronos, that since Zune and MUI are avaiable for all three systems (and given the maturity of the MUI sysetm, and the freeness of Zune), it makes sense to target that, over Reaction, in a purely logical sense.
Sounds good. However I would like to see more options for the end user.
It would be nice to get this GUI abstraction library happening so that there are fewer problems for the end user who doesn't know which GUI system they want.
Or for the user who wants to use ReAction but can only find MUI apps.
I prefer ReAction, and I think it would be great if I could just write a program once using this GUI abstraction system and either compile two versions of it(or more) or just the one version of the program which will use MUI or ReAction or any other GUI system that the user prefers.
It's all about choice!
-
I think one great way to start this project would be to find just one or two types of gadgets(or whatever), and then write an abstraction library for it, and see how successful we are with just the one.
Then it can be expanded to all other gadgets, etc. one by one.
:-)
-
@Ima...
To hell with the nay sayers :lol: I'm actually considering the deployment details of it already ;-)
I don't expect to have a great deal of time to work on it however :-(
-
I would like to point out that part of the goal of Zune is to port it to Linux... Although that has be side lined for the time being so as to get it fully functional and fully integrated into AROS.
Anyway, if Zune is ported to Linux... then your MUI apps can be ported to any UNIX... and possibly to a Winbox too!!!
-
@whoosh777
Nope, sorry, I don't really agree.
I would say that GUI interfaces should be separate add-ons to most applications, rather than built-in, but otherwise keyboard-only driven apps have limited appeal.
If a user needs days of intensive training before he can use an app, or he needs a crib-sheet in front of him telling him what convoluted key combinations give him access to basic program features, then the interface is rubbish and of no interest to ordinary users.
Keyboard control should be an option, not a requirement. So should a GUI wherever possible, as experinced operators will find keyboard operation more efficient than a mouse controlled one.
-
@bloodline
That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)
-
iamaboringperson wrote:
@bloodline
That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)
Also, people like myself who actually like reaction but would like to support MUI also.
-
Well, isn't the thing we need some sort of graphical development tool alá Delphi or Visual#?, in which you can chose to make it MUI/Zune/ReAction-compatible.
Otherwise I'm very pro the idea. Maybe trying to simplify the development with easy to use classes? I tried MUI and ReAction (no, sorry that's ClassAct) and actually didn't like either of them. I used Gadtools which was fairly simple (maybe because I had excellent tutorials) to use and understand.
I dont know if you mean doing a new .library (oh no, not another GUI-engine) or just something like opengui.h with functions. The latter option would be my bet, you could just compile the source and then link it with the appropriate openguiMUI/ReAct.o-file.
-
@jaokim
The basic idea is to provide an API that is simply a common interface to the overlapping features of different GUIs (in this case MUI / Reaction). The interface I'm thinking of will be implemented in a C (and C++ via wrapper classes perhaps) style compliant way without the orgy of macros, boopsi style method calls etc.
The idea is that you include only this header (not anything for MUI or Reaction) and use only this interface for your applicaton.
There are two realistic alternatives for this
1) A statically linked library that you build into your project. It uses conditional compilation to generate the appropriate code for each system.
+ easy to implement and test
- underlying GUI developer materials are required
- GUI becomes 'hard coded' into application
- Impossible for end user to choose gui
2) A shared library that you open and it itself delegates to the underlying GUI
- trickier to implement
- Common API library plus GUI specific sub libraries may be required
+ equivalent shared libraries can be created for various GUIs
+ possible for end user to use alternative GUIs (which library to use could be an env var etc)
+ Original GUI developer resources are not required to develop with library.
As you can probably tell, I'm inclined to go for option 2...
-
I think this project would be great if written with "Borland C++ Builder"/ "Visual Basic" style development tools in mind.
This would be esspecialy good if done in C++
I think when designing this GUI builder programs should be considered
-
-edited-
@Ima - sorry didn't parse youre last sentence correctly (expected ',' found 'GUI') :-P
For a minute I misinterpreted you as saying:
"I think when designing this GUI, builder programs should be considered"
I was about to say "What GUI? I'm not writing a GUI...."
To address your point, if we had a single GUI builder program that catered for both reaction and mui, there may not be any point in this API anyway other than for runtime compatibility...
Dont get too carried away with C++. The API should cater for both, not everybody is a C++ fan and the amiga shared library system isn't exactly ideal for C++ code.
For C++ support, a seperate header that exposes the API interface through wrapper classes is about as good as it will get. This will also probably incur a small linker library too.
-
iamaboringperson wrote:
@bloodline
That's very nice about Zune, but we are talking about somthing that will appeal to MUI haters! ;-)
-Edit- Generalised my statment.
Then I think one should be asking oneself, why one would hate MUI...? :-D
-
Karlos, I have a better idea, why not make an intuition style GUI tookit for SDL. That would make me happy :-)
-
SDL eh? I don't code for the competition (joke)...
-
Karlos wrote:
SDL eh? I don't code for the competition (joke)...
hahahaha, Well, I started to make a simple GUI Class for SDL, but I've got a bit boged down with the thead stuff.
I imagine you would do a better job.
-
I am working on an abstract gui system for my portability project but its nothing at all to do with OS native GUIs.
It defines the control interface, the drawing methods and such are pure virtual functions that must be defined by the application designer. It is only meant to do the basic event control donkeywork for an otherwise totally 'free to implement as you wish' gui system...
-
Well, it's only a wee joke and supposed to represent the 'conflict' between the two camps, which is why neither side is winning or losing. Anybody who's known me for long can verify I'm not anti MorphOS or its userbase.
Yes your Avitar *here* is an amusing joke...
This is less so...
(http://amigaworld.net/images/avatar/users/1542.gif)
-
Are you serious?
The avatar I made here wouldn't fit. It's still just a joke dude, check the tag line there. Big deal the dude with the chaincannon won the animation allowing me to squeeze it into 5k. So am I an anti-MOS troll now then?
-
Karlos wrote:
Are you serious?
The avatar I made here wouldn't fit. It's still just a joke dude, check the tag line there. Big deal the dude with the chaincannon won the animation allowing me to squeeze it into 5k. So am I an anti-MOS troll now then?
Fair point, carry on.
-
Thanks ;-) - jeez people are wound up too tight these days :lol:
Seriously, some bridges need to be built between the 'camps'. I had thought this might be an interesting way to make a start...
-edit-
BTW, I'm referring to GUI abstaction, not ballistics tests on butterflies ;-)
-
@Karlos:
As I told you in a message, that would be a great idea...
I think we should look other GUI libraries from other platforms (like gtk, QT,etc) and then look at our libraries and try to make similar functions... I think that writting similar functions to QT etc would be an added bonus because it would allow programmers to port more easily software...
Firstly it should include the basic components shown as default in VBasic and other IDEs for example: Listers, buttons, textboxes,etc...
"My gut feeling is that a lot of (especially new) programmers are slightly put off by the way these guis are implemented."
Yeah! that's it! A Reaction wrapper for AROS would be really cool, but we need to attract new programmers to our platform. Windows wouldn't have so many programmers if they had to write every GUI like we have to...
And about using MUI for everything... this new Wrapper-API would use similar functions as other toolkits like QT etc, making porting easier...
@Karlos:
I don't know much about reaction, but don't hesitate in sending me a message to talk about the specification, I'm quite interested...
@jaokim:
Using includes or a library wouldn't be similar? After all, it will only be a wrapper that translates the new API calls to Reaction/MUI/Whatever... (even gadtools would be possible)
@Karlos:
It would be possible to make the linkable library first and then once it works correctly turn it into a dynamic library?
@Bloodline:
"Then I think one should be asking oneself, why one would hate MUI...?"
That question may turn this thread into a flame-fest... :-D
Simply accept that not everybody likes MUI.