Hi,
I have just been using commit 5af5a23 from OCPN to test the OD plugin. There appears to be an issue with the setting of the SVG icons for plugins when the plugin changes its icons in the toolbar. At 0ed0915b it all works ....
Jon

Using the last version of O4111317 that was placed in OD thread, I see the same problem with the Grib ICON in icons bar O.

(#122)
I have an additional question: 'The most recent (by date)'. Does that mean, the file with the most recent file-date (if so creation or modification?). Or do you use the tags in the bsb file or in the header, again in this case which one (CED/SE, CED/RE, CED/ED or else?). What if it is an older edition with a newer release and date?

The reason behind this question: do we need to preserve the file dates while copying and downloading?

Alexej

It means the file system file date not a date field somewhere inside the file. For this I think it doesn't matter whether creation or modification as they are usually the same. The chartdownloader sets the date on the file when it is expanded from the compressed archive. So the file date means the date when it was downloaded by the plugin.

It would be best to not have duplicate file names within a single type of chart file set. The usage of file dates presupposes that two duplicate name files are in fact the same chart just different versions. It is not robust to rely on file dates for differentiating files that contain completely different charts but have the same name.

It means the file system file date not a date field somewhere inside the file. For this I think it doesn't matter whether creation or modification as they are usually the same. The chartdownloader sets the date on the file when it is expanded from the compressed archive. So the file date means the date when it was downloaded by the plugin.

It would be best to not have duplicate file names within a single type of chart file set. The usage of file dates presupposes that two duplicate name files are in fact the same chart just different versions. It is not robust to rely on file dates for differentiating files that contain completely different charts but have the same name.

Also...OpenCPN does not read any .bsb files, only the .kap files.
/Thomas

As seen too often in the past: Each new commit results in a step backwards of functionality. Since introducing SVG type icons many people claim about it and the value display in the wmm_pi icon has gone. So I discarded SVG completely to get back the value display as shown in the attachment.

Gilletarom,
I have found what is causing the issue, OCPN does not look for or handle the 'Shift' key so both Ctrl + b & Ctrl + B are used for the same function, i.e. toggle chart bar. OD is using Ctrl + Shift + B to start drawing a boundary. I can easily change OD to use whatever keys are needed, but without the Shift key or Meta key being trapped there are not many options left for plugins. I will need Dave to say how he wants OCPN to react and what keys should be available for plugins.

A small problem with keyboard shortcuts.
"Ctrl + b" hides the charts bar but does not reappear. by cons, after hiding the charts bar, the second use of "Ctrl + b" opens the OCPN Draw icons bar.

And then, impossible to display bar charts.

A second problem , probably specific this graphic card :
"Ctrl + g" or "Crtl + G" do not change from daylight to green and, see screen copy, a second window, black, appear but it is impossible to display this second window.
The only way is to shutdown O and re-run O to return normal situation.

I have no trouble with SVG on Mac, building from current (today) github.

Dave

Dave,

I see a problem when the svg files are not on the proper location.
Then the test in wmm_pi.cpp line 358 still seems to see that there is a svg file while it is not.
The return of function GetBitmapFromSVGFile seems to set live.IsOk always to true.
If the svg file is not present I see the strange effect on the icon and if the svg file is there everything is honkydory.

We should of course be more explicit in the core regarding the exact shift states we expect. But we don't at this point. We also should probably have some registry methods for this. What happens if two PlugIns want CTRL-SHIF-B? More design work...

It's a bit late in the game to alter the hotkey logic for O4.2. You recall the aggravation earlier of establishing the hotkey list, and validating across all keyboards, worldwide? Was not a trivial exercise.

As a quick, relatively safe workaround, I can cherry-pick a few keys for you, if you give me a list. For example, CTRL-SHIFT-B could be made available to all PlugIns by explicitly ignoring it in the core.

Question:
What tool did you use to prepare the video after the screen capture? It seems to be ideal for making tutorial videos for specific OpenPCN functions and features. It looks like it supports drawing, overlay text boxes with effects, etc. I would like to use this tool, I think.