OpenCPN Version 2.4 Beta Build 506

[HappySeagull]

Ok,I'll shut up!...I was a little worried it was a false alarm again.

[HappySeagull]

Well,not quite yet...You're sure you've got it eh?Because I fixed it here and can no longer get a crash.

[ChuckSK]

I finally trapped the crash at chcanv.cpp line 9068.

[BluegillBoy]

(searched this thread, didn't find anything about this, but appologize if I'm pointing out a known issue.)

Cruising southern Lake Michigan I find a skewed chart in Hammond Harbor. Chart 14926.11 (raster, NOAA).

when I zoom through it won't come on screen. when I scroll through by chart scale it appears unquilted and then locks the scale so I can no longer zoom in or out until i set another scale up or down. then all functions as before.

the toolbox still shows quilting turned on so it hasn't jumped out of quilting.

"show skewed charts as north up" is checked and the chart is shown north up.

running XP SP3, all Lake Michigan raser charts are loaded, no vector charts.

see screen grab attached.

[bdbcat]

ChuckSK....

Right you are. This is the area of interest.
Member element m_bm_cache_vp is un-initialized, sometimes....

Thanks
Dave

[HappySeagull]

Originally Posted by BluegillBoy

(searched this thread, didn't find anything about this, but appologize if I'm pointing out a known issue.)

etc.....

running XP SP3, all Lake Michigan raser charts are loaded, no vector charts.

see screen grab attached.

Hi,BlueGillBoy.

Polyconics won't quilt....that's what it is...I see the little red cones in the screen grab and that's how I know.
um,there was a similar thread about these Great Lakes Charts a month or two ago you may find interesting,if you run into more trouble with these.I'll PM it if I can find it.

also,per skew,http://www.cruisersforum.com/forums/...tml#post671225

aah,here.
http://www.cruisersforum.com/forums/...tml#post652114

[cagney]

BluegillBoy

Your picture shows a chart where OpenCPN is in single mode. The program behaves OK, with one or two small changes. The quilt tick box in the ToolBox is not changing with the quilt status. As others has already reported, to get F9 to work with toggling quilting, the quilt box has to be ticked first. This is also a change.
In your case we have skewed polyconic charts (perhaps we need another statusbar chart icon for this?). I doesn't quilt because it's skewed.
Polyconic charts in them self certainly quilts, but I think that there used to be a warning for decreased accuracy.


Thomas

[HappySeagull]

Cagney,Thanks for correction!that's new in these Betas!Polyconics quilt!
(excuse:almostall of mine are large scale plans so always at the end of the chart bar)

[cagney]

Further testing reveals that Polyconic charts now quilt similar to Tmerc charts. There used to be a warning for poor geo referencing when quilting Polyconics and Mercs. They no longer mix. Polyconics and Mercs are now quilted strictly separate. The transition is seamless when zooming in/out. As for Tmercs, you will see black where there is no Polyconic coverage. Zooming out auto switches to Merc quilting ( provided there are Mercs of smaller scale loaded).

Thomas

[antxon]

Dave & Fabbian,

Originally Posted by fgd3

Yes, it's different for me. When I zoom with the scrolling device the point under the mouse pointer jumps to the center of the screen and stays there as I scroll in and out. (Did I mention I'm running Windows Vista?) Of course, you will get that behavior only if you don't move the mouse while scrolling. And it took me several hours to figure out what was happening because, like you, I thought at first that I had to chase the point of interest with the mouse pointer.

Test it carefully. Pick some readily identifiable feature away from the center of the display and scroll in and out without moving the mouse. Let me know how it works for you. If you're using a real mouse it might be harder to avoid accidentally moving the mouse as you scroll than it is for me. I'm using the scroll bar on my laptop's touchpad, so accidental mouse movement is less likely.

Since I'm interested in getting a closer look at the area under the mouse pointer I like having it moved to the center of the screen. That prevents some important details from disappearing off the edge as I zoom in closer. And I think everything would be more apparent if the mouse pointer were moved to the center of the screen along with the point of interest.

