OSX xboard Gtk using the native quartz

[JoshPettus]

Apparently it is really simple with macports just install the quartz version of the librsvg and gtk libraries
via:

sudo port install librsvg +quartz
sudo port install gtk2 +quartz

then compile the gtk version of xboard
./configure --with-gtk
make
install

Some advantages of this over x11 is that it's:
1) faster (at least faster then gtk+x11)
2) looks quite a bit smoother using OSX's built in features
3) Most windows are linked to the program and automatically move with the main board this also means carrying over into OSX's fullscreen mode for windows.

For some reason this excludes the move history, engine output, and evaluation graph windows, and of course, the terminal window.



All we need is for someone who knows what they are doing to put it all together in a .app bundle with the appropriate libraries, or statically linked with ones and we would have an excellent candidate for OSX distribution.

[hgm]

It looks very cool!

Strange that some windows are excluded, and others not. Some windows have 'persistent positioning', which is saved in the setting file, and should be restored when you re-open them. But that also applies to Comment and Tags windows, not jut to the ones you mention.

It could have something to do with the -stickyWindows option, which so far never worked on Mac. When this option is on, XBoard should move some windows that touch the board window to keep touching, when you move or size the board window. Perhaps this interferes with the native way of doing something similar. Be sure you have it switched off.

As to the terminal, it really is an annoying problem to have the ICS console as a separate app. Now that we have the Chat-box window, it could be an idea to absorb the ICS Input Box and the ICS console into it, as one of the chats, with fixed assignment. Its treatment would differ from that of the other chats, in that what you type there would not be pre-fixed by "xtell CHATPARTNER ", but sent raw. The Chat Partner field would have to be set to an immutable 'ICS console' in that case.

I have tried earlier to expand the ICS Input Box with an output memo to display the ICS output, but what stopped me is that Xaw had no possibility for selectively colorizing lines in a text memo, like the x-term can. But in GTK this is no problem.

So for now I should perhaps add code to recognize "ICS" in the Chat Partner field as special, and make the Chat Box catch all traffic that normally would go to the x-term.

[JoshPettus]

Well that sounds like some really neat ideas. I can tell you however that -stickyWindows pseudo works in that it works for some windows, if the windows are close enough together, but not for others, e.g. the chat boxes. (just as in winboard for that matter) Which may be why the native can take over for the non functioning ones. I'll give disabling it a try and let you know.

I like the chat box idea, only that wouldn't be colored either would it?

[hgm]

In GTK it is possible to colorize line-by-line, or even character-by-character. I already use that to highlight PVs in the Engine Output, and moves in the Move List windows (in yellow).

For the time being it could be tested without colorization, however, if the output also keeps going to the x-term. The people that want colorization could keep using that, while people not caring about it could minimize the x-term, and write ICS as one of their Chat Partners.

I guess eventually it should be configurable which chats will be opened at startup, as it already is in WinBoard.

[JoshPettus]

Well i gave it a try, it's not the sticky windows option. Turns out the only 2 windows that are reliably moving with the board natively are the chat window and ICS Input. (also any popup windows like settings load engine, board..ect)
I guess it is the saved start-up positioning that is interfering. The only way to get these windows to appear in the fullscreen mode is to open them the first time while in fullscreen, if you go back or open them before, they will stay on the desktop window.

In case you don't know fullscreen is a little like spaces only it's dedicated to a single program, and you can switch between them as they appear on the spaces manger program called Mission Control.

I don't know, the start up positioning is, in every other instance, very useful. This would be the one case where it's getting in the way. I'm not sure it should be disabled as an option. :\

[hgm]

OK, I will think about it. In any case I pushed a version to hgm.nubati.net master that allows you to devote a chat to "ICS" to use it as console. No colorization, and in Xaw it does crash when FICS floods it with its welcome stuff. But in the GTK version it seems to work.

Only weird thing is that is seems to print many more prompts (with "set seek 1", and seek graph off) than I see in the x-term.

[JoshPettus]

Neat! I will try it out, i guess this could replace the ICS input window?
Yah if there isn't a simple solution then I say don't worry about it for now. The workaround if fairly straight forward until someone else with OSX thinks its a problem. (should they)

[edit] Yah I'm getting twice as many fics% lines. Oh well that's why i have it send that stuff to the seek graph. couldn't stand the flooding before anyway. XD

Might have to change scroll behavior slightly in the future. When you leave the chat box for another chatbox then come back to ICS, it scrolls to the top so you have to scroll to the bottom each time. But that doesn't seem to be default behavior for the other windows such as shouts, so I wonder whats going on there? Default is to remember the last position of the scroll bar right? hmm

Also it doesn't respond to the ICS text menu right now. GTK does offer the ability to have a right click contextual menu similar to winboard right? Right clicking does give me a menu where i can have the basic cut copy paste.

[hgm]

Yah I'm getting twice as many fics% lines. Oh well that's why i have it send that stuff to the seek graph. couldn't stand the flooding before anyway. XD

The strange thing is that in the debug file those extra prompt don't seem to be received from the ICS. So it seems a bug that XBoard somehow duplicates them. But I just hacked into the routine SendToPlayer, which writes on the terminal, to send the same to the Chat Box. Perhaps it is something that does not show up in the terminal, because it overwrites them with each other by using a CR without LF.

Might have to change scroll behavior slightly in the future. When you leave the chat box for another chatbox then come back to ICS, it scrolls to the top so you have to scroll to the bottom each time. But that doesn't seem to be default behavior for the other windows such as shouts, so I wonder whats going on there? Default is to remember the last position of the scroll bar right? hmm

I thought this was also the behavior of shouts etc. There are some things that inexpliquably do not work in GTK. I do call the same routine ScrollToCursor both after adding a line to a chat memo, and when switching chats. But in the latter case this seems to be ignored, whilein the former case it works. (The other problem is use of the mouse wheel in the Eval Graph to adjust the zoom, which is completely ignored.)

Also it doesn't respond to the ICS text menu right now. GTK does offer the ability to have a right click contextual menu similar to winboard right? Right clicking does give me a menu where i can have the basic cut copy paste.

Ah yes, the ICS Text Menu still places its thing into the ICS Input Box. I should have that look for an "ICS" chat too.

Indeed, with this type of window we could emulate a context menu like the WinBoard ICS console has, and the permanent ICS Text Menu window can disappear. The GTK version does not implement popup menus yet, however. (Also not the piece menu and drop menu.)

[JoshPettus]

Eval Graph to adjust the zoom

Really? It's not very responsive but it seems to work for me. As does the right click mode switch.

[JoshPettus]

oh nvm, i guess I was using xaw at the time. Right click at least works...

Wierd, it scrolls when there is a scroll bar but that function inexplicably stops when on the Eval graph...