Re: [Bug-XBoard] Castling not allowed when line is blocked

[Joshua Pettus]

Yeah I'm confused here too. What do you mean?  Do you mean you want to 
be able to castle though the queen?  Cause XBoard sure doesn't do that 
now.  Harm's right, that's not chess...


Josh


On 5/11/17 2:58 PM, h.g.mul...@hccnet.nl wrote:

Op Do, 11 mei, 2017 6:49 pm schreef G van Breemen:

All,


Please amend your rules as per example, castling is not allowed as line
is occupied by queen.

Well, I don't know by which rules you are playing, but in XBoard, variant
normal, we adhere to FIDE rules...

H.G.


Many thanks,


G van Breemen
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Castling not allowed when line is blocked

[Joshua Pettus]

Yeah, I'm confused by this too.  What do you mean?  I have never seen 
"castling though a queen"..  Your wording is weird.  Is this something 
you want to happen?  In which case, Harm is right. That's not FIDE.   
Xboard doesn't appear to have any problems with this that I can see.


Josh


On 5/11/17 2:58 PM, h.g.mul...@hccnet.nl wrote:

Op Do, 11 mei, 2017 6:49 pm schreef G van Breemen:

All,


Please amend your rules as per example, castling is not allowed as line
is occupied by queen.

Well, I don't know by which rules you are playing, but in XBoard, variant
normal, we adhere to FIDE rules...

H.G.


Many thanks,


G van Breemen
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] Xboard-hgbranch-master: Texture on the fly loading bug

[Joshua Pettus]

Hi, I haven’t yet narrowed down which commit broke this, but with a build from 
the current hgbranch code, xboard crashes out whenever I change the board 
textures (or pieces) while xboard is already open.  Texture changes were done 
through the board menu.
It doesn’t crash with the textures loaded in on launch which is strange:


Assertion failed: (CAIRO_REFERENCE_COUNT_HAS_REFERENCE (>ref_count)), 
function cairo_surface_destroy, file cairo-surface.c, line 953.
/Applications/Chess/Xboard/XBoard.app/Contents/MacOS/XBoard: line 69: 84183 
Abort trap: 6 

Regards,
Josh Pettus___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Some bugs while compiling on OS X 10.10.5

[Joshua Pettus]

  I forgot, I haven’t been compiling with clang for a while. To ensure OSX 10.6 
backwards compatibility, I have been compiling on a 10.6 virtual machine, which 
doesn’t have clang and uses a combination apple llvm/gcc 4.2.1.  I’ll have to 
try it on 10.11, but I don’t have it setup currently.
Cairo/librsvg has quite a bit to it, even for the Xaw version. ;)

The only warnings I get are ones complaining about depreciated gtk stuff  
‘g_type_init’  or calling ... which idk, seems to compile 
just fine on the latest version of gtk2.

Josh


> On Dec 11, 2015, at 10:54 AM, h.g.mul...@hccnet.nl wrote:
> 
> Op Vr, 11 december, 2015 3:07 pm schreef Joshua Pettus:
>> I just tested on the current OSX app.  Turns out, it doesn’t highlight
>> with the red dot, and does not capture.   I take it this is a bug?
>> 
> 
> No, that is correct. It is not allowed in Chu Shogi to capture a protected
> Lion with a Lion from a distance. (This to prevent easy trading of the
> Lions out of the game.)
> 
> Did you also get that warning about the EP_ROYAL_LION during compilation
> of XBoard?
> 
> H.G.
> 
>> Josh
>> 
>> 
>> 
>> 
>>> On Dec 11, 2015, at 2:47 AM, H.G. Muller <h.g.mul...@hccnet.nl> wrote:
>>> 
>>> 
>>> 
>>> 
>>> Op 12/10/2015 om 2:58 AM schreef global667:
>>> 
>>>> Hello,
>>>> 
>>>> 
>>>> I got many, many warnings, while building the sources under OS X
>>>> 10.10.5 with clang (see attachment), but it works.
>>>> 
>>>> 
>>> Just to check if some of these warnings are really errors, could you
>>> try the following?
>>> 
>>> 1) Start XBoard as "xboard -ncp -showTargetSquares true -testLegality
>>> true" 2) Select Chu Shogi from the File -> New Variant menu (lower-right
>>> button) 3) Play the white Lion from f3 to e5
>>> 4) Play the black Lion from g10 to e8
>>> 5) Play the white Lion from e5 to d6
>>> 6) Click the black Lion on e8
>>> 
>>> 
>>> Clicking the Lion should highlight the squares it can move to by
>>> colored dots. The question now is whether after (6) the square of the
>>> white Lion (d6) is highlighted this way in red (allowing the black Lion
>>> to capture the white one) or whether it isn't.
>>> 
>>> H.G.
>>> ___
>>> Bug-XBoard mailing list
>>> Bug-XBoard@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-xboard
>>> 
>> 
>> 
> 
> 


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Some bugs while compiling on OS X 10.10.5