I wouldn't mind if the point of interest were kept under the mouse pointer as you suggest. If a nearby feature fell off the edge it would be simple enough to drag the chart so it was back in the frame. Either way would be an improvement over the current behavior.

Fabbian

Sorry for this late reply, I was on the water again. Fabbian, I understand what you mean, and you are right. I didn't notice it because as you pointed I use a real mouse. Now I am not sailing and I can get the mouse not to move, but in real sailing conditions that is very hard to get. I never did in last 10000 miles...

I agree that both aproaches to the zoom topic can be an improvement, centering the chart and move the pointer accordingly to the center, or keeping zoomed area under the pointer.

Since OCPN has currently two modes to manage zoom, what i'd suggest is to adapt both aproaches to each of the zoom modes:
If the Wheel-Zoom-to-Cursor is not enabled, the behavior could be the first aproach but clicking first to center the area: So click to move area AND pointer to the center, then scroll to zoom. This would be more "touchpad oriented".
If the Wheel-Zoom-to-Cursor is enabled, the second aproach would be taken: wheel twist would not center the area on the screen nor the mouse pointer, instead the chart area would stay under the pointer and the zooming would be focused in the pointer location. This would be the "mouse oriented" way. I kindly suggest this as it is by far the most usual way of zooming with the mouse for any software aimed to visualizing big graphical documents, from navigation software as Maxsea to PDF readers as Adobe's (CTRL+SCROLL) or 3d modelling soft as Google SketchUp and, as Hamish pointed, is incredibly fast and intuitive.

This way both options have their own coherence and are adapted to real sailing conditions, and would be a great enhancement from the current "in-between" aproach.

Antonio

[bdbcat]

Antonio....

Thanks for your thoughtful comments.

I wonder about your proposal:

1. Wheel zoom off:
I find it distracting for the mouse pointer to jump around the screen. Using a real mouse, if we move the mouse to center screen on a click, then I find I am always having to pick up the mouse and put it back on its pad, as the "warp" has caused the physical mouse position and the pointer to get incoherent.....

2. Wheel zoom off.
I do not understand your proposal for "wheel zoom to cursor".

Lemme try it another way that aligns with the code.
On zoom-in, I think you want to leave the pointer where it is (pixels on the screen), zoom-in the chart, and shift the chart as required so that the lat/lon of the pointer is the same before and after the zoom.

This approach has problems, maybe. A zoom-in could certainly drive the pointer lat/lon off the screen. Where do we put the pointer then?

Or maybe I just don't get it

Looking for enlightenment...
Dave

[antxon]

Originally Posted by bdbcat

Antonio....

Thanks for your thoughtful comments.

I wonder about your proposal:

1. Wheel zoom off:
I find it distracting for the mouse pointer to jump around the screen. Using a real mouse, if we move the mouse to center screen on a click, then I find I am always having to pick up the mouse and put it back on its pad, as the "warp" has caused the physical mouse position and the pointer to get incoherent.....

2. Wheel zoom off.
I do not understand your proposal for "wheel zoom to cursor".

Lemme try it another way that aligns with the code.
On zoom-in, I think you want to leave the pointer where it is (pixels on the screen), zoom-in the chart, and shift the chart as required so that the lat/lon of the pointer is the same before and after the zoom.

This approach has problems, maybe. A zoom-in could certainly drive the pointer lat/lon off the screen. Where do we put the pointer then?

Or maybe I just don't get it

Looking for enlightenment...
Dave

Dave,

It's me who thank you for accepting feedback.
About the first option, maybe you are right on finding it a bit confusing, though its hard to tell, I never tested something like this. But it's true that the intuitive connection between mouse movement and pointer movement gets broken somehow.
About the second, you can see exactly what I mean if you open a pdf on adobe reader and press ctrl+scroll to zoom in the document. Once the document is zoomed bigger than the screen (if not, the document will always be centered), the zoom behavior is exactly what I mean. Zoom in and out and you will see how simple and intuitive it is. And you can check that the pointer never can't get out of the screen. But maybe that is a headache for you to develop...

I hope this helps to explain it. Thank you again,

Antonio

[fgd3]

Originally Posted by bdbcat

Antonio....

Thanks for your thoughtful comments.

