Beta Test / Technical

[cagney]

Dave

OK! Some observations about the latest git build. (Not including today’s patches ).


*No object query works when double clicking.
*The only way I can see way points range rings is to start a route and include the wpt with range rings. Even then it's just as long as I don't continue with the route past the wpt.
*Some funny effects in CM93 near a chart border, illustrated below.
Here is the normal view

Zooming in a bit and O looses control of the grid.


When zooming in further, the display goes back to normal.

Thomas

[CarCode]

Originally Posted by cagney

Dave

OK! Some observations about the latest git build. (Not including today’s patches ).


*No object query works when double clicking.
*The only way I can see way points range rings is to start a route and include the wpt with range rings. Even then it's just as long as I don't continue with the route past the wpt.
*Some funny effects in CM93 near a chart border, illustrated below.
Here is the normal view
Attachment 98718
Zooming in a bit and O looses control of the grid.
Attachment 98719

When zooming in further, the display goes back to normal.

Thomas

Same here with compiling 4.1.0 for Mac OSX and todays git patches.
Even more also layers items don't show up anymore.
And why the known bugs with Mac OSX are not fixed?

Gerhard

[Hakan]

Originally Posted by bdbcat

Hakan...
Sorry, I sometimes forget to try the build on all platforms before committing changes. My main work platform is linux...
Fixed in github now.....................
................I do appreciate it, and I don't mind the nagging

Thanks
Dave

Dave..
No problem, now builds fine again also in Win. Thanks

But to keep on nagging, the earlier described loss of focus on my XP system is still valid. No changes from my report here: http://www.cruisersforum.com/forums/...ml#post1761457

Håkan

[bdbcat]

Gerhard...

re:
And why the known bugs with Mac OSX are not fixed?

To what bugs specifically are you referring?

Thanks
Dave

[seandepagnier]

Originally Posted by Hakan

Dave..
No problem, now builds fine again also in Win. Thanks

But to keep on nagging, the earlier described loss of focus on my XP system is still valid. No changes from my report here: http://www.cruisersforum.com/forums/...ml#post1761457

Håkan

I have this focus problem on linux too, on both my platforms. I fixed with:

diff --git a/src/chcanv.cpp b/src/chcanv.cpp
index d98aa8f..f3c9009 100644
--- a/src/chcanv.cpp
+++ b/src/chcanv.cpp
@@ -1899,8 +1899,8 @@ void ChartCanvas::StopMovement( )
     m_rotation_speed = 0;
     m_mustmove = 0;
 #ifndef __OCPN__ANDROID__    
-    SetFocus();
-    gFrame->Raise();
+//    SetFocus();
+//    gFrame->Raise();
 #endif    
 }

Who knows the reason for it? Also the same logic appears when the program is first launched and pressing F6.

[bdbcat]

Sean...

When built for GTK, (not android), this code produces exactly the same output as is in OCPN 4.0.

Here is the O4 code:

void ChartCanvas::StopMovement( )
{
    m_panx = m_pany = 0;
    m_panspeed = 0;
    m_zoom_factor = 1;
    m_rotation_speed = 0;
    m_mustmove = 0;
    SetFocus();
    gFrame->Raise();
}

So this should not be new behavior, or at least this is not the best fix. There must have been another SetFocus()/Raise() invocation that crept in elsewhere...I am still having lots of Z-order troubles on Android...

Dave

[bdbcat]

Thomas, Hakan, & Gerhard...

Thanks for the reports.

The following issues are fixed now in github master:

1. Waypoint range rings in OpenGL mode now visible.
Thomas, do you suggest that rings should be added automatically to all waypoints (either dropped, or by route create) if selected in Options->Ships->Waypoints? And also to existing points as well, or only to new points? We never really talked about the global meaning of the Options->Ships->Waypoint->RangeRing selection...

2. Layer objects are now loaded and visible.

3. Double click object query re-enabled.

4. Hakan's Alt-Tab focus problem on XP: This relates to the ability to bring up the (disabled) Menubar temporarily by pushing the Alt key. The XP keyboard handler does a poor job of filtering the Alt-Tab sequence from the application. The result is that OCPN sees a single Alt-Down/Alt-Up sequence when ALT-Tab is pressed. I consider this an XP bug, but we must deal with it.
My solution is to disable the ALT-key temporary Menubar action entirely except on Mac where it seems to work reliably and be expected by Mac users.
I never liked this function, anyway. OCPN is designed to be used without a Menubar. It is clumsy when one is temporarily popped up, causing an entire re-layout of the canvas. Then you need a dummy mouse click to dismiss the menubar. Pfuuu....

So this feature is to be removed from O 4.1.
Hakan, please check your XP system with the current github master.

5. Thomas cm93 corruption: Cannot reproduce. O 4.1 has only minor cosmetic changes from O4 in the cm93 code. Thomas, will you check your configuration (OpenGL?) again, as well as on O4? Anyone else see cm93 corruption at cell boundaries?

