Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Bernd Petrovitsch <bernd@petrovitsch.priv.at>]

On Mon, 2010-03-22 at 21:21 +0100, Ingo Molnar wrote:
[...]
> Have you made thoughts about why that might be so?

Yes.

Forword: I assume with "GUI" you mean "a user interface for the
classical desktop user with next to no interest in learning details or
basics".
That doesn't mean the classical desktop user is silly, stupid or
otherwise handicapped - it's just the lack of interest and/or time.

> I think it's because of what i outlined above - that you are trying to apply 
> the "UNIX secret" to GUIs - and that is a mistake.

No, it's the very same mechanism. But you just have to start at the
correct point. In the kernel/device driver world, you start at the
device.
And in the GUI world, you better start at the GUI (and not some kernel
API, library API, GUI tool or toolchains or anywhere else).

> A good GUI is almost at the _exact opposite spectrum_ of good command-line 
> tool: tightly integrated, with 'layering violations' designed into it all over 
> the place:
>
>   look i can paste the text from an editor straight into a firefox form. I
>   didnt go through any hiearchy of layers, i just took the shortest path 
>   between the apps!
> 
> In other words: in a GUI the output controls the design, for command-line 
ACK, because you to make the GUI understandable to the intended users.
If that means "hiding 90% of all possibilities and features", you just
hide them.
Of course, the user of such an UI is quite limited doesn't use much of
the functionality - because s/he can't access it through the GUI - (but
presenting 100% - or even 40% - doesn't help either as s/he won't
understand it anyways).

> tools the design controls the output.
ACK, because the user in this case (which is most of the time a
developer, sys-admin, or similar techie) *wants* an 1:1 picture of the
underlying model because s/he already *knows* the underlying model (and
is willing and able to adapt the own workflow to the underlying models).

> It is no wonder Unix always had its problems with creating good GUIs that are 

ACK. The clichee-Unix-person doesn't come from the "GUI world". So most
of them are "trained" and used to look what's there and improve on it.

> efficient to humans. A good GUI works like the human brain, and the human 
> brain does not mind 'layering violations' when that gets it a more efficient 
> result.

If this is the case, the layering/structure/design of the GUI is (very)
badly defined/chosen (for whatever reason).

[ Most probably because some seasoned software developer designed the
GUI-app *without* designing (and testing!) the GUI (or more to the
point: the look - how does it look like - and feel - how does it behave,
what are the possible workflows, ... - of it) first. ]

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at