Sean's Optimum Branch Merge

[bdbcat]

Serge...

Nope. Consider this thread and series to be a sort of Alpha+ test of the merged optimum branch. We are looking for build problems and big-picture regression issues. A smoke test, really.

A Beta incorporating all will be out pretty soon.

Dave

[LeaseOnLife]

I. Pilliolpippiopploliolppiili 89l 9. 8htt"8""://www.zeit.de/2014/17/stimmts-nachts-pinkeln-" " 89""8"io8@**98"8""9@""lil oioiiiiili

[bdbcat]

???

Dave

[LeaseOnLife]

Originally Posted by bdbcat

???

Dave

Amazing what an iphone in a butt pocket can do... sorry, disregard!

Dirk

[Ptizef]

hi
3.3.1710 compiled OK
Tests running, no remark for the moment.
Except problem pending with dialog fonts, but it's not new in this version
Jean Pierre

[Ptizef]

Precisions about dialog font problem :
1) in default US language
when changing the dialog font, no update immediately ( more exactly, some dialogs have their font updated, others not) Exiting O and reopening allow to get the new font for all dialogs ( except settings dialog )
2) in local language
impossible to change dialog font. The "dialog" parameter is now in the list but changes are not taken. Only possible by typing directly in the config file
3) in any case the setting dialog font (all tabs) can,t be changed
Jean Pierre

[Hakan]

Originally Posted by boat_alexandra

Yes, there is, but the problem is I do not know the magic number to use. See chcanv.cpp line 1899. If you can set a breakpoint there, then press what key, then look at the value of key_char then you could provide the keycodes needed.

Yes, that's clear but the function GetKeyCode() checks every key stroke and will first see the Alt key and then the < sign. (If you try to check the char code for for your € or £ sign I think it's the same) Then you have to build a OCPN rule for that function like the wxMOD_CONTROL we use for small zoom steps. But when OCPN use the ctrl key it's a OCPN function similar for all keyboards. If you should find the | sign from all different keyboard you must check Win/OsX/Unix API for the actual keyboard and make all possible variants for that. Not very practical. But this must have been done before. How can for example Notepad++ find the correct sign?
I don't know if it's possible to understand my writing but I've tried.
Håkan

[seandepagnier]

Originally Posted by Hakan

Yes, that's clear but the function GetKeyCode() checks every key stroke and will first see the Alt key and then the < sign. (If you try to check the char code for for your € or £ sign I think it's the same) Then you have to build a OCPN rule for that function like the wxMOD_CONTROL we use for small zoom steps. But when OCPN use the ctrl key it's a OCPN function similar for all keyboards. If you should find the | sign from all different keyboard you must check Win/OsX/Unix API for the actual keyboard and make all possible variants for that. Not very practical. But this must have been done before. How can for example Notepad++ find the correct sign?
I don't know if it's possible to understand my writing but I've tried.
Håkan

I think we can use the same letters like 'a' 'b' etc.. or even '[' by going outside the qwerty test, but my concern is that these keys are not the best ones to use on your keyboard because you have to use a modifier to reach them.

[Icnoships]

Hi Dave..
Compiled fine on OSX.7.5, wx2.95

Assert that was happening on launch has gone..good stuff
All appears normal & excellent when pushing all the buttons...
thats with an without Opengl enabled.

One issue however has become more aggressive the alpha assert that happens on launching Grib can no longer be Escaped an so O is locked at that point.... force quit the only option.

There is nothing in O's log,
the system log reveals....


12/05/14 10:09:07.884 AM OpenCPN: This application is trying to draw a very large combo box, 30 points tall. Vertically resizable combo boxes are not supported, but it happens that 10.4 and previous drew something that looked kind of sort of okay. The art in 10.5 does not break up in a way that supports that drawing. To avoid breaking existing apps, NSComboBox in 10.5 will use the 10.4 art for large combo boxes, but it won't exactly match the rest of the system. This application should be revised to stop using large combo boxes. This warning will appear once per app launch.

12/05/14 10:09:09.515 AM [0x0-0xd70d7].org.opencpn: ../src/common/image.cpp(1901): assert "!HasAlpha()" failed in InitAlpha(): image already has an alpha channel

The assert is still the same as the previous screen shot i posted

Hope all that is of some use

Mo

[Icnoships]

Dave further testing...
with opengl turned off, produces a different assert this can be dismissed..
resulting in an instant crash

Here's a copy of backtrace/crashreport....

[bdbcat]

Icnoships...

I must have missed this crash report posting:

12/05/14 10:09:09.515 AM [0x0-0xd70d7].org.opencpn:  ../src/common/image.cpp(1901): assert "!HasAlpha()" failed in  InitAlpha(): image already has an alpha channel

The assert is still the same as the previous screen shot i posted

Link, please?
I need the stack trace...

Thanks
Dave

[bdbcat]

Ptizef...

Corrected dialog font setting trouble in github now.

Root cause of trouble was that "Dialog" is spelled the same in English and German...Go figure...

Please test,if possible.

Thanks
Dave

[Icnoships]

Dave
here's the same screen shot i posted previously of the assert, this is with opengl enabled & can only be got round with a force quit....

re the stack trace, it appears there is a complete lockup when the assert triggers as the system log says....

12/05/14 12:43:09.830 PM [0x0-0xea0ea].org.opencpn: Collecting stack trace information, please wait...

then nothing happens, waited 5 minutes but no trace and had to force quit

thanks Mo

[CarCode]

None of the issues above happens here with OS X 10.9.2, wxWidgets 3.1.0 and Xcode 5.1.1. But InitAlpha() has been commented out:

#ifndef __WXOSX__
    gr_image.InitAlpha();
#endif

Gerhard

[CarCode]

BTW
Since todays diffs wxWidgets 3.1.0 supports now also full screen mode for OS X:

/**
        Adds or removes a full screen button to the right upper corner of a
        window's title bar under OS X 10.7 and later.

        Currently only available for wxOSX/Cocoa.

        @param enable
            If @true (default) adds the full screen button in the title bar;
            if @false the button is removed.

        @return @true if the button was added or removed, @false if running
        under a pre-OS X 10.7 system or another OS.

        @note Having the button is also required to let ShowFullScreen()
        make use of the full screen API available since OS X 10.7: a full
        screen window gets its own space and entering and exiting the mode
        is animated.
        If the button is not present the old way of switching to full screen
        is used.

        @onlyfor{wxosx}

        @see ShowFullScreen()

        @since 3.1.0
    */
    virtual bool EnableFullScreenView(bool enable = true);

    /**

Gerhard