Please note that some Flyspray tasks have been addressed in the 4.1 github master code, those marked as "Solution Pending". Test them if interested. More coming daily.

And, potential Beta testers: Thanks for your patience as we work through this housekeeping stuff. Gotta do it... Formal 4.1 Beta will start in a couple of weeks.

Thanks
Keep 'em coming....
Dave

[CarinaPDX]

Originally Posted by bdbcat

And why the known bugs with Mac OSX are not fixed?

To what bugs specifically are you referring?

I don't know if it is a bug, but I was unable to get OCPN working when built with 10.6. I reported it here: http://www.cruisersforum.com/forums/...ml#post1753479. I didn't receive any responses.

Still looking for any ideas...

Greg

[seandepagnier]

Originally Posted by bdbcat

Sean...

When built for GTK, (not android), this code produces exactly the same output as is in OCPN 4.0.


So this should not be new behavior, or at least this is not the best fix. There must have been another SetFocus()/Raise() invocation that crept in elsewhere...I am still having lots of Z-order troubles on Android...


Dave

wxQt has z-order issues from what I remember, but I can't pull your fork because of limited internet.

Why would additional SetFocus/Raise cause this? We need to find the reason this SetFocus() and Raise() is put here in the first place.. but I'm confused, why does SetFocus actually do the opposite and remove focus?

Anyway, here is another possible bug fix but I am only 95% sure, please review:

diff --git a/src/navutil.cpp b/src/navutil.cpp
index 55e883d..d0e3a62 100644
--- a/src/navutil.cpp
+++ b/src/navutil.cpp
@@ -2782,7 +2782,7 @@ void MyConfig::UpdateSettings()
 #endif
 
 #ifdef __WXQT__
-    SetPath ( _T ( "/Settings/QTFonts" ) );
+    font_path = ( _T ( "/Settings/QTFonts" ) );
 #endif
     
     DeleteGroup(font_path);

[CarCode]

Originally Posted by bdbcat

Gerhard...

re:
And why the known bugs with Mac OSX are not fixed?

To what bugs specifically are you referring?

Thanks
Dave

e.g. Flyspray #1655/1698

Gerhard

[Hakan]

Originally Posted by bdbcat

Thomas, Hakan, & Gerhard.............
............
4. Hakan's Alt-Tab focus problem on XP: This relates to the ability to bring up the (disabled) Menubar temporarily by pushing the Alt key. The XP keyboard handler does a poor job of filtering the Alt-Tab sequence from the application. The result is that OCPN sees a single Alt-Down/Alt-Up sequence when ALT-Tab is pressed. I consider this an XP bug, but we must deal with it.
My solution is to disable the ALT-key temporary Menubar action entirely except on Mac where it seems to work reliably and be expected by Mac users.
I never liked this function, anyway. OCPN is designed to be used without a Menubar. It is clumsy when one is temporarily popped up, causing an entire re-layout of the canvas. Then you need a dummy mouse click to dismiss the menubar. Pfuuu....

So this feature is to be removed from O 4.1.
Hakan, please check your XP system with the current github master.

Now the Alt+Tab function is working as expected in XP. Yes it was a pure XP issue but I do support your general point about the Alt key and menubar behavior.

1. Waypoint range rings in OpenGL mode now visible.
Thomas, do you suggest that rings should be added automatically to all waypoints (either dropped, or by route create) if selected in Options->Ships->Waypoints? And also to existing points as well, or only to new points? We never really talked about the global meaning of the Options->Ships->Waypoint->RangeRing selection...

Even though not directed to me I've an opinion if suitable: If I've the Options>.......>RangeRing checked it shall only be activated for new waypoints. So if the option is valid when a WP is crated also check the option for that particular WP.
Furthermore I think the ring(s) should only be visible when a WP is the next active WP in an activated route. But this opinion may change if someone has arguments for another view.

Thanks Håkan

[bdbcat]

Sean...

Re:
#ifdef __WXQT__ - SetPath ( _T ( "/Settings/QTFonts" ) ); + font_path = ( _T ( "/Settings/QTFonts" ) ); #endif
Thiis is already in master.

I don't know what is happening with the SetFocus thing. I sometimes see similar problems. I will investigate.

Thanks
Dave

[P_Dub]

( Waypoint range rings visible.
Thomas, do you suggest that rings should be added automatically to all waypoints (either dropped, or by route create) if selected in Options->Ships->Waypoints? And also to existing points as well, or only to new points? We never really talked about the global meaning of the Options->Ships->Waypoint->RangeRing selection...)

May I suggest that a range ring should be available if you desire so!
This would need to implement a part in one of the interface or a new one on demand.
Regards

[Hakan]

