remember script path

[axd1967]

editing is quite painful.

apparently I always have to indicate the full script path when SAVING or LOADING a script.

I want the application to remember the current script path, so that I can edit a script offline, reload and save often and easily.

[axd1967]

is there any way to work with scripts other than via primitive editors ? debugging is frustrating and horrible, error messages are not helping:

this scripting environment is a nightmare!

now, I edit the script in an editor, then copy-paste everything again and again in the script window.

(and this low contrast color scheme is making life even more difficult - #678 )

[gzotti]

You are more than welcome to develop a better solution.

[alex-w]

is there any way to work with scripts other than via primitive editors ?

The sentence looks like proposal a programming on C++ within Microsoft Word. Sorry, but why you need a rich text editor for scripting?

debugging is frustrating and horrible, error messages are not helping:

If you adding a rich text then described problem is possible (the error "cannot run script" causes in case, when preprocessor cannot parse the script) - without script I cannot give detailed answer.

this scripting environment is a nightmare!

If you can implement a good and lightweight environment (with code highlights and maybe suggestions of methods) for scripting - welcome!

now, I edit the script in an editor, then copy-paste everything again and again in the script window.

Sigh. Why you always select the hardest way for using some function? I guess you are newbie on linux and some obvious solutions are not obvious for you. Let me suggest a fastest way for writing and debugging scripts within Stellarium with some external editor as "script editor". Run a terminal (Konsole for example) and move the terminal window to the left bottom side of screen (the window will be staying in the background for looking log). Run through the terminal your favorite text editor with new script as parameter - for example kate ~/.stellarium/scripts/my-favorite-script.ssc & (this command will run kate as background process and open the file in the editor (or create a new file)). Switch text editor into windowed mode (a big hight and small width of window - 1/3 of window size for example on wide monitor) and move it in right side of screen. Write a line // Shortcut: Alt+G in your script and save it (or any other freely shortcut). Now run Stellarium in terminal to get the log of running in the terminal. Switch Stellarium into windowed mode, change the screen size (a big width and small height for example) and move it into top left side of screen. The process of writing the script will look as: writing something in text editor, Ctrl+S (saving), Alt+Tab (switch to Stellarium), Alt+G (run script, the log is under the Stellarium's window), Alt+Tab (switch to text editor), writing another part of code, Ctrl+S, Alt+Tab, Alt+G, Alt+Tab...

Of course you may set the size of windows for Stellarium and text editor in similar values and put both windows in top center side of screen (wide windows for both programs) and use Alt+Tab for fully switching between them (the text editor is under Stellarium -> the Stellarium is over text editor -> exchange "levels" again).

[axd1967]

yeah, I'm a newbie. sounds like you are insulting me. I've been dabbling in Linux for over thirty years. for example, I am a big fan of '&' ;-). and a fan of alt-tab. (but I use GVim).

but I don't get the "alt g" thing. if I understand correctly, alt-g is a shortcut that must be defined in Stellarium, to do what exactly?

If now Stellarium would monitor the script file, then I could edit it outside Stellarium and that problem was solved...

[alex-w]

yeah, I'm a newbie. sounds like you are insulting me. I've been dabbling in Linux for over thirty years. for example, I am a big fan of '&' ;-). and a fan of alt-tab. (but I use GVim).

Hmm... Why you do not use "standard UNIX-like pipeline" in this case? O_o

but I don't get the "alt g" thing. if I understand correctly, alt-g is a shortcut that must be defined in Stellarium, to do what exactly?

In the described use case the "Alt+G" will be assigned as a shortcut for run your script (SUG 16.5.1).

If now Stellarium would monitor the script file, then I could edit it outside Stellarium and that problem was solved...

When you run the script then file of script will be re-load for each "run call".

[gzotti]

It is just your smart-alecky tone that rather insults us. If you want to contribute, develop a substantially better solution and send a PR. We do not work for and have no obligations to you.

Note that the whole scripting module is in danger by Qt changes. So yes, a solution would be more than welcome. But a solution that has Qt6 in mind. This may or may not include a change of script language towards Python. So how much energy do you suggest we should invest into a dying module that is used by a tiny minority of advanced users?

"over thirty years": That predates Linux...

[axd1967]

It is just your smart-alecky tone that rather insults us. If you want to contribute, develop a substantially better solution and send a PR. We do not work for and have no obligations to you.

I know. I just wanted to air my frustration.

Note that the whole scripting module is in danger by Qt changes. So yes, a solution would be more than welcome. But a solution that has Qt6 in mind. This may or may not include a change of script language towards Python. So how much energy do you suggest we should invest into a dying module that is used by a tiny minority of advanced users?

Python sounds very interesting.

maybe try to find out how much of this scripting is indeed used? if it's a minority, ditch (make obsolete, stop support for, let it bleed to death, forget about it, add some bugs, ...) Javascript in favor of Python. (remember the Yaml discussion? it's the same kind of problem: old things must be thrown away from time to time. and meanwhile, observe how Yaml has invaded Stellarium in a subtle way...)

"over thirty years": That predates Linux...

For only a few years. But indeed, before that there was Unix (and K&R).

[axd1967]

In the described use case the "Alt+G" will be assigned as a shortcut for run your script (SUG 16.5.1).

AH! OK! now I get it. thank you.

[alex-w]

remember the Yaml discussion? it's the same kind of problem: old things must be thrown away from time to time. and meanwhile, observe how Yaml has invaded Stellarium in a subtle way...

