[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark Ioli
Subject: Re: [Bug-XBoard] Random Thoughts To Get The Discussion Going
Date: Mon, 03 Nov 2003 23:44:44 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 Thunderbird/0.4a

Very helpful... :)

Tim Mann wrote:

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.

Ok, that perspective helps, I don't think there would be a problem with the MDI approach, I'm fairly certain any new features could be implemented in the same way as SDI, but I like the web browser model comparison, especially as it relates to cross platform support.


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.

Now that sounds interesting, I've actually dabbled with Gtk+ on Linux, pursuing this might be beneficial to me personally when it comes to approaching the WinBoard side, if I could do it in Gtk+ I know I can do it in Windows. Also along with the comments below about xboard being the primary project and WinBoard a port, I think both interfaces would benefit from swithing it over. It would make implementing GUI features in XBoard easier/cleaner/more standard, and the subsequent port to Windows easier as a result.

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

I admit I had not thought of it in that way, in terms of the GNU/free-OS perspective. But I also never thought of xboard as baggage, or optional. That does make it clearer though. I think the merge of the source trees is great, but how much do you see needing to still be kept separate? Are we working toward a better delineation between frontend (GUI) and backend? Would it be helpful from a porting standpoint to work towards very well defined line between the two, almost like an API type interface?

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.

Definitely, I think it would be beneficial, but would require a freeze on some or all of the code to implement it, so yeah, we'll have to coordinate that if we decide to go forward on it. Maybe a week of complete freeze and just work on breaking it out.

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

I've been going through it looking for what appear to be "easy" ones, I'll most likely start with those to get my feet wet.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]