| Summary: | Target fields not updated | ||
|---|---|---|---|
| Product: | [Applications] kstars | Reporter: | Jean-Claude <jcjesior> |
| Component: | general | Assignee: | Jasem Mutlaq <mutlaqja> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | minor | CC: | blues_hawk |
| Priority: | NOR | ||
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jean-Claude
2019-03-02 13:36:11 UTC
Another point : we can select a target with a double-click on it. This should fill the 3 target fields mentioned above. Thank you again for this lovely software !!! I concur that this would be a nice feature and was on my report list as well. It does fill the box the first time but after that you have to change it yourself. Also related, fields in the capture module revert when reselecting them even to delete to make a new capture run. Always assigning the name target to the currently tracking target should fix things. It would also have a nice effect of naming targets properly when using the scheduler to make imaging runs. Target field is filled in capture module if you go to a target. But it doesn't override what you have there in case you select a custom name. The scheduler puts the target name automatically there for each job. That's what it should do but if I select one target to track, and it fills in the field, then move to another target, the target does not change. It only ever fills out the field once that I can see, and then labels the new capture incorrectly if you don't correct it by hand. This may be related to being linked to selected jobs. The target name is also saved in each job and reprinted if that job is then reselected even though you can't actually edit the fields and have to remake then delete the wrong one, the process of which resets the fields to the wrong one when you select it to delete it..Then repeat all 4 times to alter a single rgb run. I would like to suggest disconnecting the entry form fields from jobs already in queue, But having the name field fill in the name when a target is selected/tracked target really is nice when it works. Another thought here, and possibly the original intent of having the fields track the jobs, is that instead of having to remake/delete/reset/remake/delete/reset..etc. make it so they actually do edit when you select and change them, maybe a save button? Personally I think disconnecting from jobs already in queue might work better. Just my 2c...fwiw. Cheers, Ray ps. I just reread the original issue and I'm not sure I did the right thing putting it here. Mine is related but a bit different I think, I can remake this into a new one if you want. Please check against KStars 3.6.1 and report back. Hi Jasem! I'll set up a test in a vm soon as I get a chance. I went ahead and updated kstars to bleeding on my notebook at lunch (not my primary production device) and tested it there with simulators. Works great! I did bode and got the ngc number and then mercury and it put mercury in the capture spot. I didn't get into scheduling in this test. Currently running Mint 21 xfce on acer aspire5/Ryzen3 w/ vega graphics. I'm at the end of energy doing long nights gathering Jupiter data so I'll do the same with my production setup tonight, likely the last night I'll stay up for this one. That system is getting an overhaul in the next week so is a good time to get do a full run with the new version. :cowboy: (In reply to Jasem Mutlaq from comment #5) > Please check against KStars 3.6.1 and report back. It works now in KStars 361 : - if the Search panel is closed and reopened, it DOES contain the name of the just found target - Selecting an object by a double-click + slewing to it , fills correctly the prefix field in the CCD panel - but the Mount Control / Target field is not filled by the name of the just found target Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Bug Janitor : for me , the bug has been solved I also see an improvement in this regard. I will change the status to solved. |