URL:
http://savannah.gnu.org/bugs/?19851
Summary: Enhance file position index switches for loading
last item in file
Project: XBoard
Submitted by: None
Submitted on: Friday 05/11/2007 at 01:27 UTC
Category: None
Follow-up Comment #6, bug #27153 (project xboard):
After seeing in Git that H.G. Muller made pre-move fixes for Winboard I
downloaded and compiled the final 4.4.0 tonight, unfortunately problem remains
for xboard.
___
Reply to this item
Follow-up Comment #8, bug #27153 (project xboard):
Premoving does not work when you try to move a piece onto
one of your own pieces (which you expect to be captured by
your opponent).
___
Reply to this item at:
Follow-up Comment #10, bug #27153 (project xboard):
Also note, that these kind of premoves (to a piece of your own
colour) can only be made by dragging the piece, not if you just click the
from and to squares.
This was the same in xboard 4.2.7.
URL:
http://savannah.gnu.org/bugs/?27642
Summary: Clock jumps strangely in engine mode
Project: XBoard
Submitted by: None
Submitted on: Fri 09 Oct 2009 07:31:33 AM UTC
Category: None
Severity: 3 - Normal
Follow-up Comment #1, bug #27642 (project xboard):
Does this also happen when you run XBoard with the option -niceEngines 20?
It could be that what you see is the result of the engins and xboard competing
for CPU. I have no explanation why such contention would be different than in
4.2.7, but
Follow-up Comment #2, bug #27642 (project xboard):
-niceEngines 20 doesn't change anything.
You have to try several times. Sometimes the 2nd second
is almost of normal length and sometimes it's almost
completely skipped.
If your clock is already at less than 10secs ,say 8.3
after engine moves
Follow-up Comment #4, bug #27650 (project xboard):
I checked at FICS: style12 board strings don't get split, even
with width set to 32 (=minimum).
So I removed the rejoining code and found no problems so far.
Output is nicely wrapped again. I consider this solved for me. No action
from your side
Follow-up Comment #5, bug #27650 (project xboard):
Unfortunately this is not true for every ICS (in particular not for the
open-source Lasker 2.2.3 code). Also, board that are part of a move list (with
non-standard opening position) seem to be more critical. I just had to patch
the code this
Follow-up Comment #7, bug #27642 (project xboard):
I don't know, if I (as the original submitter) am supposed to post my test
result. Nevertheless, it works now. Also the Segfault is repaired. Thanks.
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?27656
Summary: Autoqueen with premove
Project: XBoard
Submitted by: None
Submitted on: Sun 11 Oct 2009 09:53:11 AM UTC
Category: None
Severity: 3 - Normal
URL:
http://savannah.gnu.org/bugs/?27666
Summary: misc shogi on FICS
Project: XBoard
Submitted by: None
Submitted on: Sun 11 Oct 2009 11:54:32 AM UTC
Category: None
Severity: 3 - Normal
Item
URL:
http://savannah.gnu.org/bugs/?27667
Summary: PV line missing in analysis window
Project: XBoard
Submitted by: None
Submitted on: Sun 11 Oct 2009 01:46:42 PM UTC
Category: None
Severity: 3 - Normal
URL:
http://savannah.gnu.org/bugs/?27668
Summary: e.p. field still not passed to engine
Project: XBoard
Submitted by: None
Submitted on: Sun 11 Oct 2009 02:10:35 PM UTC
Category: None
Severity: 3 - Normal
Follow-up Comment #1, bug #27656 (project xboard):
I have given this some thought, and there seems to be a deep logical conflict
between not wanting the promotion dialog to pop up on invalid moves, and have
it pop up on a premove. Without a major re-design it does not seem possible to
have both.
Follow-up Comment #1, bug #27666 (project xboard):
Well, one thing is sure: this is not Shogi. Shogi is played on a 9x9 board.
There is no way to prevent ICS operators picking a name for their boards that
is identical to the name of an XBoard variant, while it is in fact a board for
an
Follow-up Comment #3, bug #27666 (project xboard):
For me it did, except the Gothic case, which I think is a server problem, not
an XBoard problem. (OK, admitted, a segfault is not the best kind of error
message...)
H.G. Muller
___
Reply
Follow-up Comment #2, bug #27656 (project xboard):
Good to know. A premoved stalemate would make me very sad :-)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27656
___
Message
Follow-up Comment #4, bug #27666 (project xboard):
OK, I fixed the Gothic examining case on the ICS. Unfortunately the ICS
handles it (like any variant switch, e.g. normal - crazyhouse) in such a way
that you get the board first, without knowing what the variant is, and only
sends you the
Follow-up Comment #4, bug #27656 (project xboard):
I also have thinking about alternative ways to enter under-promotions. One
idea I came up with was to move the Pawn off-board in stead of on the last
rank. The X-coordinate could still be used to indicate where you want to
promote.
Yet another
Follow-up Comment #3, bug #27687 (project xboard):
Well, software just working is not an option for softare that has the
purpose of suporting other software (such as a GUI for an engine). The main
culprit here is the package management system, which fails to recognize a
dependency between XBoard
Follow-up Comment #5, bug #27687 (project xboard):
No, that is not needed. What you propose comes over quite well. The matter is
just if we want it or not. You should realize that XBoard currently is kind of
a backward version of WinBoard, and that we are working to port WinBoard
functionality
Follow-up Comment #5, bug #27666 (project xboard):
Yes, I already noticed, that Get move list is now necessary for proper
variant recognition. Otherwise observing a suicide game (with xboard in normal
mode) shows some effects, like move animation disabled, when kings are not on
the board.
misc
Follow-up Comment #6, bug #27666 (project xboard):
Get Move List has always been necessary for variant recognition, as ICS
simply don't send any variant indication with their boards. When al variants
were played on 8x8 boards with the same pieces this was a whole lot less
critical, though. In
Follow-up Comment #3, bug #27667 (project xboard):
Another thing for the Engine output window:
Start xboard with one engine. Activate analysis mode. Open the Engine
output window (still manually). The window layout is for 2 engines shortly,
then changes to 1 engine. But when you resize the
Follow-up Comment #4, bug #27667 (project xboard):
Well, that it is experimental makes it all the more important to cure bugs!
But let me make sure what exactly you are seeing:
The Engine-Output window in fact alays contains sections for both engines,
but (mimicking WinBoard) I use the dirty
Follow-up Comment #5, bug #27656 (project xboard):
I think, an unneeded popup on an invalid move doesn't hurt at all, while a
missing popup (when you are expecting one) can cost the game.
Underpromotions are not common, but virtually never is not my experience -
I wouldn't use an interface that
Follow-up Comment #6, bug #27667 (project xboard):
And this switch in window layout is triggered by you resizing the window?
For me this does not happen, but this could be a difference in the X-tools
library. It looks like the resizing routine in your library does rescale the
contents of the
Follow-up Comment #7, bug #27667 (project xboard):
Yes, it's triggered just in the moment when releasing the mouse button, after
dragging the window larger.
I must admit, that my Xlibs are pretty antique (9 years old), but any upgrade
is always such a pain (breaking things that worked for years,
Follow-up Comment #8, bug #27667 (project xboard):
I just tried Xaw3D instead of Xaw (same age), and it works there. So I have a
simple workaround.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27667
Follow-up Comment #1, bug #27699 (project xboard):
Well, I knew this was possible from the moment I added these pieces to the
menu, but it seems so obvious a wrong thing to do that I never bothered trying
to make it impossible. There are simpler ways to make XBoard close.
One has to strike a
Follow-up Comment #7, bug #27666 (project xboard):
With the lastest git my points are fixed.
I cannot decide for:
1. the bug mentioned in comment #6.
2. bsetup on VICS (xboard or server issue?)
Thanks!
___
Reply to this item at:
Follow-up Comment #7, bug #27630 (project xboard):
The new convert program segfaults. Reason is in main():
char *namedoesn't allocate space for the string so sprintf(name,...)
dies.
char name[80] works better.
So currently not all pixmaps are correct.
Follow-up Comment #3, bug #9593 (project xboard):
I think this bug was peculiar to the Analysis window, which has now been
removed entirely from WinBoard / XBoard. The Engine-Output window that
replaces it does not pop up automaticaly when an engine writes to it, and thus
cannot suffer from the
Follow-up Comment #8, bug #27666 (project xboard):
I can confirm that the bsetup and disconnect problem are server errors. The
hack I made supports variable board size, and I initialize it in th boad-setup
routin that starts a new game. Apparently bsetup uses another routine that
does not set nr
Follow-up Comment #1, bug #27715 (project xboard):
I tried this on a third system:
ad 1) : I wasn't able to reproduce this effect on that system.
ad 2) : The white rectangle isn't even visible there. But the bug shows when
doing this:
xboard -variant courier
Then switch to variant normal.
Follow-up Comment #10, bug #27667 (project xboard):
With point 1. I mean:
In xengineoutput.c replace
XtCreatePopupShell(name, transientShellWidgetClass,
with
XtCreatePopupShell(name, topLevelShellWidgetClass,
using the already existing #if TOPLEVEL.
Follow-up Comment #9, bug #27630 (project xboard):
Another problem in convert appears on systems (like mine) where char
defaults to signed char.
Pieces of size 129 aren't handled by Load() because char h,w;
are negative in that case and the for loops are skipped.
unsigned char h,w; should
Follow-up Comment #11, bug #27650 (project xboard):
I only tested XBoard.
All options work like expected. Also resizing xterm did update width.
The minor differences between internal and ICS wrapping can be ignored.
___
Reply to this
Follow-up Comment #10, bug #27630 (project xboard):
The unsigned-char bug in pixmaps/convert.c will be fixed. The md?33.xpm
bitmap was defective because the WinBoard original winboard/bitmaps/m33s.bmp
was accidentally saved as a 16M-color bitmap in stead of a monochrome bitmap.
This should
Follow-up Comment #11, bug #27667 (project xboard):
I will have a look at why the icon does not display, and put in the depth.
I am not sure if the top-level thing is desirable. In WinBoard the default is
that all auxiliary windows open and close together with the main window, and
this works
Follow-up Comment #12, bug #27630 (project xboard):
I manually removed all leakings and stray pixels I could find, and attached
them (hope that works). I did it with gimp/linux in the bmp files, so you can
use them too, if you want. I could only test the resulting pixmaps after
conversion, but
Follow-up Comment #12, bug #27667 (project xboard):
With topLevel the window still pops up in front of the board (at least with
my Xlibs), it only doesn't resist to go behind later, just like good old
AnalysisWindow. Your screen also seems to be much larger than mine, because I
can't do without
Follow-up Comment #13, bug #27667 (project xboard):
Well, it depends on how large you make the XBoard main window. As I usually
run with engines, and thus want the engine-output open, I make sure XBoard
pops up small enough to leave ample space for it.
But I have seen that other windows whih in
Follow-up Comment #14, bug #27153 (project xboard):
Not sure if the fix of HGM is included in 4.4.1pre but FYI I compiled it
today and pre-move still not working.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27153
URL:
http://savannah.gnu.org/bugs/?27751
Summary: Negative holding counts displayed?
Project: XBoard
Submitted by: None
Submitted on: Mon 19 Oct 2009 07:48:40 AM UTC
Category: None
Severity: 3 - Normal
Follow-up Comment #1, bug #27751 (project xboard):
When you load a bughouse game with smoves the ICS does not tell you what
you were holding on every move. When XBoard grabs the game from the move list,
it reconstucts the positions from the (known) initial setup of bughouse by
playing the moves
Follow-up Comment #3, bug #27715 (project xboard):
OK, apparently the menu bar (which in my system is unobservable against the
background) apparently did not stretch all the way to the right edge of the
window, but was just the size of the menu strings. As a result scaling the
window would scale
Follow-up Comment #4, bug #27715 (project xboard):
I debugged (1) a bit, because I feared it might be not reproduceable. I saw
that when switching to bughouse mode DrawPosition is called twice. First
with fullRedraw=1, then with fullRedraw=0.
When switching back to normal mode, DrawPosition is
Follow-up Comment #2, bug #27751 (project xboard):
To me just not displaying the buggy characters would have been the solution
(and to make sure there are no other side effects by those unknown holdings).
___
Reply to this item at:
Follow-up Comment #3, bug #27751 (project xboard):
This was essentially what WinBoard was doing. Having negative counts can
potentially produce unpredictable effects when converting the position to a
FEN (for saving the position, or sending it to an engine with a setboard
command), so it is
Follow-up Comment #5, bug #27715 (project xboard):
Can you tell which call to DrawPosition exactly you had to fix? The one in
VariantSwitch, which is invoked whenever XBoard receives a board from the ICS
that does not fit the current variant, now does a full redraw. Which is the
other one?
The
Follow-up Comment #6, bug #27715 (project xboard):
I did just a dirty change to see, if that helps:
void DrawPosition(fullRedraw, board)
/*Boolean*/int fullRedraw;
Board board;
{
printf(FullRedraw: %dn,fullRedraw);
XDrawPosition(boardWidget, 1/*fullRedraw*/, board);
}
So I
Follow-up Comment #8, bug #27715 (project xboard):
That's clear. My change wasn't meant to be a permanent fix. :)
My last sentence was badly formulated, should have been:
So if you do a fullredraw on any variant switch, that must be sufficient.
Follow-up Comment #5, bug #27751 (project xboard):
This fix works for me in v4.4.1.20091019.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27751
___
Message sent via/by
Follow-up Comment #10, bug #27715 (project xboard):
Ad 1 : I don't see that VariantSwitch gets called when you switch from
bughouse to normal in ICS-mode (with smoves command).
But exactly that would repair the problem. So I further investigate this.
Ad 2 : The menu bar is ok now. The title bar
URL:
http://savannah.gnu.org/bugs/?27760
Summary: debug printf in backend.c
Project: XBoard
Submitted by: None
Submitted on: Tue 20 Oct 2009 07:35:08 AM UTC
Category: None
Severity: 3 - Normal
Follow-up Comment #16, bug #27667 (project xboard):
OK, sorry, I forgot all about the other two points. The depth I have now
implemented in XBoard. Since in the 5 years that this feature exists in
WinBoard no one ever requested it there, I left WinBoard as it was. (So I
broke the equivalence of
Follow-up Comment #4, bug #10273 (project xboard):
I assume the talk to FICS wasn't successful, or am I wrong?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?10273
___
Message
Follow-up Comment #15, bug #27715 (project xboard):
I see in my enthusiasm, I regressed something. VariantSwitch should force a
full redraw of the current board (boards[currentMove]), not of the initial
position (what InitPosition(TRUE) would do.)
To prevent the flicker when giving an smoves
Follow-up Comment #4, bug #27772 (project xboard):
It seems FICS sends holdings both before and after the board. Those before
the board were then overwriting the holdings of the previous board, of course.
I now tried to fix this by hiding a flag in each board that remembers if the
holdings were
Follow-up Comment #5, bug #27772 (project xboard):
Remark: Looks like the holdings sent before a capture always have that
format:
b1 game 174 white [PPR] black [NNB] - WR
And afterward the board was sent that:
b1 game 174 white [PPR] black [NNB]
That might be useful to differentiate the two,
Follow-up Comment #1, bug #27790 (project xboard):
It seems that when observing a game, one _always_ has to fetch a move list to
know which variant it was, even if you see the very first board. FICS gives an
indication of the variant after saying You are now observing game #., but
ICC doesn't,
Follow-up Comment #2, bug #27790 (project xboard):
Tried that and the variant is recognized now. But as in that manual case I
described, the initial board of the observer gets an extra shuffle in all wild
variants. The position is repaired after white's first move, though.
Apropos FRC - there
Follow-up Comment #8, bug #27772 (project xboard):
I guess the problems are indeed related: WinBoard only sounds bells that are
printed to the console. Normally the bells are appended to the prompt, or on
an empty line. But I guess when something is captured in crazyhouse, FICS
sends the
Follow-up Comment #9, bug #27772 (project xboard):
Sure it can be worked around, but it's normally a good thing to have a closer
look to strange behaviour. There could be more serious things behind it.
As I see the bell is always sent on a seperate new line just before the
board:
^Mfics%
^Mb1
Follow-up Comment #11, bug #27772 (project xboard):
Strange! For me the Bell got prefixed to the prompt following the holdings:
ICS: 12 15b1 game 238 white [P] black [N] - WP 12 15 07fics% 12 1512
rn--kb-r ...
I put in a patch that looks at the matched part when recognizing the prompts
after
Follow-up Comment #3, bug #27790 (project xboard):
OK, I think I fully understand how it works now. The new game starts with a
board, but as the board oof FRC is not recognizably strange, you stay in
VariantNormal. (That it is not the regular opening position is no clue, as
there are many wilds
Follow-up Comment #13, bug #27772 (project xboard):
I used telnet freechess.org|tee log.txt to capture the strings (manually
setting style 12). I don't know, if that's a proper way.
The whole beep-thing was more to make sure, that a character isn't
overwritten by accident, so that bell 0 would
Follow-up Comment #14, bug #27772 (project xboard):
Well, it seems that for me, the bell character is almost always prefixed to
the prompt. I captured it from the winboard.debug file, but that should not
really matter. It might be that there is a kind of race condition in the
server, where two
Follow-up Comment #15, bug #27772 (project xboard):
Bell() - RingBell()
Works now.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27772
___
Message sent via/by Savannah
Follow-up Comment #16, bug #27772 (project xboard):
Yeah, that was the nasty part. RingBell() strangely enough is the move sound
in WinBoard, and there is no way to call the sound produced by the bell
charactr from the back-end. Only the front-end routine that sends text to the
console produces
Follow-up Comment #1, bug #27799 (project xboard):
Not sure I understand the lex syntax completely. The +, is that a meta
character for one or more, like * means zero or more times, and ? means
one or zero? And unescaped parentheses group these operators?
Btw, now that I look at parser.l, what
Follow-up Comment #17, bug #27772 (project xboard):
I guess I found a front-end-independent fix:
In stead of RingBell() or my new routine Bell(), simply call:
SendToPlayer( 07, 1);
This sends a bell to the console, which both in WinBoard and XBoard produces
the required sound! :-D
H.G.
Follow-up Comment #2, bug #27799 (project xboard):
I never used flex before, but I think White mated isn't even desired;
wouldn't that return a win for white?
It still seems to match by ignoring the final d.
Also wins alone seems to match, because of missing brackets in the right
half.
Follow-up Comment #4, bug #27799 (project xboard):
Without guarantees this looks better:
(([Ww](hite)?)|([Bb](lack)?)) (([Mm]ates)|([Ww][io]n(s)?)).* {
return (int) (ToUpper(yytext[0]) == 'W' ? WhiteWins : BlackWins);
}
(([Ww](hite)?)|([Bb](lack)?)) (([Mm]ated)|([Ll]os[tes]+)).* {
Follow-up Comment #7, bug #27799 (project xboard):
I wasn't sure about the .* . I just saw in the original version, that a
wins eats the rest and a white mates doesn't.
So I unified that and added Without guarantees.
Feel free to change that :)
Follow-up Comment #22, bug #27772 (project xboard):
It seems the prompts fail to be filtered, because during game play, the
prompt following a board for the opponent's move is separated from the latter
by an empty line. (Actually by nrnrr, but XBoard fiters out any 'r' in the
low-level input
URL:
http://savannah.gnu.org/bugs/?27810
Summary: Copy Game / Position do not work in XBoard?
Project: XBoard
Submitted by: None
Submitted on: Mon 26 Oct 2009 10:28:29 AM UTC
Category: None
Severity: 3 -
Follow-up Comment #1, bug #27810 (project xboard):
I use that a lot, and it always worked. But I don't paste with Ctrl-V, but by
pressing the middle mouse button.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27810
Follow-up Comment #2, bug #27810 (project xboard):
There seem to be 2 different copy/paste mechanisms.
(1). copy by marking text with the mouse / paste by middle mouse button.
This even works in xterm,vi etc.
(2). Ctrl-c Ctrl-v. This seems to require special application assistance.
Those
Follow-up Comment #3, bug #27810 (project xboard):
This might be a gedit rather than an xboard problem, then. I can use Copy
Game on one XBoard, and then Paste Game to load it in another. But I could not
copy the game into gedit. Ctrl-V does not work. I have no middle mouse button
on my laptop,
Follow-up Comment #1, bug #27828 (project xboard):
OK, I see wha you mean, in WinBoard. (Where you using WB too, or XBoard?) It
would be fancy if the Game List popped up with the same game selected as is
currently loaded, so that the next-game button in the Game List would do the
same as the
Follow-up Comment #2, bug #27828 (project xboard):
I only use Xboard. That might be the reason why I never saw a filter field. I
don't have a strong preference in that matter - I was even considering not to
report that at all.
___
Reply
Follow-up Comment #5, bug #27826 (project xboard):
I can only test XBoard. All options work as expected with git
2b102a5aee6ecd7f801208d2c6f6aacf59397ee4.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27826
Follow-up Comment #9, bug #27799 (project xboard):
I almost regret that I tested this:
Load the file from the original submitter into xboard.
Save an unchanged copy to a different file.
Loading the copy gives: Illegal move: 17 d4
The first difference seems to be in the comment on 15. exd5,
Follow-up Comment #12, bug #27810 (project xboard):
Both paste methods work now in opera mail. Also -pasteSelection works as
expected.
I just had to remove the XA_UTF8_STRING stuff, because that's not provided by
my X-libs, but that's ok - my system must be the oldest still in use :)
Remark
Follow-up Comment #10, bug #27799 (project xboard):
OK, problem here is that the parser recognizes several types of comments,
between {} or (). XBoard then strips off the delimiters, appends all comments
belonging to the same move to each other, and saves between {}. This loses the
(), and
Follow-up Comment #5, bug #27790 (project xboard):
The points mentioned in original submission comment #2 are working now.
I haven't tested the follow-up points mentioned in the commit messages
regarding Variant Switch
___
Reply to this
Follow-up Comment #2, bug #27889 (project xboard):
Well, I just compiled 4.4.1 under Ubuntu 8.04, and the board appears for me,
before the first game of the match
The other behavior you describe is intended. It is more interesting to look
at the final position of the previous game, than to the
Follow-up Comment #3, bug #27889 (project xboard):
It's in 4.4.1 (and older) and I could fix it for me by changing
Reset(FALSE, TRUE);
to
Reset(TRUE, TRUE);
in function NextMatchGame() in backend.c.
___
Reply to this item at:
Follow-up Comment #6, bug #27889 (project xboard):
I don't understand the pause can be very short. Even with my fix the end
position is visible for 10 seconds. It just doesn't extend into the next game
anymore.
However, thanks for repairing the other about 15 points I reported in the
last
Follow-up Comment #7, bug #27889 (project xboard):
That depends on your setting of -matchPause. I usually set the pause to the
shortest possible value 10 (msec) when both engines support ping. The pause is
only needed to make sure the engine that is thinking gets the time to make its
move when
URL:
http://savannah.gnu.org/bugs/?27901
Summary: Incorrect error message when in double chess and
trying to capture one of the attacking pieces
Project: XBoard
Submitted by: None
Submitted on: Sun 01 Nov 2009 14:43:38 UTC
Follow-up Comment #1, bug #27901 (project xboard):
In which version are you getting this, and is this WinBoard or Xboard? And in
which mode (local engine, ICS, game viewer; Edit Game or Machine White /
Black). And is legality testing on/off?
I cannot reproduce it with WinBoard 4.4.1 and any
Follow-up Comment #1, bug #27857 (project xboard):
Thanks for the suggestion. I was not aware of this special treatment of the
draw command by FICS. It seems to me XBoard should definitely support it. An
alternative to the UI you propose would be to hit F6 when it is your move, and
then move.
Follow-up Comment #2, bug #27901 (project xboard):
Winboard 4.4.0
I can try Winboard 4.4.1 when the binaries are out.
Legality test on.
I originally got it in a Fics game, but reproduced it setting up a position
playing again Fairy-Max.
Retrying it now I see that:
Dragging the Queen to
Follow-up Comment #3, bug #27901 (project xboard):
OK, thanks. I tested it in 4.4.0, and it is indeed as you say, even without
engine in edit-game mode. But the mouse handler was completely re-written for
4.4.1, in conection with premove and the promotion popup fix, and I guess that
also fixed
Follow-up Comment #2, bug #28077 (project xboard):
It builds fine with the latest code in git.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28077
___
Message sent via/by
Follow-up Comment #1, bug #31756 (project xboard):
This is an Xaw3d bug: sizing is not done by XBoard but by the window manager.
XBoard specifies that the top of the lower pane and the bottom of the upper
pane should be 'chained' proprotionally (XtRubber). If Xaw3d does have a funny
1 - 100 of 117 matches
Mail list logo
