You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Stenberg <da...@haxx.se> on 2001/01/30 08:46:55 UTC
Re: How uniform can GUI clients be?
On Tue, 30 Jan 2001, Joerg Bullmann wrote:
> So, to come to my point: how *uniform* can an SVN client be?
I totally agree that it might be hard to make really intuitive interfaces for
different platforms that are uniform and still match the paradigms and
peculiarities of those particular platforms.
Still, just guessing here, most platforms would probably use the same
approach and only the Mac would differ.
I would also like to point out that there doesn't have to be a single view.
Compare to the Clearcase GUI-viewer, in which you can select to display the
file tree in different ways, just as you can in most 'file explorer' type of
applications.
How people like to view things may not differ depending on what platform they
use, but on purely personal preferenses and ways of thinking.
> How should the SVN commands be represented? I'd suggest an "SVN" menu
> with entries for all SVN commands.
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. Of course, allowing some commands and a shell prompt for
power users is 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.
> Do we want a log window that shows all the server responses? I like it.
> But I think I recall someone (was it one of the Greg(g)s?) speaking out
> vehemently against it some time ago. My memory might fool me here.
I'm against it. Sure, it can *exist* if you select to enable it and if you
wanna do some under-the-surface debugging and see exactly what the server did
say. But I think that the GUI should present information and progress data to
prevent the need for a "server log".
Compare to when you copy files using your file browser on a GUI system, you
drap and drop the files and they are copied or moved with some indicator
showing that they are moved/copied. You do not get a window where all the
copy-lines are shown and you do not select a "command menu" where copy is
picked.
> A GUI SVN client could offer simple diff and conflict viewing features.
I'd say this is one of the areas where a GUI client can show its power. A
really fancy diff viewer in different colours or traces what was done between
versions. Things that are tricky on a shell prompt and gets easier/nicer
within a GUI.
> Hope my ideas can help here and spark off a bit of detail discussion. I'd
> love to meet up with people to talk through this in kind of a workshop,
Well, mailing back and forth is a pretty good start imho.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: How uniform can GUI clients be?
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Tue, Jan 30, 2001 at 02:43:27PM -0800, Kevin Mallory wrote:
> I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
> least look at the merge manager in ClearCase.
While Im a die hard cli guy myself, the merge manager & version tree
viewer (especially the one on winblows nt) are excellent.
> It's one of the best parts of the tool (along with xlsvtree - the
> graphical version/merge browser).
I couldnt live without the lsvtree functionality when I moved from
ClearCase to cvs, so I wrote one. I have a command line cvslsvtree
perl script if anyone is interested.
--John Cavanaugh
Re: How uniform can GUI clients be?
Posted by Bob Miller <kb...@jogger-egg.com>.
B. W. Fitzpatrick wrote:
> Just for the sake of argument, NeXT/Apple's FileMerge utility totally
> blows Emacs away. It's a *very* nice GUI diff/merge program. I can't
> even begin to describe it without pictures.
I haven't used NeXT's FileMerge. I use xxdiff. I like it a lot, to
the point where I can barely comprehend regular diff's output anymore.
xxdiff's ancestors are xdiff and gdiff, which were developed at SGI
for IRIX over the last decade.
http://xxdiff.sourceforge.net/
kdiff (part of KDE) looks a lot like xxdiff, but its behavior is
completely broken.
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Re: How uniform can GUI clients be?
Posted by RADICS Peter <mi...@lbcons.net>.
On Tue, Jan 30, 2001 at 11:17:22PM +0100, Branko �ibej wrote:
[SNIP]
> > versions. Things that are tricky on a shell prompt and gets easier/nicer
> > within a GUI.
>
> Heh. We've got that. Its called Emacs+ediff+emerge.
>
> (I know, I know, not being constructive ... but I have yet to see the
> graphical diff/merge that beats Emacs in that respect.)
>
I once worked on OpenStep with Project Builder (not sure about the
name). It had a pretty good visual diff editor. If you can get your
hands on a OpenStep install CD, give it a try, and see if it's better
than your emacs beast :)
cheers,
mitch
--
// RADICS Peter <mi...@lbcons.net> (http://lbcons.net)
//
// "If human beings don't keep exercising their lips,
// their brains start working." -- Ford Prefect
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Kevin Mallory wrote:
> I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
> least look at the merge manager in ClearCase.
I have. Several times today, in fact. :-)
> It's one of the best parts of the tool (along with xlsvtree - the
> graphical version/merge browser).
The version tree is absolutely the best part of ClearCase, ans on I'd
like to see in SNV GUI clients. As I've said before.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
RE: How uniform can GUI clients be?
Posted by Kevin Mallory <ke...@ActiveState.com>.
I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
least look at the merge manager in ClearCase.
It's one of the best parts of the tool (along with xlsvtree - the
graphical version/merge browser).
-- Thanks
Kevin
Kevin Mallory VP, Engineering, 604-484-6474
Active State - http://www.activestate.com - Programming for the People
QUALITY is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it
represents the wise choice of many alternatives.
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please
contact the sender and delete all copies.
> -----Original Message-----
> From: Branko �ibej [mailto:brane@xbc.nu]
> Sent: Tuesday, January 30, 2001 2:17 PM
> To: Daniel Stenberg
> Cc: dev@subversion.tigris.org
> Subject: Re: How uniform can GUI clients be?
>
>
> Daniel Stenberg wrote:
>
> >> A GUI SVN client could offer simple diff and conflict
> viewing features.
> >
> >
> > I'd say this is one of the areas where a GUI client can
> show its power. A
> > really fancy diff viewer in different colours or traces
> what was done between
> > versions. Things that are tricky on a shell prompt and gets
> easier/nicer
> > within a GUI.
>
> Heh. We've got that. Its called Emacs+ediff+emerge.
>
> (I know, I know, not being constructive ... but I have yet to see the
> graphical diff/merge that beats Emacs in that respect.)
>
>
> --
> Brane �ibej
> home: <br...@xbc.nu> http://www.xbc.nu/brane/
> work: <br...@hermes.si> http://www.hermes-softlab.com/
> ACM: <br...@acm.org> http://www.acm.org/
>
>
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Stenberg wrote:
>> A GUI SVN client could offer simple diff and conflict viewing features.
>
>
> I'd say this is one of the areas where a GUI client can show its power. A
> really fancy diff viewer in different colours or traces what was done between
> versions. Things that are tricky on a shell prompt and gets easier/nicer
> within a GUI.
Heh. We've got that. Its called Emacs+ediff+emerge.
(I know, I know, not being constructive ... but I have yet to see the
graphical diff/merge that beats Emacs in that respect.)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: How uniform can GUI clients be?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Jan 30, 2001 at 08:36:30AM -0500, Mark Murphy wrote:
> Rather than focusing on the differences, maybe we can start listing
> places where we can be the same.
Good Idea!
> For instance, I think all the GUI environments we've been talking about
> support two main types of menus: window menus (the kind that drop down
> from a bar just under the window title bar) and context menus (the kind
> that pop up when you perform a platform-specific type of mouse click on
> an object).
Yup.
> 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, ... 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.
>
> Thoughts?
Here is what I was thinking of something like the following for the
window menus.
File
Repository - for choosing server/repository/authentication/etc.
Exit - I'll let you figure it out
Edit
Checkout
Update - update currently selected item (if any).
Update All
Commit - commit currently selected item (if any).
Commit All
View
As Unified Tree - view tree Mac Style with folders and files.
As Tree - view Windows Explorer style, tree and pane of files
As ???? - view Windows style where just current dir is shown
---
Differences
Status
Log
Help
The usual stuff.
For context menus I was thinking along the lines of
Update
Commit
Status
Log
Differences
As for overall design, I was thinking of either a two or three paned
thing, something Outlook or Outlook Express. I.e. in my best ascii art.
+---------------------------+ +-------+---------------+
| | | | |
| Hierarchy for unified or | | tree | Files |
| windows style | | | (for explorer)|
| | | | |
+---------------------------+ or +-------+---------------+
| | | |
| Info, i.e. contents, diff | | |
| status, log, etc | | same |
| | | |
+---------------------------+ +-----------------------+
Or, and this would probably be more consisten with Outlook, have the
tree come all the way down on the left, then have the right split top to
bottom with Files, and info.
What do people think about something like this.
Please fee free to add more menu options, move them around, etc.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Bob Miller wrote:
> Okay, branches are hard, and probably the wrong thing to design first.
> But you could ask the same questions about tags or revisions.
No, branches are simple, if you have a version-tree view, like ClearCase
does. So are tags and revisions. I sent a few screenshots to Bill Tutt a
few minutes ago. I can post them here, or put them somewhere in the
repo, if you're interested.
Whats hard is getting the information out of the SVN filesystem; we
don't have any APIs for that right now. That'll have to wait.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: How uniform can GUI clients be?
Posted by Bob Miller <kb...@jogger-egg.com>.
Mark Murphy 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, ... 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.
>
> Thoughts?
At an even higher level, thought should be given to what the user-
visible objects and actions are, and those should be the same across
platforms.
For example, what is the representation of a branch? Is it an
explicit object, a bunch of side effects on other objects, or both?
Can I simultaneously view two branches? How do I compare two
branches?
If the GUIs are in agreement about those (and their model is usable),
we'll be doing well.
Okay, branches are hard, and probably the wrong thing to design first.
But you could ask the same questions about tags or revisions.
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Re: How uniform can GUI clients be?
Posted by Joerg Bullmann <jo...@fontworks.com>.
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
Re: How uniform can GUI clients be?
Posted by Mark Murphy <mm...@collab.net>.
> >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.
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.
> 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.
> 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.
Mark Murphy
mmurphy@collab.net
Re: How uniform can GUI clients be?
Posted by Joerg Bullmann <jo...@fontworks.com>.
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
Re: How uniform can GUI clients be?
Posted by Mark Murphy <mm...@collab.net>.
> I totally agree that it might be hard to make really intuitive
interfaces for
> different platforms that are uniform and still match the paradigms and
> peculiarities of those particular platforms.
>
> Still, just guessing here, most platforms would probably use the same
> approach and only the Mac would differ.
Rather than focusing on the differences, maybe we can start listing
places where we can be the same.
For instance, I think all the GUI environments we've been talking about
support two main types of menus: window menus (the kind that drop down
from a bar just under the window title bar) and context menus (the kind
that pop up when you perform a platform-specific type of mouse click on
an object).
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, ... 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.
Thoughts?
> 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. Of course, allowing some commands and a shell prompt
for
> power users is 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.
> > Do we want a log window that shows all the server responses? I like
it.
> > But I think I recall someone (was it one of the Greg(g)s?) speaking
out
> > vehemently against it some time ago. My memory might fool me here.
>
> I'm against it. Sure, it can *exist* if you select to enable it and if
you
> wanna do some under-the-surface debugging and see exactly what the
server did
> say. But I think that the GUI should present information and progress
data to
> 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.
BTW, I am finally(!) getting some time again and will be helping out
Bill Tutt with svn_com wrappers around the SVN client API, so we can
start rolling more functionality into the UI.
Mark Murphy
mmurphy@collab.net