Sorry, but where you see invading YAML in Stellarium? Why you maniacally proposes to us incorporate worst solution from existing for config data? Using YAML for config data is may be good solution for advanced users with mighty experience in UNIX world. Biggest part of our users are unadvanced (a "common" users) with limited experience in Windows. Permission for all those users a freely editing config data in plain text editor is a better way to killing Stellarium (a get unusable configuration settings). Possible solutions? No problem: a first one - switch to using binary format for configuration data and allowing change the settings through GUI only. A second one - adding a tool for analize for well-formed of structure the config data, solver for resolving non well-formed parts of config, the converter from old format from various old versions. And yes, we should being refactored all subsystem for settings in Stellarium in this case. For what this is all? For simplification an exchanging data in personal git for one, maybe 2-3, persons (!!!) in the world. Seriously?! If you really want to get an YAML format for config.ini then please create a branch, refactor the code (switch INI->YAML), add the code for analize the new config and code for solver of problems (checking spaces and tab chars, plus checking an encoding of file), add the code for conversion an old config.ini into new format, and, finally, propose the PR.

Currently only 2 man in the world, who develop Stellarium as hobby (or a part-time day in very specific cases) and we have many bugs, who need resolve and many new features from our TODO lists (a very long and very old lists). Personally I do not want to doing the stupid monkey work, what giving nothing for end users for simplification or something similar. The changind of the format of config data is in super lowest priority for both us.

[axd1967]

hello... I feel like we have a lot of misunderstandings due to language differences. if I'm not mistaken, Russian is your mother language rather than English, which could be a possible source of misunderstandings.

I love Stellarium and promote it around me, and I am fully aware this is a difficult project that is managed by very few people. please remember this.

I have the impression that these language issues amplify misunderstanding, so please bear that in mind. if I didn't appreciate your work, I would not try to help you with other issues that you must know about by now.

in this example, I don't "maniacally" ask to go to Yaml, which you think is the worst solution (on this point I'm afraid you are totally wrong). I just point the attention of everyone interested (including future contributors) to the fact that Yaml is starting to appear in Stellarium (see Travis and Appveyor), and elsewhere (#863) I explain why YAML might be good. your argument why to NOT allow people to edit config files is also good. but I never insisted to replace it everywhere, maybe you misinterpreted this. I just try to call for new plugins to prefer YAML to a .json or .ini format, and this is directed to anyone pondering over implementing such plugins.

and finally, this issue ended up on Python/QT6, which lead me to point out that change is inevitable to keep an application alive, and therefore a move to a different config file format should be kept in everyone's mind, even if now this is not realistic. we all know that changing a format just for fun is pointless. my proposal was indeed to facilitate sharing, for which JSON and INI formats are bad formats and YAML is much better.

[alex-w]

hello... I feel like we have a lot of misunderstandings due to language differences. if I'm not mistaken, Russian is your mother language rather than English, which could be a possible source of misunderstandings.

Yes, I'm from Russia.

in this example, I don't "maniacally" ask to go to Yaml, which you think is the worst solution (on this point I'm afraid you are totally wrong).

YAML may be broke by one wrong char!

I just point the attention of everyone interested (including future contributors) to the fact that Yaml is starting to appear in Stellarium (see Travis and Appveyor), and elsewhere (#863) I explain why YAML might be good.

Travis and AppVeyor are external infrastructure for GitHub and I may remove both *.yml files without any changes in Stellarium. Tomorrow Travis may switch parser to XAML and this will not touches Stellarium itself. Especially for issue #863 - Oculars plugin is good example, when INI should be edited through GUI only and what you ignored. The only possible way to solve the problem of wrong format of data is using hierarchical binary format (like Windows or Gnome registry) for config data to full control the data and special tool for read/write of those data. No, it will not allow you the partial sharing the data of Oculars plugin.

my proposal was indeed to facilitate sharing, for which JSON and INI formats are bad formats and YAML is much better.

Please explain why INI and JSON are bad formats for you.

[axd1967]

YAML may be broke by one wrong char!

that is a weak argument.

1. Qt6/Python will have the same problem.
2. every format has syntax issues. you can forget a closing bracket in XML or JSON, misspelled field names in .ini, etc.

When I discovered Yaml, I thought "oh no, yet another format". today I consider Yaml as one of the best human readable formats.

... Especially for issue #863 - Oculars plugin is good example, when INI should be edited through GUI only and what you ignored.

Any file that falls under the hands of a user can potentially be edited by hand - exactly the fear you have and want to prevent by switching to binary formats.

Another approach is to embrace this behaviour, because it will happen. This approach is slightly more demanding on the code side but far more user friendly.

Please explain why INI and JSON are bad formats for you.

"Bad" is too extreme. See #863 (comment) - please consider continuing that discussion there and not here.

[alex-w]

that is a weak argument.

Really? But your "I like it" is a weak argument too!..

Another approach is to embrace this behaviour, because it will happen. This approach is slightly more demanding on the code side but far more user friendly.

The INI is super simple and super stupid format - key = value. Where is you see here difficulties for understanding and readability? Where is not user friendly here? I know only one use case, where INI is not user friendly - arrays.

"Bad" is too extreme. See #863 (comment) - please consider continuing that discussion there and not here.

OK, I will ask you in other words. How exactly GUI for scripting is related to YAML config? How exactly spreadsheet to compute the coordinates for JSON data is related to YAML config for Oculars?

[axd1967]

So... I try the Alt+G thing (and ALt+g, etc), but that doesn't trigger the script. Note that the script works fine.

What am I doing wrong?