Celestia Forums

Chuft-Captain, Hiya

Thanks for the advice, yet I have tried accordingly with no luck. I am sure I was at the right site but in the wrong time. Anyway, hope your CC has gone

Joe,

I found a copy of the addon on a backup disk. I think this is identical to version 8, but I'm not absolutely sure.
If SITESLED ever returns, I suggest you retry the original download link (and see if there are any differences compared with this version).

In the meantime you can at least use this as a temporary replacement:

(If you ever do manage to download the original from the SITESLED link, please let me know if you spot any differences.)

Cheers
CC

PS. I plan to re-release the Lagrange Points with the LP-VIEW tool (and this won't be hosted at SITESLED ).

This script is a very good idea. It allows to view easily a complicated concept.

Unfortunately, I do not have the script and it is difficult to say whether or not it may pose problems.

Choosing the keys to use is always a problem because they are also used by Celestia. And for other reasons too...
I think if we have to use the keyboard it is best to give default keys and let the user choose with a configuration file.

I guess it is not a script for lua_plugins or lua_edu tool. (In effect on your screenshot I don't see the button for this addon).
It's unfortunate for three reasons in order of increasing importance

The first and least is that we could have a much prettier and less intrusive control pane than this text menu.
Only my personnal taste though...

Secondly, the problem of key names would not arise since we have just to click on it.
The choice of the correct key depends in fact on the next point. Using the mouse instead of the keyboard should avoid this complicated problem.

The third and most important is that lua_edu_tools can easily localize a program for any language. (With lua_plugins it is not impossible but it is a bit more tricky ).
In fact it is almost essential for a program with a great educational interest like this to be translated into the language of those to whom it is addressed.

If you decide to consider my remarks I am at your disposal for the French translation.

I have also a remark (and a suggestion) about your menu which seems a bit complicated to me.
For example you have markers with labels and you add markers. The consequence is to delete the labels. And no markers are added since they were already here. That is a bit confusing.

We have to notice that if we have a label, we have also a marker. In the same way if we have not a marker we cannot have a label.
This allow to use only 2 keys (or 2 buttons) instead of 4 (V, +, -, and u):

- a button for the markers: if we have no markers, they are created. If there are markers they are deleted (with the label if required)

- a button for the labels: if we have no labels they are created (with the associated markers). If we have labels they are deleted (and the associated markers remain)

- the subordinate button is a switch. If it is OFF, the previous actions are applied only to the selected body otherwise they are also applied to the associated bodies.

What do you think about all this?

Cheers

In the meantime you can at least use this as a temporary replacement:

Many thanks, Chuft-Captain, it is a great addon. Wonderful work

jogad wrote:I guess it is not a script for lua_plugins or lua_edu tool. (In effect on your screenshot I don't see the button for this addon).

In fact, it is an ADDON activated by the "Set Addon Visibility" menu in the LUA tools.

jogad wrote:It's unfortunate for three reasons in order of increasing importance

The first and least is that we could have a much prettier and less intrusive control pane than this text menu.
Only my personnal taste though...

Secondly, the problem of key names would not arise since we have just to click on it.
The choice of the correct key depends in fact on the next point. Using the mouse instead of the keyboard should avoid this complicated problem.

The third and most important is that lua_edu_tools can easily localize a program for any language. (With lua_plugins it is not impossible but it is a bit more tricky ).
In fact it is almost essential for a program with a great educational interest like this to be translated into the language of those to whom it is addressed.

If you decide to consider my remarks I am at your disposal for the French translation.

I agree with most of your points here, and a graphical version is and was always a possibility, however I preferred to start with this approach and perhaps then a graphical approach for version 2.

jogad wrote:I have also a remark (and a suggestion) about your menu which seems a bit complicated to me.
For example you have markers with labels and you add markers. The consequence is to delete the labels. And no markers are added since they were already here. That is a bit confusing.

We have to notice that if we have a label, we have also a marker. In the same way if we have not a marker we cannot have a label.
This allow to use only 2 keys (or 2 buttons) instead of 4 (V, +, -, and u):

- a button for the markers: if we have no markers, they are created. If there are markers they are deleted (with the label if required)

- a button for the labels: if we have no labels they are created (with the associated markers). If we have labels they are deleted (and the associated markers remain)

- the subordinate button is a switch. If it is OFF, the previous actions are applied only to the selected body otherwise they are also applied to the associated bodies.

What do you think about all this?

Cheers

I must say that I find the current version quite intuitive and easy to use (aside from the key assignment issues). I'm also not sure that your suggestion necessarily reduces the maximum number of keys required, but changes their nature. (see below, where I describe a similar approach requiring 3 keys only)
I assume that you have viewed the OpenOffice presentation I created (download on page1 of this thread), which gives some idea of the workflow.

The aim AFAIC, is to minimise the number of keys overall, and especially to minimize the number of keys that operate as switches, as this creates a "program state" which must be reported to the user, thus complicating the display (currently the V key is the only key operating in this modal fashion).
You suggest making the subordinate button a switch, which again creates a dual-modality which would have to be reported to the user.
The ideal is for all keys to "perform actions" rather than "change state".

I will continue to consider your comments, however the likely path I see this taking is:

1. The (-) key is no longer required ... the (+) key will perform the function of both keys (either adding or removing labels/markers depending on whether thay are currently displayed or not.
2. The (V) key may also become superfluous if the (+) key is made to have a progressive action, adding / removing labels AND markers, depending on current state.
3. The (U) key may also be deprecated, if we simply "Clear all" on exit of the script. Less convenient, but does away with another key assignment.

So, if all 3 options are implemented, we are left with only 3 keys:

(+) - cycles between: nothing / markers only / markers+labels
(S) - possibly a switch as you suggest (with the (+) key doing the work), but more likely an action key, replicating the functionality of the (+) key, but acting on all sub-ordinates rather than a single object.
(?) - help key

I need however to also consider whether this reduction in keys actually makes the tool more or less intuitive, or easy to use. This simplification of the user interface may in fact obsfucate it's function. (Less is not always more).

Hope this makes sense.
Cheers
CC

Chuft-Captain wrote:In fact, it is an ADDON activated by the "Set Addon Visibility" menu in the LUA tools.

In this case there is a celx script launched by the lua tools. Such a script won't have the features offered by lua tools such as graphical display and especially translation capabilities.

Chuft-Captain wrote:The aim AFAIC, is to minimise the number of keys overall, and especially to minimize the number of keys that operate as switches, as this creates a "program state" which must be reported to the user, thus complicating the display (currently the V key is the only key operating in this modal fashion).
You suggest making the subordinate button a switch, which again creates a dual-modality which would have to be reported to the user.
The ideal is for all keys to "perform actions" rather than "change state".

I entirely agree with you. But "perform actions" or "change state" is a matter of point of vue.
As a programmer I see the (S) key as a switch. But As a user I consider it is and action (select one orbit or select all orbits). If you choose this option it could be explained in the help screen as a (S)eclect key.

Chuft-Captain wrote:I will continue to consider your comments, however the likely path I see this taking is:

1. The (-) key is no longer required ... the (+) key will perform the function of both keys (either adding or removing labels/markers depending on whether thay are currently displayed or not.
2. The (V) key may also become superfluous if the (+) key is made to have a progressive action, adding / removing labels AND markers, depending on current state.
3. The (U) key may also be deprecated, if we simply "Clear all" on exit of the script. Less convenient, but does away with another key assignment.

So, if all 3 options are implemented, we are left with only 3 keys:
(+) - cycles between: nothing / markers only / markers+labels
(S) - possibly a switch as you suggest (with the (+) key doing the work), but more likely an action key, replicating the functionality of the (+) key, but acting on all sub-ordinates rather than a single object.
(?) - help key

I am totally happy with this 3 keys approach . Whether you decide to use the (S) key as a select key or as an extension of the (+) key, it is fine for me.

Chuft-Captain wrote:I need however to also consider whether this reduction in keys actually makes the tool more or less intuitive, or easy to use. This simplification of the user interface may in fact obsfucate it's function. (Less is not always more).

Nothing is completely intuitive for everyone . Whatever you decide, you have to explain it in the help screen. Explaining 3 keys is easier and more effective than explaining the 6 keys of the original design. It also demonstrates how important is to have the possibility to translate this vital help screen.

Another idea : a short introduction to (or a definition of) the Lagrange points along with the help screen?

Ok! I stop here! Anyway it is a great addon with or without any improvement. I you pay too much attention to my ideas it will never end and we'll never see the addon completed!

jogad wrote:I you pay too much attention to my ideas it will never end and we'll never see the addon completed!

Yes, I agree. This script started as a loose collection of individual scripts which were solely for my own use a few years ago, then we had a couple of years of earthquakes, which sort of put Celestia work as a very low priority.
Then a little while ago, our quakes have finally mostly subsided, and I took the opportunity to integrate the individual scripts into something more suitable for public release, but then recently I've had a bad flu for a few weeks which again has halted further coding of this.

Thanks for your feedback. It will give me food for thought when I finally get back onto this.

CC

Here is a proposed LuaEduTools style version as requested.

The idea is to click on LABEL,MARK,or NONE to apply that style of labels.
RESET button clears ALL labels/marks which may have been applied in the session.
The MODE button determines whether the Lagrange Points of the "Selected" object, or of it's "Sub-Objects" are labeled (default: "Selected").


French & Italian translations (via BING):




I suspect I'll need help with the translations.
Any volunteers for: German, French, Italian, Korean, Dutch, Russian, and Swedish translation tasks?
(About 5 minutes work per translation for someone fluent in English and the selected other language.)

CC

Great work, CC.

BTW, "modalita" should be "modalit?" with the accent on the last "a" but it is also the italian translation for "modality" and not for "mode" only. Thus:

Mode = Modo
Mark = Indica

the remains are good.

Thanks Massimo,

That's Italian sorted.

For the remaining translations, I'll put the Italian code as an example below.

Volunteers, please copy this and then re-post it with the quoted parts on the RHS edited to the best translation of the English on the left, for your chosen language:

Any volunteers for: German, French, Italian, Korean, Dutch, Russian, and Swedish translation tasks?

For Dutch, You're welcome....

Hi,

My contribution

And here are the votes of the Dutch Jury
10 points

Thanks Marco, Jogad, and Massimo.

That just leaves German, Korean, Russian, and Swedish.

Decided to pluralize a couple of the button texts as they read a little better that way (at least in English, and I'm told in French).
The affected buttons are LABEL -> LABELS, and MARK -> MARKS.

In French, it's just a matter of adding "s" (as in English).
I've assumed the same applies to Italian, and Dutch (just add "s"), but I know that this may not necessarily be the case in all languages.
Please advise if this is wrong.

For future volunteers in the remaining 4 languages, please use the following template for your translations:

Jogad, I've decided to go with "None" ("Aucunes"), rather than the alternative "Nothing" ("Rien"), simply because to me "None" reads a little better than "Nothing" in this context.
The opposite may be the case in French, but I have to assume that English will be the most used language and give that priority.
You will of course be free to customize your own copy if you think that "Rien" is a better interpretation than "Aucunes" in the French version, or alternatively, I could always translate the English "None" into "Rien", which although it is not a literal translation may be the best interpretation of the actual purpose of the button in French. -- What do you recommend?

Cheers
CC

PS. As this tool is nearing completion, if there are no volunteers soon to provide translations for German, Korean, Russian, and Swedish, then I may end up using an online translator such as BING, which will not give the best results.

Ok, with a question from my part.

Marks = Indica; the same because it is the third/neutral person of the present tense of the verb "indicare" (to mark) thus it is undifferent whether plural or singular, being an "action".
Labels = Etichette

The question: is "none" relevant to "marks"? that is: it mean "unmark"?

EDIT LATER:
in order to avoid some confusion, note that the italian translation for "marks" as relevant to "markers" (that is, the non-verb) is "marche/i"; but in this contest is ugly, because usually it concern things like either "poststamps" and such bills or "company logos". Yet another issue there is when "marks" is synonim of "symbols"

Fenerit wrote:Ok, with a question from my part.

Marks = Indica; the same because it is the third/neutral person of the present tense of the verb "indicare" (to mark) thus it is undifferent whether plural or singular, being an "action".
Labels = Etichette

The question: is "none" relevant to "marks"? that is: it mean "unmark"?

Thanks Massimo,
I think the answer to the question is: YES.
It is relevant, but in my mind the text describes a "state" rather than an "action", which is why I chose "None" rather than "Un-mark".
In English, "Label" and "Mark" can be noun or verb (meaning "to label" or "to mark"), depending on either the context or the readers interpretation
In the case of this tool, it's ambiguous, and is in the mind of the beholder, hence your question, and my emphasis on "in my mind".
Because of this ambiguity, in the English version, my choice of "None" versus "Un-mark", was partly designed to remove the ambiguity inherent in the other 2 buttons so that they would be interpreted as DESCRIPTORS, rather than VERBS in the mind of the user. (This is also a good reason to use the plural forms "Labels" and "Marks", as they are clearly NOT verbs. )

Perhaps a picture (or 3) will also be helpful:

Well, maybe then I think it's more easy so:

Marks = Indica
None = Rimuovi (remove)

therefore the operation's "meaning" should be like:

Marks = Mostra (show)
None = Nascondi (hide)

Chuft; do put:

Marks = Indica
None = Nascondi

and stop.

Chuft-Captain wrote:Jogad, I've decided to go with "None" ("Aucunes"), rather than the alternative "Nothing" ("Rien"), simply because to me "None" reads a little better than "Nothing" in this context.
The opposite may be the case in French, but I have to assume that English will be the most used language and give that priority.
You will of course be free to customize your own copy if you think that "Rien" is a better interpretation than "Aucunes" in the French version, or alternatively, I could always translate the English "None" into "Rien", which although it is not a literal translation may be the best interpretation of the actual purpose of the button in French. -- What do you recommend?

Although this is not the most important point of your program , I think that "rien" is better than "aucunes" for several reasons

Even if "aucunes" exists its usage is not very common. The most usual is aucun/aucune (singular form). Since "?tiquettes" and "Marques" are plural forms, if may sound as a mistake.

"Aucun(e)" answers the question "combien ?" (how many) while "rien" answers the question "qu'est-ce que ?" or "quoi ?" (what?)
It is more logical (in French) that the buttons for labels, marks and none/nothing answer the same question.
Qu'est-ce que tu montres ? - des ?tiquettes (what do you show? - labels)
Qu'est-ce que tu montres ? - des marques
Qu'est-ce que tu montres ? - rien (aucun/e/s is not possible here)
If you answer "aucune" the question would be:
Combien en montres-tu ? (how many do you show?)

My recommandation is to keep "none" in English since it is better for you and to translate by "rien" in French since it is better for me. Anyway, depending on the context, the same word cannot always be translated in the same way.
@+