[Joshua Pettus]

For the record,  the gtk2 mac integration library, and our code that makes use 
of it,  Is completely centered around an OSX app bundle deployment.   Macports 
is like a unix style repository for OSX, and anything installed by it would be 
a classic unix style installation.  Therefor, in this situation, our OSX 
integration code is completely useless.  Which is fine. Anyone installing via 
macports is probably looking for a classic unix experience anyway. (Someone 
like Bob Hyartt for instance who probably doesn’t care for what Apple has to 
offer anyway XD).

Josh

> On Dec 10, 2015, at 11:48 PM, Joshua Pettus <jshpet...@gmail.com> wrote:
> 
>> 
>> On Dec 10, 2015, at 2:45 PM, h.g.mul...@hccnet.nl wrote:
>> 
>> Op Do, 10 december, 2015 2:58 am schreef global667:
>>> Hello,
>>> 
>>> 
>>> I got many, many warnings, while building the sources under OS X 10.10.5
>>> with clang (see attachment), but it works.
>>> 
>>> If I run ./xboard with GTK, I got an warning.
>>> 
>>> 
>>> $ ./xboard
>>> No default pieces installed!
>>> Select your own using ‚-pieceImageDirectory'.
>> 
>> Sounds like you forgot to do "sudo make install”…
> The warnings are normal and nothing  to worry about.
> 
> Yeah,  Xboard looks for it’s resources in the standard unix directories and 
> needs the "sudo make install" to set everything up correctly.  Idk if the 
> installation script takes in to account the “prefix" parameter which would be 
> needed for many macports installs?  (For the record, macports defaults to a 
> prefix of /opt/local and any app needs to be installed in there)  Such 
> directories really isn’t ideal for mass osx deployment which is why we went 
> through the trouble of bundling xboard in an app bundle, (taking advantage of 
> the quartz version of GTK2, the GTK2 mac integration library, and a few extra 
> lines of code on our part)
> 
> http://www.open-aurec.com/wbforum/viewtopic.php?f=19=53274 
> <http://www.open-aurec.com/wbforum/viewtopic.php?f=19=53274>
> 
>>> 
>>> 
>>> with Xaw I got:
>>> 
>>> $ ./xboard
>>> Error: Can’t open display:
>>> 
>> 
>> This sounds like an internal Xaw error. The string "open display" does not
>> occur in the source anywhere.
>> 
>> Don't bother too much with Xaw. The future is GTK.
>> 
> Well even for the standard GTK2 on OSX, a working X11 server is important.
> It sounds like you have a problem with your X11 server.  I assume you have 
> Xquartz.app installed or at least the macports x11 server port?  I know 
> Xquartz.app works fine, but I haven’t ever tried the x11 port.  Might need 
> some extra configuration.. do other x11 based apps work?  Inkscape comes to 
> mind.
> 
> I assume you will be making the port for the X11 version of GTK2?  That’s 
> generally what other GTK based macports use, and is still the default gtk2 
> install.
> 
> If you need any help, let me know.  I believe a working up-to-date macports 
> port, as another option besides the app bundle, is very desirable.
> 
> Best Regards,
> Josh
> 
>>> 
>>> By the way: I have become the maintainer of the sources of Xboard on
>>> Macport if it is okayfor you. I will put it to 4.8 and perhaps add gtk
>>> support.
>>> 
>> 
>> OK, great. I am a Mac-ignorant, but please note that the sources can be
>> built for OS X through the Gtkosx library. Joshua Pettus can tell you more
>> about that.
>> 
> 
> 
> 
> 
> 
> 
>> 
>> Regards.
>> 
>>> Greets
>>> 
>>> 
>>> ___
>>> Bug-XBoard mailing list
>>> Bug-XBoard@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-xboard
>> 
>> 
>> 
>> ___
>> Bug-XBoard mailing list
>> Bug-XBoard@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-xboard

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [XBoard-devel] xboard osx issues and a few fixes

