Re: Aqua is a Plastic Cube!

On Fri, 09 Jun 2006 17:37:23 -0400, Daniel Johnson wrote:

"TheLetterK" <non@xxxxxxxx> wrote in message
news:pan.2006.06.09.18.12.22.68546@xxxxxxxxxxx
On Fri, 09 Jun 2006 05:45:19 -0400, Daniel Johnson wrote:
That's not handled by the application framework.

Sure it is. What else could handle that?

The visual style of widgets? All the application framework needs to do (in
respect to widgets) is say "button here", "drop down menu here", etc. Many
platforms have theming engines that handle the actual look of the buttons,
menus, etc.

The "visual style" is a bunch of bitmaps; the *framework* is what
implements the controls. This is what provides the behavior, ie,
the smooth slide-out of the drawers.

That's what I said--I *thought* we were talking about that 'bunch of
bitmaps'. That's what I Was talking about, anyway.


(At least, in Cocoa it is called a framework)

[snip]
Au contrare. It does work without a programmable GPU;

Just not in real-time, which defeats the purpose in having it.

This isn't really so; the CPU can actually do these effects
in real time, but it is so taxing that it can't do very much else
at the same time.

Which is a pointless argument to make.


[snip]
WPF is a lot more than CoreImage of course, but in a way it is
less; it's not an image manipulation tool.

Neither is CoreImage, then.

You may want to elaborate that argument a touch;
it doesn't make any sense as stated.

CoreImage is no more an image manipulation tool than WPF can be. It's a
way of rendering effects using a programmable GPU, but that in itself does
not make it a usable tool.

Hmmm. It is not an end user application, if that's what you mean. But
I do not quite understand why this is important.

It's not an application at all, that's what I mean.


[snip]
No, I would not say so. WPF is the *entire stack*; it's like
speaking of "Cocoa"; it *covers* the actual rendering but also
much more. They are not the "at the same level" because one
is very much broader.

It doesn't matter that one is broader than the other, they still sit at
the same level (indicating that they are at the same 'depth' in a
block diagram).

They are not; if WPF were put into Apple's old Mac OS X
diagrams, it would take up two levels: it would be alongside
Cocoa, but also alongside Quartz.

WPF isn't analogous to Cocoa. It's the display subsystem, not an
application framework. You are confusing WPF with WinFX.


When one wants to call on these functions in Windows
using WPF, they do so in the same manner that one calls on CoreImage
functions on OS X (though the syntax and methods differ). WPF covers
other things, yes, but it *also* handles the same things CoreImage does.

I do not clearly understand what you are saying. The programming
model is quite different, and the capabilities of the tools are also
different.

The programming model is different, but the capabilities of the
libraries/APIs in question are not. If you wanted to, say, apply a
Gaussian blur to an image in Vista or OS X, you would do so in the same
manner--you'd call the function in WPF or CoreImage, respectively. The
methods and syntax by which this is accomplished differs between the
platforms, but at the most basic level it is the same process on both.


[snip]
No. DX9 is a tool for accessing them; but if you
to program them, you program them- DX9 does
not program them for its own evil ends.

Accessing and using are the same thing, in this case.

I do not agree, as you may guess.

[snip]
Extension is a pretty weak substitute the good design.

This is a poorly supported concept when applied to open source software.

Being "open source" is no excuse, though it *is* an
explaination. Open source projects do well when copying
existing works, but not so well when designing something
new.

This is simply flat out not true. If anything, it excels at creating
totally new concepts--that's one of the big complaints about Linux, that
it's "going everywhere at once".


XRender is illustrative; it's not integrated into the rest
of X and offers only limited functionality.

There are many, many bits of software built atop XRender, including most
modern desktop environments. How can you really say it's not integrated
when it is a seamless extension and most modern software (that would be
concerned with it) expects it to be loaded?

It is not "seamless"; it does not extend or improve the X-Windows
rendering model, but replaces it.

So? It's still ubiquitous, and still *extremely* common. I fall back on my
classic example--your comment has no more validity than my complaint about
the lack of system-wide spell checking in Classic apps.


[snip]
One that is so ubiquitous as to be considered a part of the platform.

One can argue that it *is* part of the 'platform' now; but part of
the problem this platform has is that it's rather vaguely defined,
and it's not too clear what is or is not part of it.

How does that matter? It's just considered a dependency if you write
software that requires it. If not, then you don't need to concern yourself
over it.

Well, it theory perhaps it does not matter.

In practice, it matters because it complicates the logistics
of deploying Linux and its applications.

Only in the time before package managers. Dealing with dependencies has
been a non-issue for *years*.


[snip]
By that logic, then Quartz doesn't 'know how to anti-alias text' either.

Yes, it does. Really.

No it does not. Quartz just composites, anti-aliases, and renders
bitmaps--nothing else.

No. You are just wrong about this; Quartz provides
actual text rendering, and it is anti-aliased.

