Ocpn-Draw and Boundary

[NAV]

Originally Posted by Hakan

The Swedish use is the same e.g. decimal comma instead of point.
This is not an obstacle in the OCPN world only. So I've ended up in changing my Windows international settings to use decimal point although my system language is Swedish.
Håkan

Yes , I know. But the 'problem' is this:
I cannot enter a decimal point at all in this field (this field can show decimal figures). I can enter a decimal comma, but after entering this I cannot enter a decimal figure.

So it seems that entering decimal figures is impossible (although these are shown when the length figure is calculated automatically).

[Gilletarom]

Originally Posted by NAV

Yes , I know. But the 'problem' is this:
I cannot enter a decimal point at all in this field (this field can show decimal figures). I can enter a decimal comma, but after entering this I cannot enter a decimal figure.

So it seems that entering decimal figures is impossible (although these are shown when the length figure is calculated automatically).

I confirm and if i try to replace all, in any case, after the ",", I canot continue and if I validate by "ok", I have really "0" as value.

[rgleason]

I put a change in that freezes the length field if you put your cursor in it, and/or the angle field if you put your cursor in that. This allows you to change the field to what you want without the autoupdate undoing your change. The 'freeze' is removed when you close the dialog box, but not before.

-Very Clever

I am hoping to freeze OD now so that we can deliver it into production. I really don't want to make any more functionality updates only fixes. If there is extra functionality wanted/required I would like to see flysprays raised.

--Ok flysray pi - ODraw is ready.
OpenCPN::OpenCPNPi - ODraw: Tasklist
but the items need updating because ODraw has moved along so much. Maybe others should check to see if their items are outdated and close them? I will certainly check now.

I know someone wants the arrows on the EBL reversed so that it can be used for wind direction. I would need to think about it, but my gut feeling is it should be another tool, but this time either on or off and driven by input from OCPN via extended Position Fix information, but this will require changes to the API, so now would not hit production until the next release.

Ok, The wind tool sounds like it might be good. There are several Nmea data tools that might be very useful in the future.

[NAV]

Dutch language file updated to Draw patch 641 (who will prepare CrowdIn for the latest pot-file?):

[Gilletarom]

Hello Jongough, hello RGleason,

OD before putting into production, it is necessary that we make a final series of test with the latest patch. If a version of "nearly final" could be in the thingie, it would be nice.

[Hakan]

Originally Posted by NAV

Yes , I know. But the 'problem' is this:
I cannot enter a decimal point at all in this field (this field can show decimal figures). I can enter a decimal comma, but after entering this I cannot enter a decimal figure.

So it seems that entering decimal figures is impossible (although these are shown when the length figure is calculated automatically).

So, If I change to decimal comma in my Windows international properties I get the same behavior as you and that's not usable. When I change back to decimal point (and restart OCPN) I can enter a point but not a comma in the OD - fields.

And I do agree this is a difference between OCPN core and Draw_pi. In for example "tools-ship-own ship-GPS distance..." I can use a comma when my international proprieties are change to decimal comma, but not in OD.
This would be corrected since we can't expect every "normal" user to change their system properties to be able to run OD (or other plugins?), should we?
Håkan

[Gilletarom]

Hello Jongough,

Here last french file language.

Note that I took two decision that changes a little the spirit of OD Draw.
First : I change "Borne" by "Borne/Disque"
Therefore, one can believe that there are two tools in one. but this is not true because for boudary line, you can view the properties while here for discs, you can not.

Second : I change Exclusive by "Extérieur" and "Inclusive" by "Intérieur"
This leaves the uses in other plugins more flexibility as to the use made of this property.
And I'm going to look at what it brings as consequences in the WatchDog plugin.

But I fear that, therefore, the same translation appear in the WatchDog if the same words are used in the queue pot OD Draw and WatchDog.

It seems to me that NAV had asked that the words "Excusive and Inclusive" are not written in the same way in both language files. I confirm to need the same flexibility.

Idea:

You can change "Inclusive" to "Inside" and "Exclusive" by "outside" in the OD Draw plugin.

This does not normally request a code change, at least I suppose. And so it will not change the operation.

Am I alone in thinking that this idea is reasonable?

[Hakan]

More Decimal comma/point:
If Win system properties is decimal comma:
In Watchdog for example you can use a comma but it has no effect. 3,5 gives 3.0 when saved.
Håkan

[Gilletarom]

Hmmm ... I launched the WatchDog. Indeed, what is modified in the language file of plugin OD is also modified in the language file WD plugin.

This is not what I want.

