Moving Subsurface photos between directories
Robert, Please look through the following paragraph for the user manual, will you? Your system provides pretty sophisticated image management. None of the image management software that I use includes such automatic remapping of image locations. Its impressive. Three suggestions to make the management of images using hash sums more smooth: 1) If I understand it correctly there is a problem in calculating hashes for each photo already associated with a dive in Subsurface. That is, to update the existing dive log so that all photos have valid hash sums in XML. It appears to me that, in order to do this, one has to force Subsurface to save a dive while the photos are shown for that dive. In large photo collections over large numbers of dives this may be a very tedious and somewhat risky job: Open each dive individually, Do some changes to dive details, save update for that dive. IF I AM CORRECT, I think there is a big need for a facility that determines whether a) there is an existing XML hash attribute for each image, b) if so, whether the XML hash sum for each image is a valid hash sum, c) if there is no hash sum or an invalid hash sum (e.g. ), then to calculate the hash sum for the image and write that into the XML. Is my understanding of this correct? Because this is a once-of type of activity, such a facility should probably be activated by a command line option, not from within the GUI. 2) The option Hash images in the main menu is a bit cryptic for non-technical users. I would suggest Find moved images or something similar ?? 3) Any way of reusing the same bottom blue bar shown while converting a XML dive log to the new XML format? Some type of visual feedback while doing the hash sum calculations and updating for all images is crucial. Kind regards, willem [[Moving_images]] Moving photographs among directories, hard disks or computers After a photograph has been loaded into _Subsurface_ and associated with a specific dive, the directory where the photo lies is stored, allowing _Subsurface_ to find the photograph when the dive is opened again. If the photo or the whole photo collection is moved to another drive or to a different machine, it is unlikely that the directory structure will remain identical to that of the original uploaded photo. When this happens, _Subsurface_ looks for the photos at their original location before they were moved, cannot find them and therefore cannot display them. Because, after moving photos, large numbers of photos may need to be deleted and re-imported from the new location, _Subsurface_ has a mechanism that eases the process of updating the directory information for each photo: automatic updates using fingerprints. When a photo is loaded into _Subsurface_, a fingerprint for the image is calculated and stored with the other reference information for that photo. After moving a photo collection (that has already been loaded into _Subsurface_) to a different directory, disk or computer, _Subsurface_ can perform the following steps: - look through a particular directory (and all its subdirectories recursively) where photos have been moved to, - calculate fingerprints for all photos in this directory, and - if there is a match between a calculated fingerprint and the one originally calculated when a photo was loaded into _Subsurface_ (even if the original file name has changed), to automatically update the directory information so that _Subsurface_ can find the photo in the new moved directory. This is achieved by selecting from the Main Menu: _File - Hash images_. This brings up a window within which the NEW directory of the photos needs to be specified. Select the appropriate directory and click the _Scan_ button towards the bottom right of the panel. The process may require several minutes to complete, after which _subsurface_ will show the appropriate photographs when a particular dive is opened. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: new Windows 4.4.1 binary is up
On Wed, 29 Apr 2015 at 00:02 Dirk Hohndel d...@hohndel.org wrote: Didn't want to go through the pain of calling it 4.4.2 - and the only difference is that uploads to Divelogs.de with non-ascii home path now seem to work. Rainer, if you have any other users who complained about that... this might be the solution. /D Installed flawlessly on windows 8, but when I start it up a warning pops up: checking for updates. the server returned the following information: you are running an unknown product version 4.4.1.0. Latest released version is 4.3. It's just a minor annoyance of course... Peter. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: new Windows 4.4.1 binary is up
On Wed, Apr 29, 2015 at 06:49:35AM +, Peter Konings wrote: On Wed, 29 Apr 2015 at 00:02 Dirk Hohndel d...@hohndel.org wrote: Didn't want to go through the pain of calling it 4.4.2 - and the only difference is that uploads to Divelogs.de with non-ascii home path now seem to work. Rainer, if you have any other users who complained about that... this might be the solution. /D Installed flawlessly on windows 8, but when I start it up a warning pops up: checking for updates. the server returned the following information: you are running an unknown product version 4.4.1.0. Latest released version is 4.3. It's just a minor annoyance of course... Oh how embarrassing. I was still checking for the latest Qt4-32bit version if people connected from 32bit Windows. I can't believe I missed that. Please try again, it should now tell you that the latest is indeed 4.4.1 Thanks for pointing this out! /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
How about 4.4.2? [was Re: new Windows 4.4.1 binary is up]
I just merged our libdc branches with the latest upstream from libdivecomputer. More precisely, Subsurface-4.4 branch was merged, but Subsurface-testing was rebased, so that one will require a force pull. Jef has done some good work recently and added support for a few more dive computers. So if I were to make a 4.4.2 release with the latest libdivecomputer code included... are there any other fixes in master that I absolutely should back port? I know that I'd take a couple of my Uemis fixes as Uemis support in 4.4.1 is actually rather broken :-( Anything else? /D On Tue, Apr 28, 2015 at 03:02:22PM -0700, Dirk Hohndel wrote: Didn't want to go through the pain of calling it 4.4.2 - and the only difference is that uploads to Divelogs.de with non-ascii home path now seem to work. Rainer, if you have any other users who complained about that... this might be the solution. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Add a default case for switch over dc_family_t
This adds a default case which just errors out for the switch over
dc_family_t instead of checking a uninitialized variable if this was
ever called with something else than one of the expected dc-family
types.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
libdivecomputer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libdivecomputer.c b/libdivecomputer.c
index 069e87b..f07023f 100644
--- a/libdivecomputer.c
+++ b/libdivecomputer.c
@@ -963,6 +963,9 @@ dc_status_t libdc_buffer_parser(struct dive *dive,
device_data_t *data, unsigned
case DC_FAMILY_HW_OSTC3:
rc = hw_ostc_parser_create (parser, data-context,
data-deviceid, 1);
break;
+ default:
+ report_error(Device type not handled!);
+ return DC_STATUS_UNSUPPORTED;
}
if (rc != DC_STATUS_SUCCESS) {
report_error(Error creating parser.);
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Add urldialog.ui to qmake ui list
This unbreaks the qmake build system by adding urldialog.ui there. Yes, i know we're planning on switching away but i still build things via qmake and its nice if it works until we actually remove it. Signed-off-by: Anton Lundin gla...@acc.umu.se --- I remember that I also fixed the old plain make based thingie before the switch to qmake. Is this becomming some sort of habit? subsurface.pro | 1 + 1 file changed, 1 insertion(+) diff --git a/subsurface.pro b/subsurface.pro index bec7d65..be6e060 100644 --- a/subsurface.pro +++ b/subsurface.pro @@ -253,6 +253,7 @@ FORMS = \ qt-ui/diveshareexportdialog.ui \ qt-ui/filterwidget.ui \ qt-ui/plannerDetails.ui \ + qt-ui/urldialog.ui \ qt-ui/locationInformation.ui # Nether usermanual or printing is supported on android right now -- 2.1.4 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Two patches image hashing
… as suggested by Willem.
From bb0a4539cfa4d2c05229b741b99fa4797bc077da Mon Sep 17 00:00:00 2001
From: Robert C. Helling hell...@atdotde.de
Date: Wed, 29 Apr 2015 22:17:59 +0200
Subject: [PATCH 1/2] Display a notification while image hashing is ongoing.
Signed-off-by: Robert C. Helling hell...@atdotde.de
---
qt-ui/mainwindow.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qt-ui/mainwindow.cpp b/qt-ui/mainwindow.cpp
index e22f340..23f9551 100644
--- a/qt-ui/mainwindow.cpp
+++ b/qt-ui/mainwindow.cpp
@@ -330,6 +330,7 @@ void learnImageDirs(QStringList dirnames)
void MainWindow::on_actionHash_images_triggered()
{
+ QFuturevoid future;
QFileDialog dialog(this, tr(Traverse image directories),
lastUsedDir(), filter());
dialog.setFileMode(QFileDialog::Directory);
dialog.setViewMode(QFileDialog::Detail);
@@ -340,7 +341,10 @@ void MainWindow::on_actionHash_images_triggered()
dirnames = dialog.selectedFiles();
if (dirnames.isEmpty())
return;
- QtConcurrent::run(learnImageDirs,dirnames);
+ future = QtConcurrent::run(learnImageDirs,dirnames);
+
MainWindow::instance()-getNotificationWidget()-showNotification(tr(Scanning
images...(this can take a while)), KMessageWidget::Information);
+ MainWindow::instance()-getNotificationWidget()-setFuture(future);
+
}
ProfileWidget2 *MainWindow::graphics() const
--
1.9.5 (Apple Git-50.3)
From eb12c914c62a3f3b6b925574ecee5c4ae0dca84f Mon Sep 17 00:00:00 2001
From: Robert C. Helling hell...@atdotde.de
Date: Wed, 29 Apr 2015 22:53:32 +0200
Subject: [PATCH 2/2] Rename menu entry for image hashing
Signed-off-by: Robert C. Helling hell...@atdotde.de
---
qt-ui/mainwindow.ui | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qt-ui/mainwindow.ui b/qt-ui/mainwindow.ui
index 1494706..b5456f2 100644
--- a/qt-ui/mainwindow.ui
+++ b/qt-ui/mainwindow.ui
@@ -699,7 +699,7 @@
/action
action name=actionHash_images
property name=text
-stringHash images/string
+stringFind moved images/string
/property
/action
/widget
--
1.9.5 (Apple Git-50.3)
Best
Robert___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: new Windows 4.4.1 binary is up
On Wed, 29 Apr 2015 at 14:58 Dirk Hohndel d...@hohndel.org wrote: On Wed, Apr 29, 2015 at 06:49:35AM +, Peter Konings wrote: On Wed, 29 Apr 2015 at 00:02 Dirk Hohndel d...@hohndel.org wrote: Didn't want to go through the pain of calling it 4.4.2 - and the only difference is that uploads to Divelogs.de with non-ascii home path now seem to work. Rainer, if you have any other users who complained about that... this might be the solution. /D Installed flawlessly on windows 8, but when I start it up a warning pops up: checking for updates. the server returned the following information: you are running an unknown product version 4.4.1.0. Latest released version is 4.3. It's just a minor annoyance of course... Oh how embarrassing. I was still checking for the latest Qt4-32bit version if people connected from 32bit Windows. I can't believe I missed that. Please try again, it should now tell you that the latest is indeed 4.4.1 Thanks for pointing this out! /D Thanks for fixing this: it works as expected now. Peter ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Suunto EON sample interval
Hi Linus, I am looking at a log from Suunto EON Steel and it seems that it generally has a 10 second sample interval. However, there is a leap second every now and then. Thus causing a drift on the sample times. Did you see this on your the EON? The log is from Subsurface, so I am wondering if this is something that Subusrface does or is it normal for the EON, or something else. ---8--- sample time='2:41 min' depth='13.55 m' temp='6.1 C' pressure='177.2 bar' ndl='53:00 min' / sample time='2:51 min' depth='14.11 m' pressure='176.65 bar' ndl='50:00 min' / sample time='3:01 min' depth='15.04 m' temp='6.0 C' pressure='175.39 bar' ndl='45:00 min' / sample time='3:11 min' depth='15.77 m' temp='5.9 C' pressure='174.89 bar' ndl='40:00 min' / sample time='3:22 min' depth='16.9 m' pressure='173.93 bar' ndl='34:00 min' / sample time='3:32 min' depth='18.0 m' pressure='172.9 bar' ndl='30:00 min' / sample time='3:42 min' depth='19.3 m' temp='5.8 C' pressure='172.14 bar' ndl='26:00 min' / sample time='3:47 min' depth='19.3 m' / sample time='3:52 min' depth='20.87 m' temp='5.7 C' pressure='171.65 bar' ndl='22:00 min' / ---8--- There is also some odd samples which I assume are interpolated by Subsurface to correspond to events (even though there is no corresponding event visible on the log for every single interpolated sample). miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Suunto EON sample interval
On Apr 29, 2015 20:25, Miika Turkia miika.tur...@gmail.com wrote: I am looking at a log from Suunto EON Steel and it seems that it generally has a 10 second sample interval. No. The eon steel gives time difference in the samples, and they are not ten seconds apart, they are given in *milliseconds* and while close to ten seconds they are not exactly that. I have the logs, but am not in front of my computer right now. So not only are things not at an even second to begin with, there are events that happen outside of the regular samples that may have timestamps that change things even more. My eon importer keeps track of the time in milliseconds internally (it really has to - ask the times are incremental and in that format) but then exposes them in seconds (because that's the same format, and the libdivecomputer interface). So you'll never see the traditional every x seconds behavior. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
