[XBoard-devel] GTK+ and wxWindows discussion

[Tim Mann]

Here are some messages that didn't get archived because we exchanged
them while bug-xboard was broken and xboard-devel hadn't been created yet.

-- 
Tim Mann  address@hidden  http://tim-mann.org/
> --- Begin Message ---
>
>
>
> Subject: 
>
> XBoard in GTK+
>
>
>
>
> Date: 
>
> Wed, 05 Nov 2003 21:36:40 -0800
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;	rv:1.6a) Gecko/20031030 Thunderbird/0.4a
>
>
>
>
> Since we're having mailing list issues, here's the email I tried to send 
> last night:
> >>>>>>
>
> Ok, this idea stuck with me, and I think it might be something I'd
> consider taking on, big as it is. Of course I have some questions about
> how to proceed with it. Correct me where I'm wrong here, but it would be
> possible to place the files related to the current X frontend in their
> own directory, similar to what is done with WinBoard right now, correct?
> So what is left is just the backend pieces which are exporting the
> interface used by any frontend? I'm just thinking that something as
> substantial as switching the X front end to use GTK+ would need to be
> done separately, not pieced into the current X frontend, so a
> xboard-gtk+ directory to place those frontend pieces in? I'm just trying
> to understand how generic the backend is, i.e. is my approach to doing
> this feasable or am I missing something, a dependency or interelation
> that makes it not quite so simple?
>
> Mark
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: XBoard in GTK+
>
>
>
>
> Date: 
>
> Wed, 5 Nov 2003 22:08:07 -0800
>
>
>
>
> On Wed, 05 Nov 2003 21:36:40 -0800, Mark Ioli <address@hidden> wrote:
> > Since we're having mailing list issues, here's the email I tried to send 
> > last night:
> >  >>>>>>
> > 
> > Ok, this idea stuck with me, and I think it might be something I'd
> > consider taking on, big as it is. Of course I have some questions about
> > how to proceed with it. Correct me where I'm wrong here, but it would be
> > possible to place the files related to the current X frontend in their
> > own directory, similar to what is done with WinBoard right now, correct?
> > So what is left is just the backend pieces which are exporting the
> > interface used by any frontend? I'm just thinking that something as
> > substantial as switching the X front end to use GTK+ would need to be
> > done separately, not pieced into the current X frontend, so a
> > xboard-gtk+ directory to place those frontend pieces in? I'm just trying
> > to understand how generic the backend is, i.e. is my approach to doing
> > this feasable or am I missing something, a dependency or interelation
> > that makes it not quite so simple?
>
> I think the frontend/backend interface is generic enough that it
> wouldn't need any serious changes to work with GTK+.  It already works
> with both Xaw and Windows, and those are pretty different.  Someone did
> a Motif front end once long ago too.  (I didn't merge it because there
> was no free clone of Motif then and I didn't want to be dependent on a
> proprietary toolkit.)
>
> Yes, I'd say to put the new frontend in a new subdirectory.  While I was
> making the base CVS version, I really should have moved most of what's
> in the main xboard directory into subdirectories, one for the
> backend/frontend interface and backend implementation, and one for the
> existing Xaw frontend files.  We can still do this; the only problem is
> that CVS doesn't have a way to rename files without losing their
> history.  (Renaming the ,v files in the repository is a kludge and
> requires shell access to the repository, which we don't have.)  I
> suppose I should think about fixing this before we go any farther -- I
> can ask the Savannah staff to nuke our repository so that I can
> reorganize the source tree on my home machine and then check everything
> in again.
>
> One minor issue with making more Unix frontends is that both operating
> system dependencies (Win32 vs. Unix) and window system dependencies
> (Windows vs. X) are encapsulated in the front end.  If we make another
> Unix front end, it will want to share some code with the existing one. 
> This isn't exactly a problem, more of an opportunity.  It gives a
> rationale for splitting some stuff out of xboard.c -- namely, stuff
> that's generic Unix support.
>
> -- 
> Tim Mann  address@hidden  http://tim-mann.org/
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: XBoard in GTK+
>
>
>
>
> Date: 
>
> Wed, 05 Nov 2003 22:42:51 -0800
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;	rv:1.6a) Gecko/20031030 Thunderbird/0.4a
>
>
>
>
>
>
> Tim Mann wrote:
>
> > While I was making the base CVS version, I really should have moved most of 
> > what's
> > in the main xboard directory into subdirectories, one for the backend/frontend 
> > interface and backend implementation, and one for the existing Xaw frontend files.
>
> I'd say go for it then, since we're early enough into the project that 
> this can be done without much disruption, it sounds like it would be 
> worth it in the long run. If you think it would be easier to do this 
> immediately after 4.2.7 is committed, it can wait until then I imagine, 
> it really wouldn't affect my initial steps with a GTK+ version.
>
>
> > If we make another Unix front end, it will want to share some code with the 
> > existing one.
> > This isn't exactly a problem, more of an opportunity.  It gives a rationale for 
> > splitting
> > some stuff out of xboard.c -- namely, stuff that's generic Unix support.
>
> Again, sounds like a good idea, maybe splitting out the code should be 
> the first project after 4.2.7, just to give us as clean a starting point 
> as possible. I have a question though. Let's say the switch to GTK+ is a 
> success, all has been completed and implemented, is working fine. Do we 
> continue to maintain/update/add to the Xaw frontend, or decide that the 
> "X" frontend is now the one written to the GTK+ library?
>
>
> --Mark
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: XBoard in GTK+
>
>
>
>
> Date: 
>
> Wed, 5 Nov 2003 22:54:29 -0800
>
>
>
>
> On Wed, 05 Nov 2003 22:42:51 -0800, Mark Ioli <address@hidden> wrote:
> > 
> > 
> > Tim Mann wrote:
> > 
> > > While I was making the base CVS version, I really should have moved most of 
> > > what's
> > > in the main xboard directory into subdirectories, one for the 
> > > backend/frontend 
> > > interface and backend implementation, and one for the existing Xaw frontend 
> > > files.
> > 
> > I'd say go for it then, since we're early enough into the project that 
> > this can be done without much disruption, it sounds like it would be 
> > worth it in the long run. If you think it would be easier to do this 
> > immediately after 4.2.7 is committed, it can wait until then I imagine, 
> > it really wouldn't affect my initial steps with a GTK+ version.
>
> I'm ahead of schedule on the other stuff I wanted to do for 4.2.7, so
> I'll look at doing that this weekend.
>
> > > If we make another Unix front end, it will want to share some code with the 
> > > existing one.
> > > This isn't exactly a problem, more of an opportunity.  It gives a rationale 
> > > for splitting
> > > some stuff out of xboard.c -- namely, stuff that's generic Unix support.
> > 
> > Again, sounds like a good idea, maybe splitting out the code should be 
> > the first project after 4.2.7, just to give us as clean a starting point 
> > as possible. I have a question though. Let's say the switch to GTK+ is a 
> > success, all has been completed and implemented, is working fine. Do we 
> > continue to maintain/update/add to the Xaw frontend, or decide that the 
> > "X" frontend is now the one written to the GTK+ library?
>
> I think once the GTK+ front end gets to the point where it has the same
> functionality and is stable, we can drop the Xaw front end.  
>
> "Same functionality" isn't quite obvious to evaluate, though.  One thing
> that some users like a lot about both xboard and winboard is that they
> are visually minimalist -- they use up minimal screen real estate.  If
> the GTK+ front end ended up having lots of extra stuff visible in the
> main window, it wouldn't be "done" until you could turn that stuff off
> and get something close to the old look.  
>
> To reveal some more thinking behind this:  Since GTK+ has some nice
> features for making things dockable, it would be cool to make some of
> the existing stuff that's now fixed in the main window dockable and
> movable (like the clocks), and also make some of the things that are
> currently always separate windows dockable into the main window (like
> the analysis window, tags, etc.).
>
> -- 
> Tim Mann  address@hidden  http://tim-mann.org/
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: XBoard in GTK+
>
>
>
>
> Date: 
>
> Thu, 6 Nov 2003 06:25:41 -0800 (PST)
>
>
>
>
> --- Tim Mann <address@hidden> wrote:
>
> > To reveal some more thinking behind this:  Since GTK+ has some nice
> > features for making things dockable, it would be cool to make some of
> > the existing stuff that's now fixed in the main window dockable and
> > movable (like the clocks), and also make some of the things that are
> > currently always separate windows dockable into the main window (like
> > the analysis window, tags, etc.).
>
> I really like that idea, thinking of the interface in terms of distinct
> modules will help with keeping the code separated nicely, and just overall
> make the interface much more customizable for people. So they could combine
> the board module with the clock module and the console module any way they
> like, along the top, the side or wherever. The minimalist idea could be
> implemented just by selecting has few as they want, recreating the "classic"
> xboard look if that's what they desired. Cool :)
>
> --Mark
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> AW: XBoard in GTK+
>
>
>
>
> Date: 
>
> Thu, 6 Nov 2003 19:20:51 +0100
>
>
>
>
> Hi, 
>
> I will look this weekend what we can do with GTK+. I don't know GTK too.
> But it seems like easier to learn the Xaw stuff.
>
> Basicly its a good idea to use GTK+. This should we use for the WB side
> too. 
>
> Can i use VS6 with GTK ?  I think i need the develop files.  
>
> Daniel
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tim Mann [mailto:address@hidden 
> Gesendet: Donnerstag, 6. November 2003 07:54
> An: Mark Ioli
> Cc: address@hidden; address@hidden
> Betreff: Re: XBoard in GTK+
>
>
> On Wed, 05 Nov 2003 22:42:51 -0800, Mark Ioli <address@hidden>
> wrote:
> > 
> > 
> > Tim Mann wrote:
> > 
> > > While I was making the base CVS version, I really should have moved 
> > > most of what's in the main xboard directory into subdirectories, one
>
> > > for the backend/frontend interface and backend implementation, and 
> > > one for the existing Xaw frontend files.
> > 
> > I'd say go for it then, since we're early enough into the project that
> > this can be done without much disruption, it sounds like it would be 
> > worth it in the long run. If you think it would be easier to do this 
> > immediately after 4.2.7 is committed, it can wait until then I
> imagine, 
> > it really wouldn't affect my initial steps with a GTK+ version.
>
> I'm ahead of schedule on the other stuff I wanted to do for 4.2.7, so
> I'll look at doing that this weekend.
>
> > > If we make another Unix front end, it will want to share some code 
> > > with the existing one. This isn't exactly a problem, more of an 
> > > opportunity.  It gives a rationale for splitting some stuff out of 
> > > xboard.c -- namely, stuff that's generic Unix support.
> > 
> > Again, sounds like a good idea, maybe splitting out the code should be
> > the first project after 4.2.7, just to give us as clean a starting
> point 
> > as possible. I have a question though. Let's say the switch to GTK+ is
> a 
> > success, all has been completed and implemented, is working fine. Do
> we 
> > continue to maintain/update/add to the Xaw frontend, or decide that
> the 
> > "X" frontend is now the one written to the GTK+ library?
>
> I think once the GTK+ front end gets to the point where it has the same
> functionality and is stable, we can drop the Xaw front end.  
>
> "Same functionality" isn't quite obvious to evaluate, though.  One thing
> that some users like a lot about both xboard and winboard is that they
> are visually minimalist -- they use up minimal screen real estate.  If
> the GTK+ front end ended up having lots of extra stuff visible in the
> main window, it wouldn't be "done" until you could turn that stuff off
> and get something close to the old look.  
>
> To reveal some more thinking behind this:  Since GTK+ has some nice
> features for making things dockable, it would be cool to make some of
> the existing stuff that's now fixed in the main window dockable and
> movable (like the clocks), and also make some of the things that are
> currently always separate windows dockable into the main window (like
> the analysis window, tags, etc.).
>
> -- 
> Tim Mann  address@hidden  http://tim-mann.org/
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: AW: XBoard in GTK+
>
>
>
>
> Date: 
>
> Thu, 6 Nov 2003 22:38:43 -0800
>
>
>
>
> I've heard that the Windows version of GTK+ may not be stable or
> well-maintained, so it may not work out to use it.  We could keep the
> existing Windows frontend if that's true.  Though it would be nice to be
> able to drop it so we only had to maintain one frontend.
>
> Another possibility that I looked into briefly at one point would be to
> use the wxWindows portability framework (http://www.wxwindows.org/).  If
> you program to the wxWindows API, your programs can be compiled for
> either X, Windows, or Mac.  Last time I looked, the X implementation of
> wxWindows used GTK+ and the Windows implementation used Win32 directly
> (I think).
>
> There are some drawbacks to using wxWindows, though.  It adds another
> layer, it seemed slow when I tried it (I got as far as implementing
> dragging chess pieces around a canvas), and it p doesn't expose all the
> functionality that we'd like to use from GTK+ and Windows, so we'd end
> up with some amount of system-specific code anyway. Also, although the
> license is compatible with the GPL, the library is not one that users
> would commonly have on GNU/Linux and other free OSes, so this would
> create a problem for distributing XBoard only in source form as we now
> do -- people would have trouble building it, including the distribution
> vendors.  (Red Hat and most other GNU/Linux distro vendors currently
> include prebuilt xboard binary packages.)  In fact, I think I read
> recently that official GNU programs are actually required to use only
> libraries that are commonly included with free OS distributions, but I
> can't find the Web page where I saw that right now.
>
> On Thu, 6 Nov 2003 19:20:51 +0100, "Daniel Mehrmann" <address@hidden> wrote:
> > Hi, 
> > 
> > I will look this weekend what we can do with GTK+. I don't know GTK too.
> > But it seems like easier to learn the Xaw stuff.
> > 
> > Basicly its a good idea to use GTK+. This should we use for the WB side
> > too. 
> > 
> > Can i use VS6 with GTK ?  I think i need the develop files.  
> > 
> > Daniel
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Tim Mann [mailto:address@hidden 
> > Gesendet: Donnerstag, 6. November 2003 07:54
> > An: Mark Ioli
> > Cc: address@hidden; address@hidden
> > Betreff: Re: XBoard in GTK+
> > 
> > 
> > On Wed, 05 Nov 2003 22:42:51 -0800, Mark Ioli <address@hidden>
> > wrote:
> > > 
> > > 
> > > Tim Mann wrote:
> > > 
> > > > While I was making the base CVS version, I really should have moved 
> > > > most of what's in the main xboard directory into subdirectories, one
> > 
> > > > for the backend/frontend interface and backend implementation, and 
> > > > one for the existing Xaw frontend files.
> > > 
> > > I'd say go for it then, since we're early enough into the project that
> > > this can be done without much disruption, it sounds like it would be 
> > > worth it in the long run. If you think it would be easier to do this 
> > > immediately after 4.2.7 is committed, it can wait until then I
> > imagine, 
> > > it really wouldn't affect my initial steps with a GTK+ version.
> > 
> > I'm ahead of schedule on the other stuff I wanted to do for 4.2.7, so
> > I'll look at doing that this weekend.
> > 
> > > > If we make another Unix front end, it will want to share some code 
> > > > with the existing one. This isn't exactly a problem, more of an 
> > > > opportunity.  It gives a rationale for splitting some stuff out of 
> > > > xboard.c -- namely, stuff that's generic Unix support.
> > > 
> > > Again, sounds like a good idea, maybe splitting out the code should be
> > > the first project after 4.2.7, just to give us as clean a starting
> > point 
> > > as possible. I have a question though. Let's say the switch to GTK+ is
> > a 
> > > success, all has been completed and implemented, is working fine. Do
> > we 
> > > continue to maintain/update/add to the Xaw frontend, or decide that
> > the 
> > > "X" frontend is now the one written to the GTK+ library?
> > 
> > I think once the GTK+ front end gets to the point where it has the same
> > functionality and is stable, we can drop the Xaw front end.  
> > 
> > "Same functionality" isn't quite obvious to evaluate, though.  One thing
> > that some users like a lot about both xboard and winboard is that they
> > are visually minimalist -- they use up minimal screen real estate.  If
> > the GTK+ front end ended up having lots of extra stuff visible in the
> > main window, it wouldn't be "done" until you could turn that stuff off
> > and get something close to the old look.  
> > 
> > To reveal some more thinking behind this:  Since GTK+ has some nice
> > features for making things dockable, it would be cool to make some of
> > the existing stuff that's now fixed in the main window dockable and
> > movable (like the clocks), and also make some of the things that are
> > currently always separate windows dockable into the main window (like
> > the analysis window, tags, etc.).
> > 
> > -- 
> > Tim Mann  address@hidden  http://tim-mann.org/
> > 
> > 
>
>
> -- 
> Tim Mann  address@hidden  http://tim-mann.org/
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: AW: XBoard in GTK+
>
>
>
>
> Date: 
>
> Fri, 7 Nov 2003 09:35:14 -0800 (PST)
>
>
>
>
> --- Tim Mann <address@hidden> wrote:
> > I've heard that the Windows version of GTK+ may not be stable or
> > well-maintained, so it may not work out to use it.  We could keep the
> > existing Windows frontend if that's true.  Though it would be nice to be
> > able to drop it so we only had to maintain one frontend.
>
> Yeah, it will be interesting to see if the Windows version is also updated
> when the 2.4 release of GTK+ comes out, supposedly by end of year I think. I
> can't speak to it's stability since I've never tried it. I've tried programs
> written in Tcl/Tk that required the Windows version of that (the SCID
> database program), which is interesting, but requires just that, the Tcl/Tk
> for Win to be installed on the person's machine. I don't know if you could
> just link statically to everything, might just end up with an enormous exe,
> and simply moves the problem over to the distribution of the source code
> (here's the code, but it you want to compile it you need all of this...) At
> least GTK+ is included on almost all Linux distros, so not as big of an issue
> for the X frontend.
>
> > Another possibility that I looked into briefly at one point would be to
> > use the wxWindows portability framework (http://www.wxwindows.org/).  If
> > you program to the wxWindows API, your programs can be compiled for
> > either X, Windows, or Mac.
>
> I looked at this briefly a while back, never actually tried it though. I'm
> just not real big on wrappers like this (unless I write them myself) and MFC,
> too much of a control freak I guess, like to deal with the raw interface :)
> I think for now it's still best to keep WinBoard written to the native Win32
> stuff, maybe GTK+ will become a possibility for it, or an option at least for
> people who want it.
>
> --Mark
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: XBoard in GTK+
>
>
>
>
> Date: 
>
> Sun, 9 Nov 2003 16:17:30 -0800
>
>
>
>
> On Wed, 5 Nov 2003 22:54:29 -0800, Tim Mann <address@hidden> wrote:
> > On Wed, 05 Nov 2003 22:42:51 -0800, Mark Ioli <address@hidden> wrote:
> > > Tim Mann wrote:
> > > 
> > > > While I was making the base CVS version, I really should have moved most 
> > > > of what's
> > > > in the main xboard directory into subdirectories, one for the 
> > > > backend/frontend 
> > > > interface and backend implementation, and one for the existing Xaw 
> > > > frontend files.
> > > 
> > > I'd say go for it then, since we're early enough into the project that 
> > > this can be done without much disruption, it sounds like it would be 
> > > worth it in the long run. If you think it would be easier to do this 
> > > immediately after 4.2.7 is committed, it can wait until then I imagine, 
> > > it really wouldn't affect my initial steps with a GTK+ version.
> > 
> > I'm ahead of schedule on the other stuff I wanted to do for 4.2.7, so
> > I'll look at doing that this weekend.
>
> This turns out to be a bit of a pain, so let's postpone it until we are
> ready to break up the source files into smaller pieces.  It might be
> good to start a new CVS module at that time too, perhaps called xboard5.
>
> In case you found it hard to figure out, the source files and
> directories currently in the main xboard directory can be classified as
> follows:
>
> acconfig.h       Unix (used by configure script)
> backend.c        Common
> backend.h        Common
> backendz.h       Common
> bitmaps/         Unix (pieces in XBM format)
> ChangeLog        Common
> ChangeLog.2      Old
> childio.c        Unix (can probably get rid of this)
> childio.h        Unix (")
> cmail.in         Unix (because it's not ported)
> cmail.man        Unix (")
> comment.in       To be deleted
> common.h         Common
> config.guess     Unix (used by configure script)
> config.h.in      Unix (")
> config.sub       Unix (")
> configure        Unix (")
> configure.in     Unix (")
> COPYING          Common (top level)
> COPYRIGHT        Common (top level)
> engine-intf.html Common (documentation)
> FAQ.html         Common (documentation)
> frontend.h       Common
> gamelist.c       Common
> gpl.texinfo      Unix (documentation)
> ics-parsing.txt  Common (documentation)
> INSTALL          Unix (documentation)
> install-sh       Unix (used by Makefile)
> lists.c          Common
> lists.h          Common
> Makefile.in      Unix
> mkinstalldirs    Unix (used by Makefile)
> moves.c          Common
> moves.h          Common
> parser.h         Common
> parser.l         Common
> pgntags.c        Common
> pixmaps/         Unix (pieces in XPM format)
> pxboard          Unix
> READ_ME          Common (top level)
> sounds/          Common
> ToDo             Common (top level)
> winboard/        WinBoard
> xboard.c         Unix and Xaw (mixed)
> xboard.h         Unix and Xaw
> xboard.man       Unix (documentation) -- should merge with xboard.texi
> xboard.texi      Unix (documentation)
> xboard.texinfo.in Unix (documentation)
> xedittags.c      Xaw
> xedittags.h      Xaw
> xgamelist.c      Xaw
> xgamelist.h      Xaw
> xhistory.c       Xaw
> xhistory.h       Xaw
> zic2xpm.c        Unix (utility program, move to "contrib" or something)
> zic2xpm.man      Unix (doc for above)
> zippy.c          Common
> zippy.h          Common
> zippy.lines      Common (example)
> zippy.README     Common (documentation, probably should merge with main 
> documentation)
>
>
> -- 
> Tim Mann  address@hidden  http://tim-mann.org/
>
>
> --- End Message ---