#75 contig editor staden-2-0-0b6

[Alfred Beck]

I compiled the staden-2-0-0b6-src on an amd 64 bit system
(linux), reprot form configure:

External packages used:
curl: via /usr/bin/curl-config
zlib: DIR (system)
liblzma: DIR /package/staden/unix-rel-2.0.0b6/linux-x86_64
samtools: DIR /package/staden/unix-rel-2.0.0b6/samtools-0.1.7a
io_lib: via
/package/staden/unix-rel-2.0.0b6/linux-x86_64/bin/io_lib-config
Tcl: via /usr/local/lib/tclConfig.sh
Tk: via /usr/local/lib/tkConfig.sh
tklib:
/package/staden/unix-rel-2.0.0b6/linux-x86_64/lib/tklib0.5
Iwidgets:
/package/staden/unix-rel-2.0.0b6/linux-x86_64/lib/iwidgets
Itcl:
/package/staden/unix-rel-2.0.0b6/linux-x86_64/lib/itcl3.2
Itk:
/package/staden/unix-rel-2.0.0b6/linux-x86_64/lib/itk3.2
----------------------------------------------------------------------

My problem is that if I use fvwm as window-manager the the
contig-editor window of gap4 can not be resized.
If I use KDE as window-manager only the title and the first
button line is shown and on Xface only the title line is
shown. Do you know this and do you have a fix for this??

Thanks in advance
Alfred Beck

[James Bonfield]

Gap4's contig editor is rather ghastly in how it handles resizing.

Are you referring to resizing in Y or in X, as they differ? For whatever reason (forgotten now) we decided that the editor should automatically grow in Y so that it takes up as little screen real-estate as possible when dealing in low coverage reasons, but expand up to show as much data as possible when in deep regions. Unfortunately this strange relationship of one dimension being under the control of the program and the other under the control of the user just doesn't fit well with some window managers that like to keep track of windows in neat little pigeon holes for "application controls size" and "user controls size". I expect the reality is more complex than that, but the conflict still exists.

Add to this the fact that therefore growing in X could cause an additional sequence to be visible, hence requiring the window to grow in Y, and you've got a mess! An attempt at fixing this was to delay resizing by a short time, to try and prevent looping due to asynchronous delays in setting and querying sizes. Again it doesn't always behave properly.

A workaround is just to manually change the default size. This can be done by creating (or adding to) your $HOME/.gaprc file and adding these lines:

set_def CONTIG_EDITOR.MAX_HEIGHT 29
set_def CONTIG_EDITOR.SEQ_WIDTH 80
set_def CONTIG_EDITOR.NAMES_WIDTH 23

These are the defaults from the installed gaprc, but you can adjust them to whatever is appropriate for your display and font size.

Does this workaround the problem? I'm loathe to try and actually "fix" the resize problems as experience has shown me as soon as I get it working for one window manager it promptly breaks for another.

James

PS. Gap5 is fortunately far saner and just lets the user control both X and Y sizes, meaning it behaves sensibly. Having the consensus at the top makes this more attractive too so there's never a large blank space between sequence and consensus.

[Alfred Beck]

Dear James,

I mean in X, in the fvwm in our unix installation I can move the border to a other size, but it jumps back to the initialize position. The general size of this I can change with the .gaprc entry:

set_def CONTIG_EDITOR.SEQ_WIDTH 80

you noted, but in other window-manager tested KDE or Xface I can't change in X nor in Y. the sequence is not shown, only the title line (see above).
The problem that the our users working with gap4 prefer to use Xface and don't want to go back to KDE.

But one of them noted to me, if they change the contig_editor script of gap4 to allow the resize in Y (as is is set in gap5) the problem with Xface disappears and they can work with gap4 and can resize the window. After a short test it looks that it works stable.

btw. which windomanager should work? and a special newer Xwindows release, or the "good old one"?

Alfred