When Scheduler configures Capture, it sets the target name as part of the folder to which to store captured frames. Following the D-Bus rework, target name is not part of that path. Reason is that the method setting the target name was replaced by a property, and Scheduler code requires update to accommodate that. However, this situation could be an opportunity to rewrite that feature, which is scattered over many places in capture.cpp. The location where Capture stores frames is given by the concatenation of: - Local directory, - Directory postfix, itself a concatenation of: -- Target name, if set, -- Frame type, -- Filter name, if any is used, and if frame is light or flat. The file name under which Capture stores frames is given by the concatenation of: - Explicit prefix, if set, - Frame type, - Filter name, if required, if any is used, and if frame is light or flat, - Exposure duration, if required, as integer if exposure has no fractional part, or decimal if it has, - Timestamp, if required, - Integer index. I observe that Capture UI indicates "Target" as default value of the prefix, as a watermark proposal. But there is no code managing that hint, and prefix never equals the target name. Target name is only used when set programmatically, and only in the folder path. All this is makes code complex, and creates a discrepancy between two use cases: - When used alone, Capture does not insert any object name as target name. -- "<local>/<frame>/<filter>/<prefix>_<frame>_<filter?>_<exposure?>_<timestamp?>_<index>.fits". - When used with the Scheduler, Capture inserts the name of the object that is the target of the Scheduler's observation job. -- "<local>/<target>/<frame>/<filter>/<prefix>_<frame>_<filter?>_<exposure?>_<timestamp?>_<index>.fits". There are few possibilities: - Make Capture fetch the target name from the last track request in KStars (but that may mean finding an object from RA/DEC? EmptySky?) - Add an explicit field (but that means a sequence can't be generic to multiple targets) This could also be a good opportunity to create a storage module, which would centralize and organize frames. We could imagine a separate tab in Ekos, with its own D-Bus interface, and showing the contents of the disk and allowing quick access to FITS files and headers (currently, checking the results of a night requires opening single files in FITSViewer). That module could then be extended with features to manipulate images, even make use of plugins, eventually jupyter notebooks or social features. But let's not get carried away.
Setting target name using member property targetName and method setProperty is failing. Something is wrong with the way of calling this. Investigating.
I just tested with a sample scheduler job and the target name was set just fine. Please double check again.
I think we should resolve this one now that clearSequence is removed. The issue was due to targetName being executed *before* clearSequence although the property setter was requested *after* clearSequence. I will remove most of the Q_NO_REPLY because there's no guarantee on the order they will execute. Our source is not prepared for this type of async calls. If you agree, of course.
Well, this is how the adaptor is created: " [ 13%] Generating domeadaptor.cpp, domeadaptor.h cd /home/tallfurryman/dev/kstars_build/kstars && /usr/lib/x86_64-linux-gnu/qt5/bin/qdbusxml2cpp -m -a domeadaptor -i ekos/auxiliary/dome.h -l Ekos::Dome /home/tallfurryman/dev/kstars/kstars/org.kde.kstars.Ekos.Dome.xml " So it's definitely taking "org.kde.kstars.Ekos.Dome.xml" as input. If I check this file, I can see "<signal name="ready"/>. When I look at "domeadaptor.h" in the build output, "Q_CLASS_INFO" for "D-Bus Introspection" doesn't have that string. That file is rebuilt properly because it doesn't exist beforehand after a "make clean". None of my changes to the XML source are reflected in the output. Note that I'm searching for a reason for the situation I'm in and why it doesn't work as I expect, not for a solution to this problem :) Sounds like ccache could get in the way there.
Found it! There is a syntax error in the dome XML, just after the declaration of "isMoving"! When qdbusxml2cpp generates the MOC, it doesn't report the error, but simply stops reading the XML file... Therefore, no definition after "isMoving" is taken into account. Wooooow.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. 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 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!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone!