Mark and/or Daniel wrote:
>While we may depict a folder/directory
>differently, the context menu operations to be
>performed on one should be fairly consistent
>(i.e., add, remove, update all, commit all, ...
I'd say leave out commands like "update ALL"
and "commit ALL". The idea generally should
be: select an object and then specify the
operation you want to do with it. An object
here can be a folder or a file or so.
>for a folder/directory). Similarly, most of the
>options off of the window menus should be similar.
>There are still likely to be platform-dependent
>options in both types of menus, but we can
>probably get 80% consistency. After all, the goal
>behind uniform GUIs should be transferable
>knowledge (if I know GUI A, I can figure out GUI B
>quickly) vs. absolute identical functionality.
Agree with this.
>>I'd say that there shouldn't be a need for a menu
>>with "SVN commands". There's a GUI and the
>>"commands" should be replaced with GUI operations
>>as far as possible.
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.
It is my opinion that any kind of "hidden functionality"
(like merge via drag and drop) needs a visible
counterpart on a menu. That was one of the ideas behind
menus: you can see the commands which are there! This
helps a lot when you are new.
>>Of course, allowing some
>>commands and a shell prompt for power users is
A shell prompt? Do we really need that? Wouldn't this
kind of defeat the purpose of a GUI client? If you
want a command line, you can use the command line client,
no? ;-)
>>still a feature that could be left in there but
>>I'd prefer if the GUI would not feel like just a
>>fancy layer ontop of the SVN command line
>>commands. I'd want that a GUI-user shouldn't need
>>nor have to know the SVN client commands.
>
>Agreed.
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?
Some of these operations will easily be mapped
to e.g. drag and drop. But not all. How would you
e.g. retrieve an old revision 1.5 of file
hungerdunger.mc ? What GUI operation would be an
appropriate and intuitive choice for that? OK, I
might be a tad dry in my imagination here, but
I really think that there should be a menu command
entry for every SVN command. Surely, on top of
that, some commands can be triggered through drag
and drop.
What am I missing? What other GUI operations did
you have in mind? I can think of drag and drop.
What else?
>>>Do we want a log window that shows all the server
>>>responses? I like
>>
>>I'm against it. Sure, it can *exist* if you select
>>to enable it and if you wanna do some
>>prevent the need for a "server log".
>
>I envisioned a log window (a.k.a., "transcript",
>stemming from my Smalltalk days) mostly showing
>exactly which files were affected on recursive and
>wildcard operations (e.g., update). The transcript
>would be toggled on/off, and probably default off,
>but I think it could be useful for batch
>operations.
Yep! Exactly that. Only, I'd have it default to
"on". 8-)
Cheers,
Joerg
Received on Sat Oct 21 14:36:20 2006