Summary: | manual filter wheel or filter drawer option | ||
---|---|---|---|
Product: | [Applications] kstars | Reporter: | Tommy LKW <tlkw79> |
Component: | general | Assignee: | TallFurryMan <eric.dejouhanet> |
Status: | REPORTED --- | ||
Severity: | wishlist | Keywords: | triaged |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Tommy LKW
2018-07-05 06:22:56 UTC
I agree on adding a settings option to the Capture module to allow manual change of a filter. If such option is set, a pop-up requesting the change would block the Capture module for the end-user to run the change, as stated in point 3 from the OP. Point 1 can be handled with the Filter Wheel Simulator with no implementation change, as long as the request to the end-user is made before requesting the Simulator to change the filter (because that changes the state of the Capture module too soon). It is the responsibility of the end-user to configure the filter names in the Filter Wheel Simulator so that they match the sequence because that has an impact on capture storage files, as mentioned in point 1 from the OP. Proper numbering of the filter on the wheel is not needed, but is recommended for clarity. Point 3 is already covered if we use the Filter Wheel Simulator. Point 4 cannot be achieved, but actually only the Capture module requires operations to be blocked. That's probably what the OP meant anyway. Default value must be disabled, no blocking of the Capture module for manual filter change. Location of the option in the UI is not easy. We need an option that pertains to the Capture module, and related to the filter, so the first idea would be to implement it with a checkbox in the Filter Settings, under the focus offset table. While it might be easily forgotten here, the fact that a pop-up would remind the end-user of this option is probably enough. Open question: in the implementation, are filter offsets relevant for a single filter selection, or general to all filters? Open question: would it be interesting to have the feature even for automated filter wheels, to allow tinkering in that case too? (nothing in this post suggestions prevents this) Open question: in the implementation, are filter offsets relevant for a single filter selection, or general to all filters? It is best if filter offsets relevant for single filter selection. Hi, sorry for asking. Any progress on this request so far? Thanks. No, no yet. That feature is properly specified, but we are busy fixing issues in the Scheduler. (In reply to TallFurryMan from comment #4) > No, no yet. That feature is properly specified, but we are busy fixing > issues in the Scheduler. Thanks for the reply. Good to hear that. Thank you. 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 set the bug status 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! I have also no idea what is the progress of this request. It looks like it takes forever to fullfil the request. :( All depends on the Kstars developer now. Indeed it does depend on the free time of the handful of developers :) We need to prioritize, and currently most of the work is fixing side-effects following the D-Bus changes. We won't introduce new features until the most serious ones are patched. But we will gladly review implementation patches. Marking reported, so that the ticket doesn't go away. Thank you. I am under the impression that this issue is still current. There is a workaround that consists in adding a Filter Wheel Simulator with enough movement time to allow manual intervention. 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! Keeping reported, I didn't have bandwidth to check. |