Re: Great SWT Program

In article <b2780f61-9bac-42f9-bce5-3894690ebf90@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Dec 6, 9:29 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
Stick to debating the relative merits of an environment with more
input options and an environment with fewer, and drop the straw man
arguments centered on a hypothetical individual badly-written
application AND the false conflation of the two only loosely related
issues of environment input options vs. individual application input
options.

[vicious insults and lies deleted]

(aka Twisted chickening out of rephrasing his claim)

The number of keys and the force needed are orthogonal, so having more
keys isn't inherently worse.

This wasn't part of the claim anyway so it's irrelevant.

Anyway, the original scope of discussion was *software* allowing more
input options. Software doesn't require, in and of itself, any amount
of physical force to operate. It is simply not true, and indeed CANNOT
BE true, that adding, say, mouse support will automatically and
unavoidably make software suck. End of story!

And this wasn't my claim either. My claim was that your original claim
(that you now seem to realise was wrong, but refuse to rephrase) was
bollocks.

No. That isn't what I'd said at all. You forgot to read on to my
simplified example in which designer skill doesn't enter into it. It's
irrelevant, in case you're wondering, because if a UI is bad because
the designer had bad skill, then it is bad because the designer had
bad skill rather than because it had however-many input options!
Sheesh!

So you may want to rephrase your claim in order to take this new
realisation into account.

(A forest of incomplete sentences deleted)

Christ, I hope so, because I don't know how to make it more armor-
piercing than that. If your skull is too think for even that to
penetrate, then I will have to simply give up on you completely as
hopelessly dense.

I thought you already had?

You're the one who suggested that the input device would need to be
remapped by software. Are you now suggesting that this software should
write itself?

No, I'm suggesting we assume that the programmer is perfect. After
all, the comparison is between keyboard+mouse and keyboard-only, so we
should change only the one variable. Everything else should be assumed
to be ideal.

Right, so your claim is that in a fantasy world of your own design,
keyboard and mouse is always better than keyboard alone.

This isn't a very interesting claim at all and doubt anyone but you
will want to waste any time on it.

My claim is that it is possible for a GUI app to be worse than a
text-mode app.

That's a trivial claim and a pointless one, and it's one that I never
disputed.

Except your original claim made the above impossible.

[calls me a liar for the umpteenth time ... and then does it AGAIN.
AND AGAIN.]

Have you stopped counting "insults"? And I was hoping for a high score
this week :-(

you never actually use a mouse so in practise it will only happen for
you when returning to the computer from having done things completely
elsewhere.

Why would this force me to look at the keyboard before I start typing?

TO POSITION YOUR HANDS INITIALLY, YOU DOLT!

It is not necessary to look at the keyboard to position the hands
correctly.

Plus, you continue to grossly underestimate the number of characters
you'd have to type in general to navigate with search,

I don't have to estimate it at all since I do it all the time.

Either you're miscounting, or you're not bothering to count and then
underestimating.

Or perhaps you are simply wrong :-)

Take your pick.

I don't have a pick. Perhaps I should get one?

