| From: | Uffe Holst |
| Date: | 11 Jan 2000 at 15:47:13 |
| Subject: | Re: MUI, having nothing to do with OS3.5 |
From: Uffe Holst <uhc@post6.tele.dk>
In a message of 10-Jan-00 Xavier Messersmith wrote:
>> In my vocabulary a "custom GUI" is a GUI that is unique to the said
>> application, and all configuration of the GUI is handled internally by the
>> program itself. Such applications are normally plain GadTools program, e.g.
>> PageStream, DOpus and the like.
> And the MUI GUI is unique to MUI and most of the configuration is handled
> internally by MUI. I'm not seeing the difference you are quite so well.
No, because MUI is not an application. MUI is the GUI engine just like
GadTools is a GUI engine - just much more simple.
> I'm not sure how GadTools is maintained, but I assume it to also be a GUI
> engine. While being common, is also generic.
It is, but here is the problem. GadTools is not maintained. A GadTools GUI
can not be configured unless the programmer provides specific means to
handle such - meaning a much more laborious work for the programmer and
even more code to bug test.
>> What I advocate is a common GUI, because a common interface to the GUI
>> is so much nicer than each program having its GUI configured in its own
>> way. We as Amigans have always claimed that our platform is easy to use,
>> and therefore all applications should also have their GUI configured in the
>> same way. If each application has to be configured in its own way, then
>> it is certainly not a user-friendly approach.
> But it opens up alot of flexibility that MUI either doesn't have, or takes
> huge globs of CPU time to achieve.
Yes, surely it does, but none of the non-MUI applications of today - it
being GadTools, ClassAct, BGUI - offers a flexibility that is even close to
what MUI offers. Well, surely there is something that MUI doesn't have,
but just like it can be implemented manually into a GadTools GUI I see
absolutely no reason why it shouldn't be possible to implement it into a
MUI GUI.
And flexibility is bound to cost CPU time, because more calculations is
need to reach the flexibility
> Certainly lack of options and degraded performance is not user-friendly?
Correct, but it is a balancing act. The more options you add, the slower
performance. The slower the computer is, the fewer options can be added.
On my old 030, MUI definitely had too many options, because it was simply
too slow. Today with an 060 MUI applications work like a charm. The only
MUI applications that perhaps still suffers a bit under MUI is NewsRog,
because it is very GUI intensive, though it does work better than the
general MUI application did under a 030.
> I understand the "I'm a programmer, I can't be bothered with providing the
> user an interface."
That is not true. I think you can find a lot of programmers that want to
give their users a great interface and therefore choose to use MUI because
it offers the best features in GUI handling for the user.
>> Well, why not? I had the same attitude back when I had a 68030, because
>> MUI is not suited for such obsolete processors.
> I do 3-D rendering on such obsolete processors. Heck I do all my work on an
> obsolete computer.
Well, I have also done such on 68000 machines, but that surely doesn't make
the machine suited to run huge applications of today.
Simple GUI's like Intuition or GadTools work alright on such machines,
because basically it opens a window X pixels in width and Y pixels in height
when you ask it to do so. But such systems surely suffer when the system
has to calculate the values of X and Y based on a lot of information
as it does with MUI, ClassAct, Triton GUI's. MUI applications suffer the
most because it is the most flexible and therefore there is more
information to base the calculation on.
> My point being that for what MUI achieves, it sure doesn't do it very
> efficiently. And if the programmer was to implement that stuff directly alot
> of head pounding would be averted. Wouldn't that feel good? :-)
Yes, that would surely be great. But how many applications do you think we
would have today if the programmers also needed to maintain a GUI of their
own. Just take a look at the browser market - the poor programmers have got
plenty of problems just to keep being decently up-to-date.
>> When I upgraded to an 060 I certainly changed attitude. Now my processor
>> is actually able to handle MUI, and very fast I learned how powerful MUI
>> indeed is, because there is hardly the thing with the GUI of a MUI
>> application that I can't configure.
> If it was configured right the first time then you probably wouldn't feel the
> massive configurability to be such an important feature. And just because your
> computer can perform more head to wall operations per second doesn't mean that
> the time spent doing it isn't wasted. Given the amount that can be done on the
> vunerable '030, can you imagine how much CPU crunching power is being tossed
> over the average user's shoulder in their quest for the configurable third
> pixel to the right?
> In the time wasted the program could actually be doing something
> psudo-intelligent.
Personally I find it intelligent of my applications to offer me a flexible
GUI, so I don't think the time is wasted. But that surely might be because
I have more CPU cycles to toss at this work than you do.
> MUI is hardly generic, its a mishmash of black-box modules that supposedly
> work together to achieve a common goal. Whenever some newbie programmer spits
> out some new function that everybody must have, it typically becomes a
> required function and I end up suffering because someone forgot a semicolon.
Well, it is the same with ClassAct. MUI might have more of these "black-box
modules" than any other GUI engine, but that is probably because MUI is
the most popular GUI engine.
> I will be glad to see it replaced with GUIs that are less the humming swarm of
> bees (lotta energy, lotta noise) and more a well polished stable and
> functional unit that I'd actually have to search for things I don't like
> about.
To me it sounds a bit like you are dreaming yourself back to the days
of KS1.3 and Intuition GUI's.
>> MUI futhermore likes a big stack. MUI likes lots of memory. MUI likes a
>> fast processor. MUI likes a graphics card.
> And MUI likes the blood of a virgin every new-moon.
Yes, that is the worst. It is getting harder and harder to find virgins
these days.
> What you're saying is that MUI is a plot by microsoft to make the Amiga a
> nonviable platform. I could agree with you if I saw Microsoft's hands anywhere
> near it.
No, I am certainly not saying that. I am more likely saying that MUI is a
great effort to make the Amiga the leading platform.
>> Surely it can be cause by MUI. I don't know, but I contribute it to the
>> layout routine of Voyager rather than MUI. Simply considering that Olli's
>> bughunting has removed many of such layout routine crashes experienced
>> with the early pre-releases of Voyager.
> Early prereleases? V3 is directly descendant to V2.95, most bugs are
> inherited, and not from early betas either.
Well, there definitely had been made a lot of changes between V 2.95 and
pre-release 1 of V�, and it was these changes that seemed to cause quite
a few crashes.
>> Applications like Miami, NewsRog and YAM are running all the
>> time, and Voyager regularly.
> MUI ruins NewsRog, IMO. I can easily get enforcer hits from it.
You can. I have been using Enforcer quite a bit over the last months,
mainly to see how badly Voyager behaved, and in all that time I haven't
had one single hit by NewsRog, and I use NewsRog a lot. Okay, there
might of course be certain ways in which you can use NewsRog that causes
Enforcer hits.
Uffe Holst
--------------------------- ONElist Sponsor ----------------------------
Hey Freelancers: Find your next project through JobSwarm!
You can even make money in your sleep by referring friends.
<a href=" http://clickme.onelist.com/ad/jobswarm1 ">Click Here</a>
------------------------------------------------------------------------