hgm wrote:Well, if they leave a lot to be desired, it is upto us to meet the desires.
Yes, it is.
What would you desire most in XBoard? It is already free and open source, and the most universal GUI around, so it seems a good starting point.
The problem with XBoard for a Macintosh user is simply that it isn't a Mac app, but an X11 app. Most Macintosh users have never heard about X11, and have never seen an X11 app in action. XBoard neither looks nor behaves anything like a native application, and will be painfully awkward and frustrating to use for all Macintosh users, except possibly for the minority who comes from a Unix/Linux background. It does not use the standard menu bar. Universal keyboard shortcuts and mouse gestures do not work. Copy and paste between XBoard and other apps is possible, but not work the same way as copy and paste between native apps. XBoard does not use the standard OS dialogs for opening and saving files. It does not appear as an application icon in the dock while running. Because it is not recognized as an app by the operating system, it is not possible to do things like using XBoard as the default app for opening .pgn files.
The list goes on. Without a completely rewritten front-end in Cocoa (after which it would no longer be XBoard, but MacBoard), XBoard is just not an option on the Mac. I suppose writing a new front-end wouldn't be entirely impossible, but it would take a lot of work, and I think we would have more success spending the same amount of work on an app written natively on the Mac from the ground up.
IanO wrote:I hadn't realized Tord's Stockfish link above was to an updated Glaurung UI! It looks really nice, with about the same level of UCI match support as Sigma Chess.
Thanks, but actually it is just an extremely minor update over the old Glaurung GUI. There's just an icon, a new chess engine, and a handful of minor bug fixes.
And now for the feature requests! Though it has continuous analysis, I didn't see an "Analyze Game" option. I also expected that clicking on moves in the game listing would navigate to that move. Having the game list and analysis as separate windows makes moving the board around the screen more awkward.
Agreed on all counts. It's really not a good GUI. While it is possible that I will address some of the issues you mention in the current GUI, I think it is better to start writing a new GUI. The current code is just too messy and buggy (I learned Cocoa and Objective-C along the way, and it shows), and tedious to develop because it is written in Objective-C (which was the only option at the time). By rewriting in Lisp, I can work 10 times faster, and have more fun along the way.
Tord Romstad wrote: I suppose writing a new front-end wouldn't be entirely impossible, but it would take a lot of work, and I think we would have more success spending the same amount of work on an app written natively on the Mac from the ground up.
I am not so sure about that: the majority of the XBoard code is back-end code, and even then the front-end is only as big as it is because it is inefficiently written. (Too much copy-paste-modify code for setting up dialogs that are nearly the same.)
Would a re-write of the front end in GTK+ be any help? I was told this is supposedly cross platform, (although I was not able to compile it on any platform, but that is probably just my ignorance). Or does 'cross' here not cover Macs? A re-write of XBoard in GTK+ is currenly taking place.
Tord Romstad wrote:By rewriting in Lisp, I can work 10 times faster, and have more fun along the way.
Cool! I hadn't heard that there were any functional languages that were suitable for native UI development. Which Lisp system were you thinking of using?
Macintosh Common Lisp has a long Mac heritage, but it appears to remain tied to Carbon and PowerPC platforms. Same with offshoots OpenMCL and RMCL. The most active fork, Clozure, at least has Intel support and a Cocoa bridge.
LispWorks has an Objective-C bridge, but their CLIM framework is X only.
Steel Bank Common Lisp is apparently very active, and will run McCLIM, an interface manager which also only supports X graphics.
Other Lisps available from MacPorts are CLisp and GNU Common Lisp.
hgm wrote:I am not so sure about that: the majority of the XBoard code is back-end code, and even then the front-end is only as big as it is because it is inefficiently written. (Too much copy-paste-modify code for setting up dialogs that are nearly the same.)
I remain skeptical that this would be the most efficient approach, but I could be wrong. It wouldn't be the first time. I'll try to have a look at it some time.
Would a re-write of the front end in GTK+ be any help? I was told this is supposedly cross platform, (although I was not able to compile it on any platform, but that is probably just my ignorance). Or does 'cross' here not cover Macs? A re-write of XBoard in GTK+ is currenly taking place.
It covers Macs, sort of, but not in the way we want: GTK+ is just a layer over X11 in OS X (just like in Linux), and a GTK+ app is therefore no more native than a plain X11 app.
Tord Romstad wrote:By rewriting in Lisp, I can work 10 times faster, and have more fun along the way.
Cool! I hadn't heard that there were any functional languages that were suitable for native UI development.
Pet peeve: Lisp isn't a functional language, although it originated as such. It's a multi-paradigm language that supports functional programming as well as many other paradigms.
Which Lisp system were you thinking of using?
Macintosh Common Lisp has a long Mac heritage, but it appears to remain tied to Carbon and PowerPC platforms. Same with offshoots OpenMCL and RMCL. The most active fork, Clozure, at least has Intel support and a Cocoa bridge.
I'll use Clozure Common Lisp. The Cocoa bridge is excellent and very easy to use. The ability to do the GUI work interactively is extremely useful. It also the Lisp implementation I am most familiar with, because I use it most of the time at my job (we also have Lispworks 6.0, but I usually do most of my work in CCL because of the warm, fuzzy feeling of using free software, and use Lispworks only for testing compatibility).
By the way, Clozure Common Lisp isn't a fork of OpenMCL, it is OpenMCL. The name was changed some time back.
Conceptually the XBoard front-end is quite simple. It just requires a routine to draw a board, defining menus and couple clicks on the menu items to the corresponding back-end routines, and coupling mouse events on the board to the mouse handler (which now also resides completely in the back-end).
The most cumbersome part would be to define menu dialogs a la WinBoard, which XBoard currenty does hardly have either. If I would have to redo what I have done so far in XBoard, I would do it completely differently. In stead of dedicated code for each dialog, I would write a single table-driven dialog generator. That is needed anyway (and exists in XBoard) for the dialog to set the engine options (where the list that defines the dialog is ultimately provided by the engine). With minimal modifications it could be used for all other dialogs, by providing pre-cooked lists of GUI options, rather than engine options.
Tord Romstad wrote:By rewriting in Lisp, I can work 10 times faster, and have more fun along the way.
Cool! I hadn't heard that there were any functional languages that were suitable for native UI development.
Pet peeve: Lisp isn't a functional language, although it originated as such. It's a multi-paradigm language that supports functional programming as well as many other paradigms.
OK. I tend to lump things which can be used functionally together. I'm sure my Haskell friends would disagree also.
Which Lisp system were you thinking of using?
Macintosh Common Lisp has a long Mac heritage, but it appears to remain tied to Carbon and PowerPC platforms. Same with offshoots OpenMCL and RMCL. The most active fork, Clozure, at least has Intel support and a Cocoa bridge.
I'll use Clozure Common Lisp. The Cocoa bridge is excellent and very easy to use. The ability to do the GUI work interactively is extremely useful. It also the Lisp implementation I am most familiar with, because I use it most of the time at my job (we also have Lispworks 6.0, but I usually do most of my work in CCL because of the warm, fuzzy feeling of using free software, and use Lispworks only for testing compatibility).
By the way, Clozure Common Lisp isn't a fork of OpenMCL, it is OpenMCL. The name was changed some time back.
You are so fortunate, getting to use Lisp in your day job! It explains how you were so successful with Glaurung and Stockfish; Lisp programmers are a little smarter than the rest of us.
I wholeheartedly support you rewriting your chessboard UI in Clozure. It would be a poster child for Lisp app development as well; I didn't see any big Cocoa apps listed on the Clozure CCL Software wiki page.
Tord Romstad wrote:Pet peeve: Lisp isn't a functional language, although it originated as such. It's a multi-paradigm language that supports functional programming as well as many other paradigms.
OK. I tend to lump things which can be used functionally together.
Strange though it may seem, there are very good Lisp programmers who have a strong distaste for functional programming style.
I'm sure my Haskell friends would disagree also.
Yes, they would. They wouldn't even agree with the "supports functional programming" part.
You are so fortunate, getting to use Lisp in your day job! It explains how you were so successful with Glaurung and Stockfish; Lisp programmers are a little smarter than the rest of us.
Yes, I do feel very fortunate to be able to make a living from Lisp programming. It is the programming language I feel most at home with, and it has given me the chance to work with some extremely talented and creative programmers, and to learn a lot from them.
Tord Romstad wrote:Without a completely rewritten front-end in Cocoa (after which it would no longer be XBoard, but MacBoard), XBoard is just not an option on the Mac. I suppose writing a new front-end wouldn't be entirely impossible, but it would take a lot of work, and I think we would have more success spending the same amount of work on an app written natively on the Mac from the ground up.
You don't have to specifically develop for Mac to get an application that looks and behaves like Mac apps should. Cross-platform toolkits like Qt are pretty good at making things as native as possible. Here's what Cute Chess's Cocoa build looks like at its current state:
It explains how you were so successful with Glaurung and Stockfish; Lisp programmers are a little smarter than the rest of us. 
