[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: GUI Notes

From: Alexander Mueller <alex_at_littleblue.de>
Date: 2001-07-12 19:19:58 CEST

> 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.

About the WinCVS Graph: I cant steal the graph algorithm.
But I just dont care about this detail. WinCVS is implemented as a MFC
application. Why bother with this component model if I have Swing?

And I dont see any problem with GPL. The only thing I cant do is
build GPLed stuff INTO non-GPL programs. But if I have an external
interface where I can plugin whatever tool there is no problem at all.

> However, having said all of that, the last version of WinCVS I saw
> wasn't all that bad.

In our company we are working with nothing but WinCVS. A lot of
positive things to say but a lot of negatives too, escpecially when
you peek behind the facade at the code. Didnt like the code...
The other bad things avout cvs are the reasons why people are
interested in a project like subversion.

> 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.

First I thought about joining the WinCVS project to maybe port the thing to SVN.
Next I thought about implementing a special WinSVN program like the one you
are planning.

After a lot of thinking I decided against it. I dont like it to write code that run just
under one architecture. And even when I would use a portable component model
like Qt I would still have to worry about things and test it under the different platforms.

Having a native library like svn that has to be pretty performant is fine with me
especially when it is done with a system like the apache protable runtime.

Front end is different for me, though...

> 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.

I am lazy and I hate the thought of wasting time. The major reason why I am planning the Java GUI.
I dont have to reinvent the wheel for every architecture I want to support.

Take a look at the WinCVS source code tree. There is such a lot of code
especially for Windows, for Linux and for Mac, and whatever else.

> Just some thoughts,
> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

... always willing for some philosophical discussions...


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

This is an archived mail posted to the Subversion Dev mailing list.