things I miss about VW in Dolphin
Richard
the namespaces or anything like that. In fact, I haven't touched
visualworks in most of a decade, back when it was version 4i if I
recall correctly. However, I *do* miss:
1) being able to drag and drop instance variables onto target classes
or otherwise have dumb moveUp / moveDown methods in the context menu
for that pane. This is a real no-brainer. It should have been
implemented 10 years ago.
2) having the changes file be autosaved so that if my computer crashes
or whatever then I can recover the history. Probably more difficult to
implement.
3) a cancel below the accept for the context menus of the method
definition and class comment panes.
Why does the last one matter? Because having that "there are unsaved
changes, would you like to retain them" dialog pop up really bugs me
the fuck out. It's rude, it's impolite, I keep having to THINK about
whether or not I want those changes. It's really horrible design to
end up hitting that dialog once every hour, on the hour.
Worse, there's another dialog that says "there are unsaved changes,
would you like to save them to the clipboard" and I don't even fucking
know the conditions that make one dialog come up rather than another.
So I have to KEEP THINKING about what those dialogs mean every time
they pop up. And that's assuming those dialogs come on one at a time,
cause I've had them come up 3 times in a row at least twice.
Having that dialog hit me over the head repeatedly makes me IRATE.
The worst part is the Dolphin way to get around it is so unuseable.
Because the Dolphin way is to select the method you're currently
editing from the methods list pane again. And the ergonomics of this
are SHIT. Because instead of:
- right click, scroll down a SHORT and FIXED distance (about 1
centimeter) down the menu, then left click - total 2 seconds. and
those 2 seconds involve only what I want to do (cancel the edit)
you have this nightmare
- very long saccade to the methods pane, hunt down the method you're
using now which is a VARIABLE distance, then double left-click on that
method, then another very long saccade BACK to the method definition
pane - total about 5-7 seconds, most of which is forgetting what I
want to do and playing "what method am I editing now?"
You see, there's this little fact about human neurocognition called
overlearning. It means that something has been learned so hard that
it's impossible for the person to prevent themselves from doing it.
And you know what's interesting about this fact? READING is
overlearned in every civilized person. (In fact, 'civilized'
historically means 'literate city-dwellers'). So when I'm glancing at
that methods list pane, it's impossible to prevent myself from reading
the method names.
I do not want to be doing this!!!
So yeah, that's my rant. I hate those places where Dolphin's IDE tells
me "haha I don't care what you want you loser, you're going to do what
*I* want now!"
A programmer is a human being. Excepting only psychopaths, human
beings are possessed of emotions. Good design is polite. Good design
is thoughtful. Good design is NEVER rude and mean and careless.
Udo Schneider
> 1) being able to drag and drop instance variables onto target classes
> or otherwise have dumb moveUp / moveDown methods in the context menu
> for that pane. This is a real no-brainer. It should have been
> implemented 10 years ago.
to check the pull up/push down refactorings in the ivar tab context menu.
> 2) having the changes file be autosaved so that if my computer crashes
> or whatever then I can recover the history. Probably more difficult to
> implement.
I don't get this one ... if you do any changes it's immidiatly written
to the changes file.
You can either recover it manually or use Ians excellent Chunk Browser:
http://www.idb.me.uk/idbchunkbrowser.html
> 3) a cancel below the accept for the context menus of the method
> definition and class comment panes.
Why not add the Cancel option to the menu on your own? Using IDE
Extentions this should even be possible w/o changing any OA code.
CU,
Udo
Richard
wrote:
> You're right - D&D is not implemented for this currently. You might want
> to check the pull up/push down refactorings in the ivar tab context menu.
the pullUp/pushDown are broken and I've complained about this to Andy.
The reason they're broken is,
1) they are far too intelligent for simple operations as they just
remove the instance variable entirely if it's never referenced.
2) there is no pullUp in the context menu, only in the Menubar >>
Class >> Refactorings menu. Which considering #1 means that it is
exactly as inaccessible as it ought to be. IOW, far, FAR too
inaccessible for common uses. Conversely, the pushDown is far, far TOO
accessible for an intelligent refactoring.
3) along with pullUp / pushDown in the class menu, there needs to be
pullDown and pushUp. As it is, you've got an asymmetric and incoherent
subset of refactorings that is very difficult to figure out.
> I don't get this one ... if you do any changes it's immidiatly written
> to the changes file.
> You can either recover it manually or use Ians excellent Chunk Browser:http://www.idb.me.uk/idbchunkbrowser.html
Well, I wish I'd known that a few days. A moot point now but I'll keep
it in mind.
Note that I do consider it a failure when simple recovery requires
expert knowledge. In VW, I managed to figure out how to recover
history in one of my very first sessions with The IDE.
> > 3) a cancel below the accept for the context menus of the method
> > definition and class comment panes.
>
> Why not add the Cancel option to the menu on your own? Using IDE
> Extentions this should even be possible w/o changing any OA code.
Too many levels of indirection. I'm already porting horde3D for the
sole reason that I need a 3D engine in Smalltalk which I can extend so
that I can USE it to implement the 3D application I want to develop.
Messing with the IDE is just one level of indirection too many.
Note that I also consider the MethodListPane>>DeleteMethod method to
be broken. Anything that requires a confirmation dialog that doesn't
launch a nuclear missile is broken by design.
VisualWorks handled this by having a removeMethod and a
safeRemoveMethod that checked whether the method was referenced first.
And it also had better history recovery, not just an undo list which
often fails because things are being re-done out of order.
In the case that you are launching a nuclear missile, the correct
protocol is to have an arming procedure which you do before the launch
command. As should be obvious since this is exactly what real nuclear
submarines have.
The lesson here is: even launching nuclear missiles doesn't require a
confirmation dialog. And that tells you confirmation dialogs are a
bad, bad, BAD thing.
Udo Schneider
> the pullUp/pushDown are broken and I've complained about this to Andy.
> The reason they're broken is,
Interesting thoughts - not having used them in the past I didn't really
realize the associated problems.
> Note that I do consider it a failure when simple recovery requires
> expert knowledge. In VW, I managed to figure out how to recover
> history in one of my very first sessions with The IDE.
Just as a side questions - does VW have built-in changes recovery? Last
time I looked (VWNC3) I didn't see it.
> Too many levels of indirection. I'm already porting horde3D for the
> sole reason that I need a 3D engine in Smalltalk which I can extend so
> that I can USE it to implement the 3D application I want to develop.
> Messing with the IDE is just one level of indirection too many.
Are you aware of horde3dtalk? (http://code.google.com/p/horde3dtalk/)
CU,
Udo
Andy Bower
Your original e-mail to me on this subject was inflammatory and
unhelpful in that it reported a bug that wasn't, claimed it was over
eight years old without a fix and then went on a rant about "donkey balls".
I'm going to respond to your complaints here but some bits are cut from
your e-mails and not just from what has been posted on the newsgroup. I
hope this isn't too confusing for other readers but I think it's
important to use the newsgroup (rather than e-mail) for replies since
the responses then get preserved "in the cloud" for other users to have
access to in future.
> the pullUp/pushDown are broken and I've complained about this to Andy.
> The reason they're broken is,
>
> 1) they are far too intelligent for simple operations as they just
> remove the instance variable entirely if it's never referenced.
Ok, so your initial complaint was that the push down instance variable
refactoring is broken and you pointed to an NG article from 8 years ago.
However, the refactoring is NOT broken and that article actually
explained why. Yes, the operation will remove unreferenced instance
variables on the push down but this, IMO, is correct. Refactoring is
most often used to tidy up existing code, either before release or to
prepare for subsequent changes. The clue here is in the "re-". Now the
delay between originally writing the code (factoring) and the tidy up
(re-factoring) maybe only minutes but the usefulness of the refactoring
process is that it allows one to tidy up code whilst, at the same time,
guaranteeing not to break it. To this end, the fact that push down
instance variable simplifies without breaking by removing unreferenced
variables is "a good thing".
> 2) there is no pullUp in the context menu, only in the Menubar >>
> Class >> Refactorings menu. Which considering #1 means that it is
> exactly as inaccessible as it ought to be. IOW, far, FAR too
> inaccessible for common uses. Conversely, the pushDown is far, far TOO
> accessible for an intelligent refactoring.
I agree that there should be a "pull up" IV refactoring in the instance
variable pane context menu. However, given the fact that I disagree with
you about how you are using refactorings then I also disagree that the
pushdown is "far TOO accessible". I have recorded the lack of "pull up"
as an enhancement and it is recorded as issue #2271.
> 3) along with pullUp / pushDown in the class menu, there needs to be
> pullDown and pushUp. As it is, you've got an asymmetric and incoherent
> subset of refactorings that is very difficult to figure out.
I agree with this too. Again recorded as #2272.
In your e-mail your stated:
> But this is only the *surface* problem. The real question is WHY am I
> trying to do something *simple* like moving an instance variable to a
> specific subclass by using the refactoring? The reason why is because
> the whole behaviour of instance variables (objects in the system
> browser's instance variable pane) is screwy. Put simply, drag and drop
> DOES NOT WORK.
>
> I expect to be able to drag and drop an instance variable onto other
> classes in the same hierarchy. But I can't. Do you know why? Because
> even though I have,
>
> 1. the variable SELECTED
> 2. everything (if anything exists) in the method pane DESELECTED
>
> when I drag and drop a VARIABLE from the variable pane onto another
> class, the browser thinks I'm dragging a METHOD. Actually, it thinks
> I'm dragging an empty method list probably.
I can explain this but it's debatable whether the current operation is
truly the best one. When you drag from the variable list you are
actually dragging a list of methods that *reference* the variable. The
thinking behind this was as follows. If you are moving instance
variables around the class hierarchy manually (remember not all versions
of Dolphin have refactoring support) then this becomes a useful
operation; you can drag the referenced methods first and then move the
IV by altering the class definition or by using the Add/Remove context
menu items.
I agree that this is somewhat unintuitive (and have recorded an issue
#2273). I think it was done this way originally because dragging of
variables has the potential to be a significant breaking change.
However, I solicit comments from other users as to whether the current
behaviour should be changed.
>> I don't get this one ... if you do any changes it's immidiatly written
>> to the changes file.
>> You can either recover it manually or use Ians excellent Chunk Browser:http://www.idb.me.uk/idbchunkbrowser.html
>
> Well, I wish I'd known that a few days. A moot point now but I'll keep
> it in mind.
Back in the early days we had a number of people creating add-ons for
Dolphin, either paid for or freebies. We wanted to encourage this
enterprise so wherever possible we would try not to compete and
re-implement features in the base product where someone had already done
a suitable add-on. Also, we felt that it was rather rude to ask that
someone's free goodie be included in the base product because,
presumably, they would prefer to drive traffic to their website. For
this reason, we have never asked Ian Bartholomew if he would like us to
integrate his (admittedly indispensible) Chunk Browser support into the
base product.
Today, however, where the ongoing support of Dolphin is rather less
commercially oriented (yes we do charge for the Pro version but sales
barely cover costs) I am more open to asking for community contributions
to the base so maybe I will do this more often in future.
Still on the subject of moving instance variables around, in your e-mail
you wrote:
>Lastly, do people really copy methods so much more often than they
>move them around that it was necessary to *almost* adhere to MS
>Windows' keyboard conventions, by having
>
>1) shift DND cause moving (as per standard)
>2) ctrl DND cause copying (as per standard)
>3) <nothing> DND cause copying (in violation of standard)?
>
>Why bother to adhere to the standard in all important ways and then
>violate it in this unnecessary way?
First of all, yes I do believe that people copy methods more than moving
them; at least *I* do. However, more important is the fact that a method
copy operation is far less likely to break behaviour of the base system
rather than by moving them. Given the fact that drag&drop is the sort of
operation can can sometimes be performed by accident I think this is
quite important. These are the reasons we chose the default D&D
behaviour for method dragging in Dolphin.
Second, the option to default to copy is *not* in violation of standard.
Dolphin was built to comply with the IBM/Microsoft joint Common User
Access (CUA) standard for GUI design. IIRC, this explicitly said that
D&D moves were allowed to choose their own default operations depending
on context. I remember a design meeting where this was directly
discussed. It's possible that MS has since written a different standard
but I was unable to find it in a recent cursory Google search. If you
can supply me such a standard then I will consider changing Dolphin's
default behaviour although, given the reasoning above (and the fact that
the operation being performed is quite obvious from the drag cursor), I
personally think this would be a mistake.
> 3) a cancel below the accept for the context menus of the method
> definition and class comment panes.
>
> Why does the last one matter? Because having that "there are unsaved
> changes, would you like to retain them" dialog pop up really bugs me
> the fuck out. It's rude, it's impolite, I keep having to THINK about
> whether or not I want those changes. It's really horrible design to
> end up hitting that dialog once every hour, on the hour.
The reason behind this due to the way Windows handles list selection
changes. VisualWorks would not have suffered from this due to the fact
they didn't (and still don't) use native OS widgets. The point is that
when you change selection in the method list (or any Windows list) then
you have two options: 1) allow the change or 2) cancel it. At the point
when the system is making this decision it is inside an OS notification
callback so there are only a limited number of things you can legally
do. Because of the way Dolphin works, recompilation of a changed method
might cause other list selection changes, sometimes in other browsers,
which would not be allowable at this stage.
So the message box that pops up *is* ugly but it fulfills the need to
accept or deny the list selection change without allowing any other
domino effects. I'm sure there would be a way around the problem but
internally it would have made an already overly complex system even more
so. This was a deliberate choice at the time.
> Worse, there's another dialog that says "there are unsaved changes,
> would you like to save them to the clipboard" and I don't even fucking
> know the conditions that make one dialog come up rather than another.
> So I have to KEEP THINKING about what those dialogs mean every time
> they pop up. And that's assuming those dialogs come on one at a time,
> cause I've had them come up 3 times in a row at least twice.
Again, this is a corollary of the Windows list behaviour. As you know
Dolphin allows you to view the same method in several browsers. If you
change a method in more than one browser and try to accept the changes
in one then the other browser will complain and say, "well, at this
point I can't do anything to keep your changes so I can either throw
them away or copy them to the clipboard. This comes about because of the
way all the browsers are event driven off list selections. Again, yes we
could have added another layer of complexity (like first checking to see
if any method was already changed in any existing browser before
allowing edits in another) but at the time we erred on the side of
reduced complexity.
True, these behaviours irritate me too but, given that they happen so
infrequently (to me at least), they don't "bug me the fuck out" and it
has never seemed worth the significant effort it would be to change them.
>>> 3) a cancel below the accept for the context menus of the method
>>> definition and class comment panes.
>> Why not add the Cancel option to the menu on your own? Using IDE
>> Extentions this should even be possible w/o changing any OA code.
Whilst the Cancel idea is quite a good one (certainly from the symmetry
point of view) I don't think it would help you in this situation. Given
the fact that you are often seeing the message box pop up in cases where
you have made the same edit in several browsers and presumably forgotten
about it - you wouldn't therefore easily be able to find the browsers in
which to manually cancel the changes.
Why not always default to the safest approach. When it says, "There are
unsaved changes do you wish to retain them?", just click YES. When it
says "Do you want to save your changes to the clipboard?", just click
YES. Simple really. Regardless of how you would resolve these situations
in other implementations, a choice has to be made and, in Dolphin's
case, this can be done in the calm period after answering YES to the
message box prompt.
> Note that I also consider the MethodListPane>>DeleteMethod method to
> be broken. Anything that requires a confirmation dialog that doesn't
> launch a nuclear missile is broken by design.
>
> VisualWorks handled this by having a removeMethod and a
> safeRemoveMethod that checked whether the method was referenced first.
Dolphin has the same. If you do context menu Delete then this removes
the method without checking for references. The Refactorings->Remove
operation checks for references because one of the key aspects of a
refactoring is that it should not break existing behaviour (at least
that was the belief of Don & John who implemented the original
Refactoring Engine).
> And it also had better history recovery, not just an undo list which
> often fails because things are being re-done out of order.
As you now know, Ian's Chunk Browser should give you more than adequate
history recovery. Also if you are using Dolphin Pro and STS this offers
very good rollback features too.
> In the case that you are launching a nuclear missile, the correct
> protocol is to have an arming procedure which you do before the launch
> command. As should be obvious since this is exactly what real nuclear
> submarines have.
>
> The lesson here is: even launching nuclear missiles doesn't require a
> confirmation dialog. And that tells you confirmation dialogs are a
> bad, bad, BAD thing.
Strangely, I'm not actually conversant with how submarines prepare for
DEFCON 1. However, I thought they had a key (or keys) which unlocks a
big red button. If so, I'm not quite sure why this is unlike a
confirmation dialog just ahead of time. On this point I don't really
know what you are getting at.
To sum up, you have reported three issues, which I have recorded as
"enhancements" rather than bugs. I guess you can start the timer running
on these now rather than assuming that it has already been running
unchecked for eight years as you suggested in your first e-mail to me.
Regards
Andy Bower
Object Arts
PS: Regarding Design. In your e-mail you say: "Most people don't
appreciate it, but design is in the details. When designing, it's never
*just* nitpicking."
I agree with this. The reason why I love Apple hardware (and now run
only this) is because of the attention to detail. I have just finished
showing the kids the latest iMac advert:
http://www.apple.com/imac/the-new-imac/
I much appreciate the the way Jony Ive raves about tiny details like the
way the front glass goes right to the edge of the case leaving no bezel.
This is ergonomics matched with beauty and is great for a $200bln
company but I feel they have slightly more manpower available to fuel
such perfectionism than we do.
Richard
> Just as a side questions - does VW have built-in changes recovery? Last
> time I looked (VWNC3) I didn't see it.
My first experiences with VW were with 3 and it had built-in changes
recovery if I recall correctly. I used 3 a lot more than 4i because
the namespaces were a severe pain. Perhaps I used a later version of
3.
> Are you aware of horde3dtalk? (http://code.google.com/p/horde3dtalk/)
Yup, I was and at some point I dismissed it. Horde3D is unuseable to
me as-is since I need a 3D engine to do what no 3D engine has ever
done before. Despite the impression of OSes and their UIs as rather
sedate compared to games, it turns out their UIs must be a lot more
dynamic since gameworlds are comparatively dead. Aside from physics
and special effects, the sophistication of game engines is quite
superficial. And I don't need physics.
In any case, I'm unwilling to write C++ code to extend a 3D engine, I
can barely read C++ as-is and that's under protest. I'm also unwilling
to live with the extreme difficulties that would come up trying to
move domain objects back and forth between languages, or alternatively
maintaining two separate scenegraphs across a language barrier. I need
a native Smalltalk 3D engine to do my work.
Andy Bower
originally wrote to me and I pointed out that Dolphin support enquiries
should really be addressed to the newsgroup he wrote as part of his
reply that, "I will leave moving any or all parts of this
discussion to the NG to your discretion".
Normally, I wouldn't post private e-mail into a public forum but I
believe the above allows me carte blanche to do so on this occasion.
I just received the following reply to my newsgroup response of yesterday:
------
Subject: your post made me feel very angry
Andy, it's clear that you're feeling defensive and are more interested
in defending your design decisions than in improving the user's
experience of the product. Whether or not your design decisions were
dubious and objectively wrong has ALMOST gotten sidelined by your ego.
It's to your credit that you're being open-minded and acknowledging
that others' opinions might differ substantially from yours. That DOES
help me deal with my anger and extreme agitation when I see you dare,
dare! to defend the utterly indefensible against simple and obvious
truths. It doesn't stop me from becoming furious in the first place
though.
I really wish this discussion could be conducted in an entirely
emotionally detached manner. There is room for improvement in
Dolphin's IDE, as you acknowledge. And how many people do YOU know
that are capable of detecting, analyzing and synthesizing solutions to
problems nobody else has even brought up in the past 10 years? I need
you to fix things and you need me to point out what needs to be fixed.
Or we could just go our separate ways and I could get the IDE fixed
for myself while you rely on others for reports.
Do you think this little rant comes out of nowhere? Well, let's look
at the matter objectively. You start your first serious (involved and
comprehensive) response to me in any medium by whining and follow up
with some triumphalist complaining about something I have already
admitted is a non-issue. Because it's really a displaced issue. And
you do your level best to ignore the fact the issue is displaced.
Later on, you try to minimize the real issue and claim it's
"debatable" when that is a blatant fucking lie.
So how about we both of us take a time out and shelve the high
emotions and egos in favour of doing productive work? If you stop
being defensive, I'll stop being insulting. I've already stopped
assuming you're closed-minded and unwilling to change just because
these errors have persisted in Dolphin's IDE for a decade. Which was
the reason for my initial insult, restrained though it was.
> I can explain this but it's debatable whether the current operation is
> truly the best one. When you drag from the variable list you are
> actually dragging a list of methods that *reference* the variable. The
> thinking behind this was as follows. If you are moving instance
> variables around the class hierarchy manually (remember not all
> versions
> of Dolphin have refactoring support) then this becomes a useful
> operation; you can drag the referenced methods first and then move the
> IV by altering the class definition or by using the Add/Remove context
> menu items.
Your reasoning here is entirely circular. You are defending what I
consider broken behaviour by ASSUMING that Dolphin must be broken in
exactly the way that I complain about. It becomes "useful" to have an
operation that gets around the fact that you can't drag and drop
instance variables around. Riiiight. No this is not debatable at all.
There is no debate here, only defensiveness.
I strongly suggest you look at the matter EMPIRICALLY by analyzing and
measuring the ergonomics of the two operations. In particular, how
many keystrokes, mouse clicks and mouse movements it takes to do:
1) select all the methods that reference one variable from the methods
list pane "manually".
This takes exactly 1 short saccade to the top of the methods list pane
from the instance variable pane, one left mouse click to select the
first method, one short saccade right to the scroll bar, another click
and one and a half very short saccades to scroll all the way down,
then another short saccade and shift-left click to select the
bottom-most method.
That was the worst case where there are lots of methods: 4.5 short
saccades. With a mousewheel, 2.5 of those saccades are eliminated,
leaving only 2 short saccades, 2 clicks and 1 scroll of the mouse
(equivalent to a click). With few methods, there is no scroll. Oh and
at the end of it all, doing it manually converts a relatively short
saccade back to the classes pane into a much longer saccade. Total
time taken: 3-5 seconds.
But wait, that's not all! You see, the SHORTEST way to do it is to
select ANY method in the methods list pane (a saccade with an enormous
target) and then hit CTRL-A to SELECT-ALL. This reduces the whole
"manual" operation you're trying to automate down to 1 second. YOU ARE
TRYING TO AUTOMATE A 1 SECOND OPERATION. And much worse in my lights,
you're DEFENDING it. Incredible!
The ergonomics of the manual operation you're inflicting on users are these:
2) click on the class definition tab (a long saccade with a tiny
target), mouse over to the instance variable in the edit pane,
double-click on the variable to select it, TAKE YOUR RIGHT HAND OFF
THE MOUSE to hit the backspace key, hit ctrl-s to save, MOVE YOUR HAND
BACK TO THE MOUSE, a longish saccade and click to select the new
class, a short saccade to the instance variable pane, a right-click
and tiny saccade to select Add Variable from the context menu, TAKE
YOUR RIGHT HAND OFF THE MOUSE to start typing, anywhere from 5 to 10+
keystrokes in order to type the variable name ASSUMING you haven't
forgotten it. If the instance variable's name takes less than 5
keystrokes then double clicking on it with the mouse will be much
harder, to the point of being painful.
Yeah Andy, I can see your point of view. I really see how it's
"debatable" that automating an already split second mouse-only
operation (for right-handed people anyways but redressing the
handedness of Microsoft's keyboard conventions is NOT something you
should be doing) is way, WAY better than automating a 10+ second
operation that has the user switch between mouse and keyboard THREE
TIMES, not counting the final back to the mouse switch to reset the
hands back to how they were.
Did you imagine perhaps that users would use the handy Remove Variable
in the instance variables pane in order to erase the variable? Well,
they can't because YOU MADE IT IMPOSSIBLE to remove variables that are
referenced! You even added insult to injury by adding that stupid
dialog that "lets" users see all the references to the variable
they're trying to delete. Because you know, it's not like they can see
those methods just by clicking on the variable!
You know what? Even if you removed that stupid "safety" on the remove
variable pane's context menu, even if you cut out the rude and
insulting dialog (confirmation dialogs are the work of evil. "you
can't do that" dialogs are the work of satan himself), it would STILL
be an enormous win to automate the drag and dropping of variables
across the class hierarchy.
You are unbelievable Andy. Defending the utterly fucking indefensible
in order to bolster your ego. And doing it with circular reasoning,
CLASSY. And this after you've gone out of your way to make an
operation more difficult than it needs to be. When I first wrote this
passage, my hands were shaking.
Now do you see? This is really not helpful. And even though I MAY have
started the ball rolling by assuming you'd be closed-minded and
hostile (I don't know you well enough to predict whether verbally
sucking your cock would have gotten a less defensive response), if
you're going to be open to public criticism at all, you really need to
learn how to distance yourself a bit from your work. Adopt a bit of a
jaundiced if still affectionate view of it. If it hurts to Kill Your
Darlings, you're gonna be in for a lot of heartbreak.
You may wish to consider how valuable it is to be able to draw upon
psychology for HUMAN-computer interface design. All the things that
make me a bit (or a lot) of an asshole and someone you're pretty
uncomfortable dealing with, make me a better designer. It's too bad I
don't have any diplomatic training as well but fuck it.
Andy, I tip my hat to you,
Richard
Andy Bower
I had originally prepared what I thought was quite a long but witty
reply to your last message. However, I had missed the insults in the
third to last paragraph of Richard's missive and after my wife pointed
them out to me I have now decided to shorten the conversation.
<snips>
> Do you think this little rant comes out of nowhere? Well, let's look
> at the matter objectively. You start your first serious (involved and
> comprehensive) response to me in any medium by whining and follow up
> with some triumphalist complaining about something I have already
> admitted is a non-issue.
Ah, but the point is that your approach is to deliberately fanfare a
non-issue to get attention and then when discovered doing so you just
ignore the fact and move onto the next rant with no sign of apology. Are
you 13?
> Because it's really a displaced issue. And
> you do your level best to ignore the fact the issue is displaced.
> Later on, you try to minimize the real issue and claim it's
> "debatable" when that is a blatant fucking lie.
No, I accepted that the issue is displaced. I accepted that there were
several better ways of doing things. I even suggested that the instance
variable pane would probably be better dragging variables rather than
referenced methods. However, the fact is that *all* the drags from the
centre tabbed pane of the browsers only drag methods. This makes the
feature regular and was a deliberate design decision and therefore, to
my mind, makes the feature "debatable" whether you like it or not.
If it helps, I actually agree with you that the most *expected*
operation would be to drag variables about but it is so insignificant to
me that I have no intention of changing it. Frankly, I cannot think of a
single time when I have needed to drag a variable anywhere ever. It's
simply not worth addressing and there are far more pressing issues that
I don't have time to fix either.
> Did you imagine perhaps that users would use the handy Remove Variable
> in the instance variables pane in order to erase the variable? Well,
> they can't because YOU MADE IT IMPOSSIBLE to remove variables that are
> referenced!
IMPOSSIBLE? Why don't you try using the class definition pane? There you
go again exaggerating for effect.
> You are unbelievable Andy. Defending the utterly fucking indefensible
> in order to bolster your ego. And doing it with circular reasoning,
> CLASSY. And this after you've gone out of your way to make an
> operation more difficult than it needs to be. When I first wrote this
> passage, my hands were shaking.
>
> Now do you see? This is really not helpful. And even though I MAY have
> started the ball rolling by assuming you'd be closed-minded and
> hostile (I don't know you well enough to predict whether verbally
> sucking your cock would have gotten a less defensive response), if
> you're going to be open to public criticism at all, you really need to
> learn how to distance yourself a bit from your work. Adopt a bit of a
> jaundiced if still affectionate view of it. If it hurts to Kill Your
> Darlings, you're gonna be in for a lot of heartbreak.
>
> You may wish to consider how valuable it is to be able to draw upon
> psychology for HUMAN-computer interface design. All the things that
> make me a bit (or a lot) of an asshole and someone you're pretty
> uncomfortable dealing with, make me a better designer. It's too bad I
> don't have any diplomatic training as well but fuck it.
But Richard, you have to learn that insulting the fuck (yes, I can swear
too) out of someone doesn't work and can't be allowed to if the world is
to remain civilized. If you had said, "Andy, do you know that the
variables pane would be more usable if it actually dragged variables
rather than methods", I would probably have agreed. I would certainly
have added it to the issues database and I might have even fixed it by
now (unlikely but possible). Instead you've right got my back up and the
priority for addressing this is now languishing somewhere below deciding
what new bitmap to use for the System Folder background.
Drawing on psychology for human-computer interactions is, frankly,
useless if you can't also draw on it for human-human interactions too.
Or more likely you are simply a troll who *is* drawing on human-human
psychology to get me to waste even more time. Still, until I saw the
above offensive rant at least I was enjoying the exchange.
In the end, I think you probably are a troll or at least someone who
needs to learn some manners. In either case the result is the same and I
shall sending your future correspondence to the spam bin. Other members
of this forum may be more tolerant.
> Andy, I tip my hat to you,
Fortunately I have no hat. Otherwise I'm not sure what I might be
tempted to do with it.
Regards
Andy Bower
Andy Bower
> In the end, I think you probably are a troll or at least someone who
> needs to learn some manners. In either case the result is the same and I
> shall sending your future correspondence to the spam bin. Other members
> of this forum may be more tolerant.
Isn't Google great; I think this page explains all.
http://c2.com/cgi/wiki?RichardKulisz
Especially: "Some people have said that abusing certain people doesn't
convince third parties that my position is correct nor does it make me
look good. As if I cared about being convincing or popular. I care about
having fun."
Sigh. And if I hadn't spent so much time on this I'd already know what
background bitmap to use for the next System Folder :-)
Best regards
Andy Bower