Re: [Bug-XBoard] Random Thoughts To Get The Discussion Going

[Tim Mann]

On Mon, 03 Nov 2003 18:17:40 -0800, Mark Ioli <address@hidden> wrote:
> To start a new thread along the lines of what Daniel and I had started 
> talking about...
> 
> I wanted to throw out some questions/ideas just to see what everyone's 
> thoughts were (well, all 3 of us so far anyway) regarding 
> XBoard/WinBoard ToDos:
> 
> 1. Should WinBoard be made an MDI application? (Large hunk of work, I know.)

I'd say no.  MDI (unless it's changed since I last looked) means that
you have a big window with some number of subwindows that are confined
inside the big window.  If we support multiple boards in xboard/winboard
(which would be good), then each one should be a separate top-level
window. The model should be more like a Web browser than MDI.

> 2. Right now there are a few things inplemented in either X/WinBoard but 
> not the other. To what extent should we strive to have identical 
> features in both?

Generally, I consider each thing that's in one but not the other to be a
bug that should be fixed at some point, time permitting.  There may be
some exceptions, particularly things that weren't all that good an idea
to start with.

> Some things which may be easy to implement in a 
> Windows GUI might not be so easy or even look the same when duplicated 
> in X, and vice versa.

They aren't that different.  Some things take more programming effort in
one than the other because there is more library support available, but
getting past that is just a matter of making the effort.  For instance,
some things that are common dialogs in Windows, like the color chooser
and the system file open dialog, aren't provided in the ancient toolkit
that xboard uses, so xboard does without or rolls its own.

> Of course that may just be my lack of experience 
> with Tcl/Tk talking.

xboard doesn't use Tcl/Tk.  It uses Xaw.  Xaw is pretty old and crufty.
A large but perhaps valuable project for xboard would be to switch it
over to using the Gtk+ toolkit instead of Xaw.  Interestingly, there is
a version of Gtk+ for Windows, though I'm not sure how well maintained
it is.

> (This will ultimately lead to a question of whether 
> each should be a separate application, different versioning, etc.)

I'm strongly opposed to that.  My most recent effort was to bring xboard
and WinBoard closer together by merging the source trees.  Since you
guys are mostly Windows developers, there's a natural tendency for you
to want to consider this "the WinBoard project" with xboard being a
piece of old baggage that may or may not be dragged along.  From my
point of view, it's the xboard project, with WinBoard being a port to
Windows that we maintain in parallel.  That's part of it being an
official part of the GNU project -- in general the GNU project doesn't
care about things that only run on non-free operating systems.  In
projects that include ports to non-free operating systems, the version
that runs on a free operating system (such as GNU/Linux) is considered
primary.

> 3. CMail has always been an XBoard only thing, do you think it would be 
> worthwhile to port it to WinBoard? I've never been a correpondence 
> player, so I'm not sure how much demand there is for it.

It would be nice, but there are some difficulties even with the Unix
version.  There's a standard for formatting email messages used to play
correspondence chess.  The standard was developed after cmail was
written, and I don't believe cmail conforms to it, although I think it's
pretty close. CMail is written in Perl, and although it's fairly
reasonable to assume people have a Perl runtime system installed on
Unix, it's not so reasonable on Windows.  Even on Unix the connection
between the Perl script and xboard is a bit kludgey.

So I think if someone is interested in an email correspondence chess
module, it would be better to write a new one in C, using CMail as
inspiration, but conforming to the new standard.

> 4. An obvious one: what should our priorities be? Code cleanup, i.e. 
> breaking the files into smaller pieces, before going forward on new 
> features? This might help to make the GUI pieces easier to work with, 
> and of course less chance of stepping on each other's toes.
> 
> Just a few for now, I'd like to hear what you think, especially 
> regarding priorities.

I'm pretty neutral on priorities.  I think people should mostly work on
the parts that interest them the most or that they think are the worst
deficiencies in what we have now.  If someone wants to work on breaking
up the source files into smaller pieces, that needs to be scheduled
carefully, because it will conflict with most anything that anyone else
is doing at the same time.

The ** items in the ToDo file were the ones I thought were most
important last time I looked at it.  That rating was partly based on
them being small enough to seem doable for me -- there are many bigger
things that would be more useful if someone has time to do them.

> 
> Mark
> 
> 
> 
> _______________________________________________
> Bug-XBoard mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-xboard
> 


-- 
Tim Mann  address@hidden  http://tim-mann.org/