And that text is made up of bitmaps--and the anti-aliasing on OS X is no
better than it is on X Windows or Windows XP. Worse, in some cases (like
on LCDs).


You may be thinking of the Window Server here; that
composites and renders bitmaps, but does not anti-alias
them. It does not render text.

Explain, then, why I have fully anti-aliased text in GNOME? It's been
around since I've been using GNU/Linux, and provides the same options and
features that OS X does. It's damn near impossible to find an X Windows
desktop these days that does not use Xft, which *does* support
anti-aliasing fonts.


[snip]
Cairo is not X, but a replacement for it.

Cairo is a 2D graphics library, not a replacement for X. It leverages
those 'non-integrated' X extensions you were complaining about earlier.

Cairo has an X-compatibility layer, but it does not require X,
and funnellings Cairo through X is a kludge.

I think you and I are talking about something different. When I talk about
X, I use it as shorthand for 'X Windowing System'. You seem to be talking
about Xlib.


If it is successful, you will eventually see 'native' Cairo
rendering, and X will be reduced to running on top of
it, rather than the reverse. This is the situation on Mac OS X
now (with Quartz instead of Cairo of course).

Cairo is much nicer than X;
I didn't know it was seeing adoption yet, but if it is that is
hopeful.

Why go on about Cairo? You've ignored all the other graphics libraries
that have come into ubiquity, so why is it special?

Have I?

You seemed to disregard libXft providing anti-aliased fonts, and insisted
that fonts on X Windows were limited to what is provided without XRender
and libXft. Despite both being so common as to be considered a part of the
platform.


Anyway, I did not bring up Cairo.

[snip]
Cool. But SVG icons don't look especially better than bitmap ones
displayed at their native resolution, like Windows does.

They do look better when you want to scale them up though.

Yes, that is true. Still, this approach is different from what Mac OS X
does, so I don't think Apple's distinctiveness is threatened by it.

If KDE supported scaling the UI to high resolution, then scaling
the SVG icons would produce a better result in that case, but
you can't tell about that from the KDE.org screenies.

I was talking about GNOME. KDE users will need to wait for KDE 4.

Oops. I assumed you meant KDE. Sorry.

KDE 4 is going to be incorporating vector graphics heavily (it's due
out later this year), and *both* toolkits come with libcairo
integration.

If KDE switches to more heavily vector based drawing, and
uses Cairo for it, then maybe it will look a lot like OS X then.

AFAIK Quartz doesn't have anything but support for vector graphics.
Everything OS X provides are bitmaps.

These two statements are in flat contradiction to each other.

No they aren't. Support and provisions are two different things. Quartz
may support vector graphics, but Apple doesn't utilize that support for
anything (they provide only bitmaps).


Quartz supports bitmaps and vectors. Mac OS X relies heavily on
bitmaps, but there are some vectors here and there.

Mac OS X vectors look different from Windows ones because
they are anti-aliased;

Vector graphics on Vista and GNOME are both anti-aliased.

the bitmaps look different because of the
high quality scaling and alpha composition.

[snip]
Yes. OS X has a high quality bitmap scaling algorithm that
lets it do this without keeping all bitmaps at their physical size;
yet another nice thing Quartz does that costs performance.

Apparently Apple's engineers are completely unable to take cues from the
rest of the computing world. Everyone else can manage to implement these
features without substantially impacting performance, yet Apple's coders
are so pathetic that their implementations are slower than molasses at
absolute zero.

No. Other vendors have not implemented these features. They are
now trying to complete, but not by duplicating Mac OS X. You have
already discussed Microsoft's use of WPF, and KDEs use of SVG
graphics, both upcoming.

Frankly, I don't believe that--what you're saying would not reconcile with
the facts. OS X has only gotten more eye candy as time has gone on, yet UI
responsiveness has improved with each release. This would indicate that
the problem lies not with the eye-candy (which is mostly offloaded to the
GPU these days anyway), but rather with Quartz itself.

Eye candy that *is* offloaded to the GPU is cheap, and Apple has
been ladling that on. But I have already pointed out the bits of eye candy
that aren't like that.

[snip]
They they took special efforts not to; but the default is to
anti alias all geometry, and that's what you see in the UI
most of the time.

Why anti-alias regular boxes? They don't *need* to be.

I explained that in my first post: so that Mac OS X is
*visibly* different from other OSes.

It's not *visibly* different in either case.


Other OSes don't do this because it brings little practical
benefit, and costs performance.

I'm anti-aliasing text in GNOME right now. It doesn't seem to impact
performance in the slightest.


[snip]
It's often times hard to distinguish
screen elements?

I don't see how this is true.

Those thin borders you referenced earlier.

Apple sometimes goes for rather subtle effects,
but I wasn't aware anyone was having actual trouble
with them.

I've got trouble distinguishing between very well blended items on OS X,
if I'm switching windows quickly.


[snip]
Good UI usually isn't. Customizability is what you can do
if you can't build a good UI: let the user alter it until they
like it.