[Joshua Pettus]

Hey Arun,

I managed to figure out what went wrong with my system and why the localization 
files weren’t installing.  Apparently I kept botching the configure line to 
look at my macports lib and include folders thereby disabling nls. I can’t 
believe I didn’t notice..  Anyway I modified the script to check if NLS is 
active before installing the files. 

https://github.com/JoshuaPettus/xboard-OSX 


Best Regards,
Josh Pettus

> On Aug 17, 2015, at 4:00 PM, Arun Persaud  wrote:
> 
> Hi
> 
> sorry for not being responsive lately... got a few deadlines at work,
> which should be over this week, but after that I'll be on travel for a
> few weeks... I'll try to look at some of these items on the weekend, but
> otherwise, feel free to just push to the git repo directly if you feel
> it's only a small change.
> 
> Arun

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #45599] Xaw frontend build failure in OS X

[Joshua Pettus]

Hi

They are, we replaced __APPLE__ with osxapp for that very reason.  My guess is 
it’s a problem with his x11 install.  The default install is a little weird.  
You can try installing it in macports and see if that helps.

Josh



 On Jul 23, 2015, at 4:10 AM, H.G. Muller h.g.mul...@hccnet.nl wrote:
 
 I suppose this is a consequence of the gtkosx integration patches being 
 activated when compiling on OS X,
 even if the desire is not to compile for the integrated version, but for a 
 version intended to run on the
 Unix-compatible OS X interface (XQuartz?)?
 
 I suppose we should surround the OS X specific patches not by #ifdef 
 __APPLE__, but by a compiler switch
 set in the configure process, through an option --with-gtkosx, so that people 
 could still compile the Linux
 version of XBoard on OS X?
 
 H.G.
 
 Carlos Sánchez de La Lama schreef op 7/22/2015 om 9:19 AM:
 URL:
   http://savannah.gnu.org/bugs/?45599
 
  Summary: Xaw frontend build failure in OS X
  Project: XBoard
 Submitted by: csanchez
 Submitted on: mié 22 jul 2015 07:19:43 GMT
 Category: XBoard (X11)
 Severity: 3 - Normal
   Item Group: Installation/Configuration/Packaging
   Status: None
  Assigned to: None
  Open/Closed: Open
  Discussion Lock: Any
  Release: None
 
 ___
 
 Details:
 
 Xboard build process failed during in Xaw/xboard.c, due to XK_Meta_L symbol
 not being defined (along with many other XK_* symbols).
 
 Seems X11/keysym.h (which in turn includes X11/keysymdef.h) was missing. I do
 not know if it gets included by some other header in other platforms, but in
 my OS X (powerpc-apple-darwin8.11.0) it did not.
 
 Attached patch fixes the problem.
 
 
 
 ___
 
 File Attachments:
 
 
 ---
 Date: mié 22 jul 2015 07:19:43 GMT  Name: xboard-4.8.0.patch  Size: 360B
 By: csanchez
 Patch to enable build in OS X
 http://savannah.gnu.org/bugs/download.php?file_id=34483
 
 ___
 
 Reply to this item at:
 
   http://savannah.gnu.org/bugs/?45599
 
 ___
   Mensaje enviado vía/por Savannah
   http://savannah.gnu.org/
 
 
 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard
 
 
 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] Accessibilty request.

[Joshua Pettus]

It’s a shame.. Other toolkits like Qt has VoiceOver support.

Personally I think the thing to do would be to mail the gtk-osx-users-list and 
see what they say.

