From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> > > Heh. Saying things like "Functions maybe like WinCVS" might get
you
> > > beheaded by some of our list followers. :-) I like the idea of
using
> > > Swing -- in fact, I (at least initially) like any idea that will
earn
> > > us a GUI that not just behaves the same on all supported
platforms,
> > > but *looks* the same as well.
>
> > In fact, I dont want it to behave exactly like WinCVS. Most of
> > all of the other CVS GUI frontends (jCVS, SmartCVS, LinCvs, WinCvs)
> > try an approach thats is too technical for the end user. I really
> > love the command line, but well you see too much of the dirty
details...
> I agree fully. An example of an interface that provides a fairly
> decent balance of functionality vs. user-friendliness (IMO) is that of
> Visual SourceSafe. I'm not familiar with many other VC frontends, but
> that one was my first VC GUI, and was pretty easy to get a grasp on,
> as well as to use once I fully understood what was going on under the
> hood.
The VSS UI isn't a particularly good example in this case. It's nice and
simple because VSS's SCM model is very simple. (Not to mention they
haven't done any serious work on the UI in over two years.)
Obviously, a GUI frontend can't behave exactly like WinCVS there are too
many annoying details you'd have to replicate. You can't steal the
WinCVS code for it because IIRC it's under the GPL license. So things
like the version graph display are much harder for a portable UI. Not to
mention SVN being different than CVS. There's also the problem of a
decent GUI diff mechanism. WinCVS apparently can munge itself into
funneling stuff into different external diff programs. (At least
Windiff, and Araxis Magic)
Xxdiff might be able to be ported, but again, it's under GPL.
However, having said all of that, the last version of WinCVS I saw
wasn't all that bad.
There might be ways to improve its usability aspects, but it certainly
covers a huge breadth of CVS functionality, and tries to make lots of it
easier than it was in the early WinCVS releases. Covering a large chunk
of functionality in
When I was doing some of the WinSVN prototype development I had two
initial goals:
1) Get up a COM object layer to serve as the middleground between the
SVN client and working copy layer so that VB could call it.
2) Try and ramp up enough suitable UI controls in VB to at least attempt
making it look like WinCVS.
The reason for doing it this way is that UI design is hard, and
generally time consuming, and trying to brainstorm about appropriate UIs
was more time than I was willing to deal with.
Just some thoughts,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006