Dave, Sean...
If you're interested I have some reports from RPi2 tests. And please do not see this report as demands for RPi functionality, I've read your comments about this issue. But if this can support any further developments it's fine.

My RPi2 was once working on OCPN ver 4.0 although without OpenGL. Well, OpenGL was working but sooo slow. Now OCPN won't start up anymore and I'm not sure what I did before this changed. OCPN now starts with the background map and without toolbar and then the toolbar placeholder is shown white and the rest of the screen is black and OCPN breaks. The log says nothing special, the last couple of rows are:

18:10:28 CET: Background world map loaded from GSHHS datafiles found in: /usr/local/share/opencpn/gshhs/
18:10:28 CET: Warning: Color not found UINFR
18:10:28 CET: Warning: Color not found SCLBR
18:10:28 CET: Warning: Color not found CHDRD
18:10:31 CET: ChartSymbols loaded from /usr/local/share/opencpn/s57data/chartsymbols.xml
18:10:32 CET: Using s57data in /usr/local/share/opencpn/s57data
18:10:32 CET: Initializing Chart /home/pi/Charts/CM93_2012
18:10:32 CET: CM93Composite Chart Root is /home/pi/Charts/CM93_2012/
18:10:32 CET: Loaded CM93 Dictionary from /home/pi/Charts/CM93_2012/
18:10:33 CET: Loading CM93 cell /home/pi/Charts/CM93_2012/03900000/E/A4440034.E
18:10:34 CET: Loading CM93 cell /home/pi/Charts/CM93_2012/03900000/E/B4440034.E
18:10:35 CET: Loading CM93 cell /home/pi/Charts/CM93_2012/03900000/E/C4440034.E
18:10:35 CET: Loading CM93 cell /home/pi/Charts/CM93_2012/03900000/E/D4440034.E
18:10:35 CET: Loading CM93 cell /home/pi/Charts/CM93_2012/03900000/E/04440035.E
18:10:36 CET: OpenCPN Initialized in 9330 ms.

These are the command answers on RPi2 and today's Git pull. (Build and install is fine.)

pi@raspberrypi ~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  libssh2-1
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 125 kB of archives.
After this operation, 4 096 B of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 Index of /raspbian wheezy/main libssh2-1 armhf 1.4.2-1.1+deb7u1 [125 kB]
Fetched 125 kB in 0s (202 kB/s)
(Reading database ... 82368 files and directories currently installed.)
Preparing to replace libssh2-1:armhf 1.4.2-1.1 (using .../libssh2-1_1.4.2-1.1+deb7u1_armhf.deb) ...
Unpacking replacement libssh2-1:armhf ...
Setting up libssh2-1:armhf (1.4.2-1.1+deb7u1) ...

>>>>Git pull, make, make install>>>

pi@raspberrypi ~ $
pi@raspberrypi ~ $ /usr/local/bin/opencpn

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-can-change-accels after class was initialised

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-menu-popup-delay after class was initialised

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-menu-popdown-delay after class was initialised

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-button-images after class was initialised

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-scrolled-window-placement after class was initialised

(opencpn:2421): Gdk-CRITICAL **: IA__gdk_colormap_new: assertion 'GDK_IS_VISUAL (visual)' failed

(opencpn:2421): Gtk-CRITICAL **: IA__gtk_widget_set_colormap: assertion 'GDK_IS_COLORMAP (colormap)' failed

(opencpn:2421): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
libGL: built on Mar  5 2015 08:36:07
libEGL warning: DRI2: failed to authenticate

(opencpn:2421): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-label-select-on-focus after class was initialised
libGL: warning, gles is NULL
libGL: warning, gles is NULL
libGL: warning, gles is NULL
Segmentation fault
pi@raspberrypi ~ $

My next attempt is to reinstall my system, Debian, Raspbian; to see if can come back to a working 4.0.

Håkan

[cagney]

Originally Posted by bdbcat

...
1. Waypoint range rings in OpenGL mode now visible.
Thomas, do you suggest that rings should be added automatically to all waypoints (either dropped, or by route create) if selected in Options->Ships->Waypoints? And also to existing points as well, or only to new points? We never really talked about the global meaning of the Options->Ships->Waypoint->RangeRing selection...
...
5. Thomas cm93 corruption: Cannot reproduce. O 4.1 has only minor cosmetic changes from O4 in the cm93 code. Thomas, will you check your configuration (OpenGL?) again, as well as on O4? Anyone else see cm93 corruption at cell boundaries?

...

Thanks
Keep 'em coming....
Dave

Dave

Reg
#1. No. No such suggestion.
Options->Ships->Waypoint->RangeRings seems to only set defaults for the session, activated for each wpt. I'm not sure we even need this setting.
For me, I think it's enough with the ability to set rings for each wpt separate.

#5 Not repeatable today. In yesterdays session there was nu problem to repeat. Session initialization dependent? I'll keep an eye on this, and see how it goes..

Thanks
Thomas