At 8:20 AM -0500 1/31/01, Mark Murphy wrote:
>The only reason for having "foo" and "foo ALL" as separate operations is
>if they have actual different meanings. For example, if performing an
>operation on a folder means something different than performing an
>operation on a folder and its contents.
I understand this difference is whether to perform the
operation recursively or not, right? Is the current (CVS
like) "recursive" or "not recursive" option not better
for this? In this respect, CVS works quite well, no?
> > Well, what would be a GUI operation for "merge from
>> branch rel-1-0-1-fixes"? This could be mapped to
>> drag and drop in a branch and revision history
>> tree view. Good. And a diff between rel-1-0-1-fixes
>> and rel-1-1-a16 of a few files? I'd say, that selecting
>> the files and then picking the diff command from the
>> SVN menu is not too strange a thing. After that you
>> can view the diff of each file by double clicking
>> the files' entries in the sand box view.
>
>I'm not familiar with version tree views, so I don't know how we'd do it
>there. In a file/folder view, when you select a file, I can see a diff
>menu option off the file object's context menu.
With version tree I mean a DAG where each node represents
a revision or a tag or a branch of a file. There you could
drag one branch node and drop it on top of another branch
(or the trunk for that matter) to signal that you want to
merge the dragged one into the one that you drop on.
> > I might be missing a lot here. But one thing is: people
>> will only feel "comfortable" with SVN (or any other
>> complex system) if they can figure out what's going
>> on. They have to understand what it does and they
>> have to understand notions of tag, branch, revision
>> history, etc. And they have to understand what operations
>> they can perform and what those operations will do
>> for them. In a system like SVN, we mustn't expect
>> the GUI to teach the user? Isn't there going on too
>> much that is not immediately *visible*. In this respect,
>> SVN is very different from, say Photoshop, where
>> you immediately see on screen what you do or did.
>>
>> So, what's so bad about having these operations as
>> commands in menus?
>
>I think most "commands" need to be operations against objects, vs.
>standalone commands. In other words, as much on context menus as
>possible vs. window menus.
Totally agree: a "command" works against an "object". That's
it. This is one of the core paradigms of GUI's like Mac OS
or Windows. And it existed and worked well long before Mac OS
or Windows knew contextual menus (no?). A command being in a
menu bar menu doesn't imply that that command is "standalone".
There surely are some: best example is "Quit". But there also
are others: e.g. "Cut", "Paste", "Copy", ... IMHO contextual
menus are great stuff because they save you "mouse mileage".
But conceptually, selecting a file or folder and then moving
the mouse to the menu bar to click there or control clicking
to get a contextual menu are not that far apart. OK, the user's
centre of attention always stays the object if contextual
menus are used, agreed. But I still fail to see the substantial
difference between both. After all, the usual menu bar guides
the user by disabling commands that do not apply to the current
object selection.
Don't get me wrong, I'd love to see contextual menus and
drag and drop operations etc. But the good ol' menu bar with
all commands in it needs to be around also.
Joerg
Received on Sat Oct 21 14:36:20 2006