I wonder about your proposal:

1. Wheel zoom off:
I find it distracting for the mouse pointer to jump around the screen. Using a real mouse, if we move the mouse to center screen on a click, then I find I am always having to pick up the mouse and put it back on its pad, as the "warp" has caused the physical mouse position and the pointer to get incoherent.....

2. Wheel zoom off.
I do not understand your proposal for "wheel zoom to cursor".

Lemme try it another way that aligns with the code.
On zoom-in, I think you want to leave the pointer where it is (pixels on the screen), zoom-in the chart, and shift the chart as required so that the lat/lon of the pointer is the same before and after the zoom.

This approach has problems, maybe. A zoom-in could certainly drive the pointer lat/lon off the screen. Where do we put the pointer then?

Or maybe I just don't get it

Looking for enlightenment...
Dave

Dave, I agree with you that it is generally not a good idea to move the mouse pointer around on the screen. When wheel-zoom-to-cursor is disabled there is no need to move the mouse pointer because zooming is centered around the center of the screen. Nothing changes even if you move the mouse while zooming.

When wheel-zoom-to-cursor is enabled zooming (assuming you don't accidentally move the mouse) is exactly like clicking the mouse and then zooming with wheel-zoom-to-cursor disabled. The problem arises if you do move the mouse. Each time you move the mouse the next movement of the scroll wheel causes the chart to move before zooming. Using a real mouse on a moving boat it is nearly impossible to keep the mouse from moving. The farther the mouse is from the center of the screen the more pronounced the accidental chart movement.

That wouldn't be a problem if you kept the center of zoom and the mouse pointer aligned. The chart movement resulting from a small accidental mouse movement would result in only a small accidental chart movement. It doesn't matter if you move the mouse pointer to match the movement of the chart or zoom the chart around the mouse pointer, so long as the center of zoom and the mouse pointer remain together.

I think the better choice would be to keep the mouse pointer where it is and shift the chart around so that after zooming the lat/lon which was under the mouse pointer before the zoom is still under the mouse pointer. There's no risk of driving that lat/lon or the mouse pointer off the screen, although details close to the mouse pointer might be forced off the screen.

There's an easier way to fix the problem. Get rid of the wheel-zoom-to-cursor feature. Since you can achieve the same result with a single mouse click before zooming (without the chart movement caused by accidental mouse movement) it really isn't necessary. Just add a note in the documentation that zooming is centered around the center of the screen and if you want to zoom in on a different area just click the chart to put it in the center before zooming.

Fabbian

[Viking Sailor]

Dave,

I would like to see:

1) Right mouse click moves pointer position to center of display.

2) Right mouse hold drags chart.

3) Zoom wheel moves pointer to display center and zooms chart.

4) Jump to position -- centers chart at position and places pointer at position. (Lift clicking the mouse and dropping a WP should end up at the jump to position.) (Or, Jump to position and drop WP?)

Thanks for all your work,

Paul

[BluegillBoy]

Originally Posted by Viking Sailor

Dave,

I would like to see:

1) Right mouse click moves pointer position to center of display.

2) Right mouse hold drags chart.

3) Zoom wheel moves pointer to display center and zooms chart.

4) Jump to position -- centers chart at position and places pointer at position. (Lift clicking the mouse and dropping a WP should end up at the jump to position.) (Or, Jump to position and drop WP?)

Thanks for all your work,

Paul

A counter thought - right click is great when you've got a mouse. But I'm seeing much greater use of touch screens in navigation applications.

Add in the problems of a mouse sliding around while underway, and you'll be getting many more using touchscreens.

(my nav computer uses neither mouse nor keypad. simpler is better underway.)

Even with a good touch screen driver which typically will give a place to touch on the task bar to make your next touch on screen a right click, it's difficult and not exactly equivalent in all applications. as an example, it's really tough to get an AIS window open in OCPN on a touch screen.

so if there's temptation to implement any additional functionality with a right click, i'd advise being able to select whether or not an individual user wants it or turns it off or uses another work-around.

and now that you've got me thinking, how could the AIS box be brought up more easily on a touch screen? hmmmm...