No need to reduce the spacing if it detracts. I suspect changing orientation would be arbitrary too. If you figure out how to launch the Kstars FITS viewer on the selected filename (and probably want to limit this to some number 1-5 to avoid user select mis-steps), I'd say maybe the next thing to consider might be a CSV data export (for user selected lines & columns). This enables other tools (Python, Excel, etc) to take advantage of the growing info content of DB fields.
If you do decide to add CSV export, I would recommend you add both row index selector and column selector. There's no current row index (but users can mouse select/drag). Selecting a column is currently reserved for sort order (asc/decend). A minimum column rectangle above each column heading could serve to allow users to select the entire column contents. On row index, folks are so used to seeing line number, I'd just include it and use it as the entire row selector.
BTW, I couldn't figure out how to see hidden fields after hiding, then unchecking. How is that accomplished? If no auto-refresh on the GUI, then should a refresh button be added to see the fields again?
Ok! Now we're talking. Congrats on a very nice project. I confirm platform independence works for CSV file paths via the conversion strings. Having PI stats with DB search/filters is very nice. I'll look forward to having a few more important fields in the future (focus position, focus HFR, seeing, etc.). I'd recommend a CSV interface for those fields too, with keywords TBD.
A couple more thoughts. Currently, when you double click on an image, a Details View pops up. I recommend reducing white space between fields (minimize vertical space). Next is the image viewer. Can you support association (via settings) for launching a different viewer? If so, this would really amp up presentation. The kstars FITS viewer would be an ideal candidate to allow. It's very nice for OSC subexposures. Images are nicely stretched and colored with bells/whistles for movement etc. The current viewer could serve as a good default....
In any case, even if you can't associate/launch another viewer, at this point, I will use AD and recommend it to others as well. Good Job! Cheers, Doug
Hi Alex, I confirm what Jasem says.....I have a CGX-L and connection is via the handset. Run your handset USB cable to your Hub or PI4 USB port, then try again. Cheers, Doug
So, before I do my own CSV path string conversion from Windows to Linux, are you sure you don't want AD to be architecture independent for this particular detail? Grabbing the path string from the CSV and converting to local form for all might be better than me doing this for myself only... As I said before, the preferred method would be two strings (to,from) to accommodate filesystem mount point differences.
A second question for you is whether the astrodom_linux_upgrade.sh script down in resources works correctly for minor updates. I did the full pull/install last time, and if the update script works more simply for minor patches like this latest one, that would be preferred. Can you comment on that script? Thanks.
Ferrante, I've updated to your latest. Thanks! The changes work as expected (I was able to save the changed field sizes, and resize the GUI). Much better. I am still getting a core dump on at least one specific use case. If you start to import a CSV file, but instead of following though, you "cancel" before loading the file, the app will core dump consistently. Here's the trace:
Traceback (most recent call last):
File "/home/dsummers/src/archive/AstroDom-master/resources/venv/lib/python3.8/site-packages/astrodom/importCsvTab.py", line 67, in importCsvFile
for row, val in enumerate(dataTemp):
UnboundLocalError: local variable 'dataTemp' referenced before assignment
./astrodom_linux_run.sh: line 18: 391996 Aborted (core dumped) python3 -m astrodom
I doubt this is a python3 thing.....probably want to chase that.
@Max: "The question is - which alignment to prefer?"
Without trying to be a smart..., you want a true PA. If PA tools/methods conflict, the way to know definitively is to drift align. PHD2's drift align tool is painless to use and simple; I ALWAYS use it. My advice would be to run both procedures, then compare answers (run PHD2 drift align last). You can trust what PHD is telling you about PA assuming you setup correctly (2 stars are required, one near DEC 0 south meridian, another near DEC 0 east horizon). If the methods agree, great. If they don't, you'll at least know. Cheers, Doug
Also, while recently distracted by AD archive tool and PHD2 logViewer support (and trying to get some dark time imaging in as well), I do still intend to investigate adding the "else clause" referenced at the beginning of this thread so that folks with more generalized temperature sensors (e.g. PPB, PPB-V2) can have correlated focus/temperature log entries. I hope this data will lead to real-time, temperature based focus adjustments between images. Ideally, for well behaved setups, this could reduce the need for full focusing runs to start of night and/or one-off adjustments.
I'm sure you've taken the words right out of many mouths in your last paragraph(s). This isn't the first code set to be difficult to work with, and it won't be the last. There's precious little help via documentation or examples for folks to leverage. It definitely should be easier than this. This is why I posted this request recently:
As it is, you've really got to want to go an extra 10 miles to get over the learning hump, because it's going to be a rough start for sure. I hope you make it (as I hope for myself). No help (I know) on the specific issue of Qt Creator buttons, but no need to feel sorry for a minor complaint. Cheers, Doug
Ok, I was able to confirm the CSV issue. A Windows CSV file must be converted to match Linux path convention. So, for example, each C:\Users\Image\blah line on PC must be converted to /home/Image/blah before AD will work correctly. Once I did this, AD was able to find the associated image file and import it (with correct results).
Not sure if you want to add a feature for this architecture nuance or not. Windows users can just push the CSV file to linux and run a script to convert, but it would be nice to have a "setting" for architecture specific CSV path conversion. If you do address it, I suggest two strings (from, to) as this will kill architecture AND any mount point naming differences.
Ok, I think I might know what's going wrong with the CSV import. Pixinsight is running on a windows host. AD runs from a Linux guest within VirtualBox. There is a shared filesystem between these two hosts (windows owns the disk). Linux maps a mount point to the windows drive. The windows side (Pixinsight) knows the directory as C:\Users\dsummers\Astro\Images\M3:
Here's one of the CSV lines showing the filename:
The linux side knows this same file system as:
These are the same disk location, but the names are different between windows and linux. So, I think this must be part of the issue. I can import the files because the AD GUI internals likely map the mountpoint correctly, but is the hash or program somehow confused by mount point naming convention differences between the hosts?
Hmm....what to do?