I imagine that in OD, "Interior" is to say where the grid is while in WD, "Inside" or "Outside" is to say where it is forbidden. And the user is free to choose indoors prohibited or outside as prohibited.
This gives much more flexibility.

Hmmm ... I launched the WatchDog. Indeed, what is modified in the language file of plugin OD is also modified in the language file WD plugin.

This is not what I want.

I imagine that in OD, "Inside" or "Outside" is to say where the grids while in WD, "Inside" or "Outside" is to say where it is forbidden. And the user is free to choose indoors prohibited or outside as prohibited.
This gives much more flexibility.

In WD, I'd replace "Inclusive" and "Exclusive" to "Allow" and "Deny".

But maybe this is technically impossible and / or there may be this would cause too much code changes in WD.

Am I alone in this kind of idea?

[Gilletarom]

Hmmm ... I launched the WatchDog. Indeed, what is modified in the language file of plugin OD modified also WD screen.

This is not what I want.

I imagine that in OD, "Interior" is to say where the grid is while in WD, "Inside" or "Outside" is to say where it is forbidden. And the user is free to choose indoors prohibited or outside as prohibited.
This gives much more flexibility.

Hmmm ... I launched the WatchDog. Indeed, what is modified in the language file of plugin OD change also the use in WD (So when installing O, or when opening O, OD file is read after the WD file)

This is not what I want.

I imagine that in OD, "Inside" or "Outside" is to say where the grids while in WD, "Inside" or "Outside" is to say where it is forbidden. And the user is free to choose indoors prohibited or outside as prohibited.
This gives much more flexibility.

In WD, I'd replace "Inclusive" and "Exclusive" to "Allow" and "Deny".

But maybe this is technically impossible and / or there may be this would cause too much code changes in WD.

am I alone with this kind of idea ?

[rgleason]

Gilletarom,
I think you are showing great mastery of English and are forcing us to eliminate ambiquities, which is good!

In WD, I'd replace "Inclusive" and "Exclusive" to "Allow" and "Deny".

The only problem I have with this change is that I am not sure that it accomplishes what you would like and represents completely what the action does.

A change similar to this would however make it clear to the user that there is a clear distinction between the ODraw "inclusive" and "exclusive" graphical only designations, and the designations in WatchDog. Are there some suitable labels for WatchDog that are different words which more adequately describe the action?

[rgleason]

One choice I had in mind a long time ago, was
"Keep [boat] inside" and "Keep [boat] outside"

Another choice under WatchDog might be "Contain" and "Reject".
I am sure there are some other alternatives.

I originally thought that the graphical selection of "inclusive" and "exclusive" would be communicated to WatchDog so that the graphical choice of "inclusive" or "exclusive" would determine the type of alarm in WatchDog.
Thus an "Inclusive" Boundary would automatically be a "Keep [boat] inside" alarm or a "Contain [boat within the boundary]" alarm.
Or an "Exclusive" Boundary would automatically be a "Keep [boat] outside" alarm or a "Reject [boat from the boundary]" alarm.

The OD and WD system currently allows more flexibility than this right now, because I do not believe the "inclusive" and "exclusive" conditions in OD are sent to WD. This is Jon's purposeful choice, and I am sure he has some good reasons for doing it this way, but I don't really understand the details.

The plugins are working and everything is documented now, so we probably should not make dramatic changes as Jon would like to put this version to bed.

[NAV]

Originally Posted by Gilletarom

Hmmm ... I launched the WatchDog. Indeed, what is modified in the language file of plugin OD modified also WD screen.
...... am I alone with this kind of idea ?

That's why I used 'free' and not literal translations for a number of strings in Draw and, although less, in Watchdog. By doing this I seem to have fully solved the problem you described.


Another thing to remember is that the sequence in which Draw and Watchdog are started (by deactivating and activating these plugins) makes a difference for the end result (i.e. which translations you see on screen).

[NAV]

Originally Posted by rgleason

One choice I had in mind a long time ago, was
"Keep [boat] inside" and "Keep [boat] outside"

Another choice under WatchDog might be "Contain" and "Reject".
I am sure there are some other alternatives.

In Dutch (here translated to English) I used 'to be avoided' and 'restricting'. Possible because I hardly used the Dutch word for 'Boundary', but instead I used 'Line (or straight lined area)'. For Boundary Point: 'Point (or circle area)'.

[Gilletarom]

Originally Posted by rgleason

Gilletarom,
I think you are showing great mastery of English and are forcing us to eliminate ambiquities....

If this could be true! But that said, thank you.