No, it's not. A good UI is one suited to the user. You *cannot* dictate a
one-size-fits-all UI and expect it to be a good UI. That's trying to apply
an objective definition to an innately subjective experience.

UI design is not the same thing as UI preferences. Users generally
prefer what they know, but it *is* possible to measure UI
'performance' objectively none the less.

No, it's possible to measure it subjectively. GOMS and such is valid only
if we assume that the sole source of delay in an interface stems from
manipulation of the interface. Most people spend a lot more time figuring
out what needs to be done than they do actually performing what is
necessary.


Customizability is a substitute for doing this.

Customization is the only solution.


[snip]
Apple has 'linked' themselves to normal PCs is nearly every possible
way, and it does not seem to have caused much of a "marketing
disaster". If they can get away with The Intel Chip, they could get
away with The Windows Engine.

No, they can't. Mac users generally haven't given a damn about the
hardware.

This was not so when the hardware was part of what distinguished
the Mac from the PC; the flames from those flamewars are still raging
in some parts. :D

They use Macs because of the software. Switching to a different
hardware platform may be disconcerting to some (though this impact is
lessened because of the strong performance gap between PPC and x86 at the
time of the switch), but switching to a different *software platform*
would initiate a mass exodus.

Very likely. But if it still looked at acted like Mac OS X, and
if it still ran their software (perhaps in new versions), it would
not appear to *be* a different software platform to them.

It would become known in short order. There is absolutely no way that
Apple could hide such a transition.


Admittedly, the technical challenges in making that happen are
very great.

Especially a switch to *windows*, which most
Mac users have already made a conscious decision to reject.

I am not so sure that the Mac community is dominated by
actual Windows-haters. Surely .advocacy is not representative?

I didn't say they hated Windows, I say they rejected Windows. Most Mac
users these days have made a conscious choice *not* to use Windows. By
switching to Windows, Apple would take away that incentive. I personally
know at least two Mac users that have stated that they would not buy Macs
were Apple to switch to Windows--one of them even went so far as to say he
would switch to GNU/Linux.


They could not get away with selling a Mac that looked like
any old PC, however. They can't use Luna. Which is probably
just as well. :D

They can't get away with claiming any sort of association with Windows at
all.

I have great faith in the power of the RDF. They wouldn't *call* it
"The Windows Engine" any more than they are now saying that they
run on x86. They'd come up with a suitable name, like "Darwin" for
"Mach" or "The Intel Chip" for "x86".

Apple didn't name Mach, CMU did.


[snip]
Microsoft's downfall is inevitable. Even at .3% a year, Linux will
eventually reach a critical market share, and gain wide commercial
acceptance. Once that happens, it's over for Microsoft.

At *that* rate it would take centuries for Linux to get there,

Critical market share is probably ~10-15%.

What's critical about that number?

That's enough support to become a clear contender for most companies.
Commercial support for Linux on the desktop would spring up almost
overnight. Once *that* happens, Microsoft can kiss their fortunes goodbye
in short order.


At the current rate, that would
be 23 years. However, the trend over the last 5 years has shown a strong
*growth* of the rate at which Linux's desktop market share increases. It's
already surpassed Apple's growth rate, even with the iPod halo effect.

I think you are extrapolating way, way too far to be credible
on this one.

It's not just me--there are many analysts that agree with this
assessment. After 5+ years of quarter-over-quarter growth, it starts to
become a clear trend.


and
by they we'll all be using holographic AIs embedded in our brains
or something. (Unless you believe Keynes. They we'll all be dead.)

You'll still need an OS to host the AI.

We'll be using MS HAL 9000. :D

[snip]
But you can't project like that. Linux's growth rate is highly
contingent. If it breaks out of its cheap-server bubble, then it
will expand very much faster than that. But I don't think it will.

It's already been expanding out of it's 'cheap server bubble'.

Very, very slowly by your own numbers.

No, it's been expanding into the position of big-iron Unix very quickly. I
was talking specifically about *desktop* adoption.

I expect that to reverse
once MS gets a Vista out the door, and then reverse again once
Vista starts getting old.

Why would you expect that? If anything, Vista's release (with it's high
hardware requirements) will encourage Linux adoption.


But I don't believe Linux can get all that far in this market as long
as it maintains its 'binary compatibility is for wimps' attitude.

Uhh, is OS X binary compatible with anything else? GNU/Linux distros are
generally binary compatible with one another. That's why you can have
binary-only installers...

This can be mitigated for applications, but for drivers it's a real
problem.

It's even more of a problem for OS X, which supports *much* less hardware.


It's been
expanding into the position of the old big-iron Unixes for years
now--Linux has been the main reason for Unix's decline.

Yes indeed.

It's going to be
IBM's primary server offering across their entire product line in the
not-too-distant future, if not already. Sun will probably follow suit as
well.

Quite possibly!

Did you honestly think that *Windows* was eating into the Unix market
share?

Perhaps just a little. :D

.