Josh



 On Jan 15, 2015, at 4:29 PM, Arun Persaud apers...@lbl.gov wrote:
 
 Hi
 
 If we do this ourselves we would have to create a lot of infrastructure
 for this. But because we do actually have an extra 'layer' between GTK
 and the XBoard 'business logic' in the form of the generic dialog
 creator, it would be possible to put the required infrastructure in the
 latter, so it automatically works for all dialogs.
 
 perhaps it would be easier to add this to the gtkos code we are using?
 that way other programs can use it too.
 
 Arun
 
 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #43792] Highlight last move doesn't work when pre-moved

[Joshua Pettus]

Well it’s a little more general then this.  Making an illegal move clears the 
board of any hi-lights and arrows. Because the hi-lighted square is no longer 
the last move. The last move was an invalid one.  Idk if this is really 
desirable. You can scroll back and forward a move to hi-light the last recorded 
move if you need.

Josh


 On Dec 10, 2014, at 8:37 AM, anonymous invalid.nore...@gnu.org wrote:
 
 URL:
  http://savannah.gnu.org/bugs/?43792
 
 Summary: Highlight last move doesn't work when pre-moved
 Project: XBoard
Submitted by: None
Submitted on: Wed 10 Dec 2014 01:37:50 PM UTC
Category: XBoard (X11)
Severity: 3 - Normal
  Item Group: Feature request
  Status: None
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
 
___
 
 Details:
 
 When having highlight last move on and doing a pre-move (dragging a piece on
 the target square during the opponent's move time), and the pre-move turns out
 to be invalid (because it would capture a friendly piece, or the the target
 square is blocked) the opponent's move is not highlighted. 
 
 Expected: Highlighted last move even when using pre-move.
 
 
 
 
___
 
 Reply to this item at:
 
  http://savannah.gnu.org/bugs/?43792
 
 ___
  Message sent via/by Savannah
  http://savannah.gnu.org/
 
 
 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #43323] -scp won't invoke engine with options

[Joshua Pettus]

You’re over thinking it.  just load your engine as -fcp and select Machine 
White/Black”  (which ever you want)  Machine black is default, in which case it 
is waiting for you to move.  -scp is only for two engines.



 On Nov 3, 2014, at 1:27 PM, Dario Niedermann invalid.nore...@gnu.org wrote:
 
 Follow-up Comment #3, bug #43323 (project xboard):
 
 Ermm... Scratch that last paragraph. I was trying to get XBoard to start in
 'Machine *White*' mode (since it starts in 'Machine Black' mode when I call it
 normally i.e. with -fcp).
 
___
 
 Reply to this item at:
 
  http://savannah.gnu.org/bugs/?43323
 
 ___
  Message sent via/by Savannah
  http://savannah.gnu.org/
 
 
 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] Make non supported variant for engine non fatal

[Joshua Pettus]

Anyway we can make the non supported variant error for an engine, non fatal for 
xboard?  It’s rather easy to do, when you mean to switch the variant, but can’t 
until you switch the engine.  Or if you select an engine that is set to use one 
variant, but the second engine, that was previously loaded, doesn’t support it. 
I don’t really know much about it, but what if it just unloaded the engine if 
it doesn’t support the variant, rather then crash?

Thanks,
Josh
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] FICS seekgraph auto-refresh doesn't remove dots

[Joshua Pettus]

Hi,

I just noticed that the seekgraph dots don’t automatically remove dots anymore 
when the seek ends,  this is in FICS.  

From what I have seen from an ICC guest account, it still works.

Best,
Joshua Pettus


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] FICS seekgraph auto-refresh doesn't remove dots

[Joshua Pettus]

Sorry,  Never-mind.  It started working again.  I think you have to restart 
xboard after selecting it in the options before it will work fully

-Josh


On Sep 24, 2014, at 12:52 PM, Joshua Pettus jshpet...@gmail.com wrote:

 Hi,
 
 I just noticed that the seekgraph dots don’t automatically remove dots 
 anymore when the seek ends,  this is in FICS.  
 
 From what I have seen from an ICC guest account, it still works.
 
 Best,
 Joshua Pettus
 


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard