Cannot scroll canvas display out of range

[westram]

Motif version allowed to scroll the display into "empty range" outside the actually drawn graphics using the middle button. gtk version denies doing that.

Problems occurring by gtk behavior:

1. In the radial , text is not completely inside the scrollable area.
2. another related problem occurs in ARB_SECEDIT:
   • set the root to a loop at the outside of the structure
   • rotate the structure
   • ⇒ parts of the structure easily get unaccessible

Problem 2. is obviously caused by some missing size-announcement after the structure change (motif version does not adapt scrollbars when that happens). With motif that was acceptable, because you could use the middle to scroll the display where ever you want. With gtk you can't. But I fear adding the missing size-announcement will trigger other unwanted behavior - like resetting zoom or changing scroll-position when EDIT4-cursor moves vertically through the sequences in the editor while displaying secondary structure.

If there is an simple way to allow scrolling the display outside the actually drawn area in gtk, i would prefer that way, since getting the size calculations right is always a PITA (as you've seen with EDIT4).

[epruesse]

1 is probably due to wrong text width calculations — does it work in motif?

When scrolling with middle , AWT_canvas::scroll() is called, scrolls the window and sets the scrollbars. Before setting the scrollbars, canvas clamps those to world size. Setting them triggers a second scroll, which moves the image back.

I could disengage the scrollbar change event when the scrollbar position is changed manually, which was probably the motif behavior. Better might be to alter the worldsize appropriately, that way the scrollbars would also be rendered correctly.

[westram]

Replying to epruesse:

1 is probably due to wrong text width calculations — does it work in motif?

Text calculation is correct - it works in motif and it also works in gtk. But arb provides two modes for zooming - one taking -structure- and -text-size into account, the other only taking the -structure-size. You can toggle these modes using 'ARB_NTREE/Properties/Tree Settings/Text? zoom/pad'.

When scrolling with middle , AWT_canvas::scroll() is called, scrolls the window and sets the scrollbars. Before setting the scrollbars, canvas clamps those to world size. Setting them triggers a second scroll, which moves the image back.

That's maybe the reason why it flickers.

I could disengage the scrollbar change event when the scrollbar position is changed manually,

With 'manually' you mean 'by code'?

which was probably the motif behavior. Better might be to alter the worldsize appropriately, that way the scrollbars would also be rendered correctly.

It's quite difficult to get sth like a "correct" worldsize:

• if text is considered to be part of the world, the worldsize changes when changing the current zoom-factor
• if text is not considered, the worldsize does not change by zooming, but then there is some text outside "the world"

Furthermore resetting the display to the worldsize also affects zooming with wheel:

• if the display shows all (unzoomed) and you move the to one treepart near the border and zoom in there, the does not only zoom, but also moves. Motif version always keeps the treepart fixed under the position (at least it tries to).
• same applies when zooming out: the starts moving towards the upper-left corner. In motif version the world-location under the cursor remains the same.

[epruesse]

When scrolling with middle , AWT_canvas::scroll() is called, scrolls the window and sets the scrollbars. Before setting the scrollbars, canvas clamps those to world size. Setting them triggers a second scroll, which moves the image back.

That's maybe the reason why it flickers.

Among other things. The concept in GTK (and all others, AFAIK) is that only the draw CB actually does drawing. All the other CBs only invalidate regions, so that those can be summarized and drawing is only done once.

I could disengage the scrollbar change event when the scrollbar position is changed manually,

With 'manually' you mean 'by code'?

… changed by ARB, not from the GTK/User side.

[epruesse]

fixed by r10742

[westram]

Replying to epruesse:

fixed by r10742

Great - works fine