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

[Mark Ioli]

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.

> snip

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


Mark