| From: | Xavier Messersmith |
| Date: | 11 Jan 2000 at 22:50:37 |
| Subject: | Re: MUI, having nothing to do with OS3.5 |
From: Xavier Messersmith <xcaliber@xav.to>
On 11-Jan-00, Uffe Holst 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.
If its executable code it is a program. Just how I see it. :-)
I really don't like when people use the term application, reminds me of the
Macintoshes backward design.
>> 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.
How hard is logic to test? this = that, that = this
That, and as I said, theres little need to configure something already well
configured.
>>> 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.
Why isn't MUI called Amoeba instead?
> And flexibility is bound to cost CPU time, because more calculations is
> need to reach the flexibility
But is flexibility absolutely necessary on every available level? This is kind
of like 3-D animation, sure, its alot more flexible when you have all the
scene data because you can view it any way you like. The thing is that
typically one view will do, and few people can raytrace anywhere near realtime
speed. Most people are happy with this, and keep faith that the person who
renders it will use the right lighting, etc.
The only difference with this analogy is that by prerendering a few display
variables you don't take up gobs of harddrive space. Another plus.
>> 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.
You're focusing on the wrong balancing act. The real balancing act should be
what people actually have an occasion to use over the efficiency of such
functionality.
>> 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.
I think the main reason is that MUI does alot of what the programmer would
formerly have to do himself.
Note what happens when the user doesn't leap for the bloated MUI archives to
run a small program with a simple interface. What? No interface at all? Geeze,
that bites.
>>> 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.
What, spreadsheets? Text processing? How people can write those programs so
inefficiently I will never know.
For most applications an '030 at 25 MHz should suffice.
> 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.
But why is it necessary to pour over all those variables? Look at a GUI some
day, there isn't that much to consider. A modest processor should be able to
shred through the simple calculations that are necessary. What is MUI doing
with the rest of that time? I refer you to my slamming of the virtual head
into the virtual wall statement. :-)
>> 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.
If the program core is clean and well organized then I don't think there would
be much difficulty. Since I'm not a programmer just yet I think I'll hold off
on this line of defense.
>> 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.
Your applications didn't spend half a CPU cycle deciding to offer you
anything. This is what I meant by what I said above.
What you're talking about is what the programmer hardwired into his program,
decisions that do not denote intelligence on the programmer's behalf.
>> 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'm sure theres a small mob somewhere that makes up for that popularity.
Note that I get alot more problems out of MUI apps than I do ClassAct (or is
that Reactor nowadays?).
>> 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.
Actually, I never did like the window bars in WB1.3. That and most GUIs don't
look that impressive in four colors. (even if most GUIs of today don't
typically use much more than that)
>>> MUI futhermore likes a big stack. MUI likes lots of memory. MUI likes a
>>> fast processor. MUI likes a graphics card.
>>
>> 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.
Through brute force tactics. Something that the Amiga typically doesn't handle
very well.
> 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.
Thats the cycle with Voyager. imagine how much effort they'd save if they got
it right the first time? I'd love to go off topic in an off topic thread,
maybe tomorrow.
>> 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.
Indeed. :-)
--------------------------- 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>
------------------------------------------------------------------------