When I look at keyboards a) that came with any PC I've ever had or b)
in bricks-and-mortar shops hereabout, they are all arranged
identically. ESC, gap, F1 through F4, gap, F5 through F8, gap, F9
through F12, gap, Print Screen, Scroll Lock, and Pause, then the Num
Lock, Caps Lock, and Scroll Lock LEDs; horizontal gap; ~1234567890-=
and backspace, gap, ins home pgup, gap, numlock /*-; tab qwertyuiop{}\
gap del end pgdn gap 789+; capslock asdfghjkl;' and enter, long gap,
456+; shift zxcvbnm,./ and shift, gap, up, gap, 123 and enter; ctrl
window alt space alt window menu ctrl, gap, left down right, gap, 0.
and enter.

So you always buy from the same vendor, or the same type of vendor.

Every one of them. There may be slight variations in gap sizes and
exact key sizes and positions.

This can be bad enough.

The ergonomic MS one has the alphanumerics in the correct places for
each hand

There are keys near the center of the QWERTY block that I may hit with
either hand depending on what the context is, particularly the
preceding keystroke or two. That wonky MS keyboard would frustrate
this particular bit of efficiency.

That's because, like most other modern keyboards, it was designed for
touch typing.

But for a North American, there's one keyboard layout that is so close
to ubiquitous that it can more-or-less safely be depended on.

Apple and Sun would tend to disagree with you.

Incorrect. Apple has what, a few percent market share? And this Sun
stuff you've seen must be for mainframes or other non-PC hardware, and
therefore even less common than Mac keyboards. Microsoft Windows, and
by extension PC keyboards, are indeed pretty much ubiquitous, and
among PC keyboards, the layout I described above is pretty much
ubiquitous.

Except it completely breaks down on laptops.

There's a double row of maximize, minimize, close buttons. The state
is still visible.

Only indirectly

No, directly.

Ah, so it actually says, in plain text, "This is a window in an MDI
application" in your version of Windows?

No. I never claimed this. You are putting words in my mouth again.
Stop it.

Yes you did - you said the state was directly visible.

Regardless, the state information in question is visible and directly
observable, without having to explicitly invoke some command to get
the UI to provide the information.

This isn't state information - it is an indirect indication of the
state. There is no MDI state indicator at all in an MDI application
when the internal window is maximized.

We both assume trained users -- though you tend to assume ones with
weeks (or more) of intensive training, and I only assume the basic
proficiency in bog-standard GUI usage that someone entering high
school should already have as part of their K-12 education.

Actually, your claim has been that Windows is entirely intuitive and
requires no training for an untrained person to use.

No, it has not. It has been that it requires no training *beyond a
normal education* to use, which is quite true.

This is very different then - it is only by accident that it is
Windows that happens to be used in most schools and if they had been
using some other computer system instead, then that system would have
been "entirely intuitive" to the general population.

There are exactly two alternatives and they are easy to visually
distinguish.

... to a trained user.

To a user that has actually graduated high school, yes.

Not at all. Microsoft has discontinued MDI and so encountering such an
app is going to be completely unexpected to someone who has only been
using their latest offerings.

An untrained
user will struggle somewhat. By contrast, an untrained user will
completely founder trying to use the cruftware that you've been
advocating.

Once again with the attack on menu bars and button bars.

On the contrary, it is at the very heart of my assertion that the mere
availability of the mouse...

Since I never claimed this anyway

Indeed not; I did and you disputed it,

Neither you or I did. You made some completely different claim and
then made a fundamental logical error when you tried to invert it.

A particular variant is graphical. But the debate in this particular
branch is over whether mouse support intrinsically sucks, not over
whether emacs sucks, so emacs is irrelevant here. (For those who
haven't been keeping score, mouse support doesn't suck and emacs does
suck.)

Both I thought emacs was irrelevant. Why then do you bring it up?

None of the nasty things that you have said or implied about GUIs are
at all true.

You're the one denigrating GUIs around here, not I.

You implied it.

DESIGN IS IRRELEVANT. See above. The issue is which ENVIRONMENT is
better: one with a mouse or one without it (both having a stock 101-
key keyboard).

Without software to control with it, the "environment" is of no
interest whatsoever.

To you, perhaps. In which case you may as well just drop this
subthread and move on. Thing is, I'd originally said the mouse
+keyboard environment was the better one (enabling better software UIs
than could be written for the keyboard-only one) and you disputed
that. But why, if the issue is "of no interest whatsoever" to you? May
as well just concede that I was right about which was the better
environment and move on already.

So what you're actually arguing is that keyboard+mouse is better than
keyboard alone when what you want to do is nothing? I don't see that
there is much difference at all in this case. I'm sure they're both
equally good at doing nothing.

Not whether some SPECIFIC APP is better or worse than
another. You claimed that an environment with a mouse is worse than an
environment without it,

For some specific environments, certainly.

No. All other things being equal, the mouse does not make things
worse.

I never said that it did.

simply because some jerk CAN make an app to
run in that environment that lacks a keyboard shortcut for one
infrequently-used command or some such rot. I called bull*** on that
claim, and I still do.

Then you should stop making up such claims.

I DIDN'T -- YOU DID!!! JEEEZUS! WILL YOU STOP THIS BULL*** AND THESE
DISHONEST TACTICS?!

I am not going to steal your own invented claims from you - credit
where credit is due.

You say X. I say not-X. You say no, not not-X. I say yes, not-X. You
then say I should stop claiming X. When YOU'd claimed X.

Your problem is in the transition from X to not-X. You screwed up some
very basic rules of logic when trying that leap.

(I notice that you're now stooping to falsely implying that I've
broken the law (...)

[falsely accuses me of mental illness]

Yep -- if it's not drugs, it must be insanity, because it surely can't
be the case that maybe I WAS RIGHT AND YOU WERE WRONG, now, can it? :P

It /could/ be, certainly, but it doesn't appear to actually be the
case.

Sure it is, because various things behave more consistently than e.g.
undo or backspace(!) in emacs, you don't need to personally keep track
of as much esoteric stuff or count the number of times you've done X
to anticipate how it will interpret keypress Y, you can see the
context of your actions, and so on and so forth.

Since the above are only problems in your own imagined text-mode app

No, they are problems in emacs as described by YOU in various posts in
this thread.

Certainly not.

And the Windows Explorer, of course. Oh, and Microsoft Word, Excel,
etc.

?

[falsely accuses me of mental illness]

I simply asked you to clarify

You did no such thing. You inserted an unexplained question mark.

because you wrote an incomplete sentence
fragment that doesn't make sense in context and you respond with
vicious insults?

You had trouble making the connection? Very well then: in addition to
IDEs and command prompts, there is auto-completion in Windows
Explorer, Microsoft Word, Excel, etc.

I don't believe that that was your motivation, or what you intended to
imply to our mutual audience.

Of course you don't - [calls me a liar]

OK. Now I'm going to start keeping count of how many times you've
claimed (including implied) that I've lied. This is ... *riffles
through some stuff* ... looks like #79.

Ooh - a new scoreboard! Yay!

But, come on, only 79?

Which, by your own rules (as quoted above), means that you have lost
the argument.

Bull***. If I say "A is true because of <detailed explanation of why
A is true>" and you say "No, A is false" I can just repeat that A is
true, and since you did not refute my explanation for why A is true in
any kind of detail, it remains standing.
(...)

Hey - /I/ never said that your rules make sense.

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.