Re: Build problem on mac
Hi On Sun, Apr 26, 2015 at 03:51:52PM +0200, Robert C. Helling wrote: let me add, that I do not have this problem when building on my office mac but it persists with a brand new cloned subsurface tree (for which I encountered other problems as marble was not finding its own header files so I had to link them to the build directory). further investigation reveals that indeed there is no libssrfmarble in subsurface/build/Subsurface.app/Contents/ besides the other dylib’s. And the fact that the hard coded path in subsurface/packaging/macosx/make-package.sh contains ‚hohndel‘ does not make me optimistic (but git blame says this is old and simply changing it to my path does not solve the problem). What? Your Mac doesn't have a path with 'hohndel' in it? It must be broken. All of mine do. You should take it to the Apple store and have it checked :-) More seriously... Tomaz fixed this Tuesday night and since then has been preparing the patches... I'm sure he'll send them soonishly. I'm disappointed that this is turning out to be such a pain. I got it to work on my system and assumed it would work the same way for everyone. But clearly I used the wrong tools to do this. Let's hope that Tomaz sends out these patches. I should have just grabbed them from his system while he was here :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTCTools import support
On 03 April, 2015 - Anton Lundin wrote: On 30 March, 2015 - Anton Lundin wrote: On 29 March, 2015 - Salvador Cuñat wrote: /snip All OSTCTools .dive files I could achieve are OSTC-2N/C series. It would be great to have some testing for logs from OSTC3, FROG or SPORT devices. Anton, Could you provide some .dive file from your OSTC3? I've managed to get OSTCProfile.exe running in a wine prefix, and now i just need to find where my divecomputers are after the move, and I'll send some test files your way. Nope. One gasswitch event in one of my dives in my OSTC3 is corrupt so OSTCProfile.exe crashes on division by zero. You need to wait a couple of more weeks before I can go and do more data-collection with my computers. Chokay. Now some hacking later, i've read out the broken logbook from my device, fixed it, and written it back into the device again. I just love having access to the firmware of the device so you can figure out how to do things like this. But, still problems with OSTCProfile.exe. Now it runs, but it doesn't save any files, or show any profiles. I've tested in wine on my machine, and on a borrowed windows box. Same problem at both. (The darn thing doesn't allow we to choose the right com-port even, so i need to registry-hack the system to set the default port right so it even can open the device...) Anyhow. I'm out of ideas on how to produce some data to try to import. After my experience with OSTCProfile, i don't think any users will have data they would like to import either. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt5 scrolling problem
On Sun, Apr 26, 2015 at 6:39 PM, Linus Torvalds torva...@linux-foundation.org wrote: So I mentioned to Dirk last week that I had found a regression in subsurface, but I hadn't pinpointed the cause. I spent some time trying to figure out why current subsurface does the wrong thing, and quite frankly, I *still* don't get it, but by now I'm blaming Qt5 for being horrible and wrong. The regression is that when I start up subsurface, it scrolls the divelist view so that the latest dive is at the top. But that's what should happen! I hear you say. No it's not, actually. The dive list should start with the latest *trip* visible, and that's how it used to be. But current subsurface starts up with the dive itself at the top, and the trip description has scrolled off the list view. Explicitly to avoid that, our common scrolling pattern is that we first scroll to the trip that the dive is in, and then scroll to the dive itself. The reason we do that is exactly so that the trip would be visible, unless the trip is so big that scrolling to the specific dive ends up scrolling the trip header off the screen. Now, the reason seems to be currentChanged(), which does just if (!current.isValid()) return; scrollTo(current); but the reason I'm blaming Qt5 for this mess is that when I change it to do if (!current.isValid()) return; if (current.parent().isValid()) scrollTo(current.parent()); scrollTo(current); it still doesn't work. The last scrollTo(current) seems to scroll the parent (the trip) off the top of the window again, and you end up with the dive visible on the first line, but the trip not visible. Removing that final scrollTo(current): fixes things for me, but that will afaik do the wrong thing if a trip has a lot of dives, and we select one that isn't visible after you've scrolled the trip line to be visible. So I'm not sure what's going on. We've used some variation of that scroll to parent, then scroll to dive in several places, sometimes together with expand(parent); and setAnimated(false/true); around the parent scrolling so that we wouldn't be visibly jerking back-and-forth. The default for scrollTo() is ScrollHint::EnsureVisible, but the dive *is* visible when you've scrolled the trip to the top, so it shouldn't scroll the trip away. My *guess* is that this all happens before the window has been painted and setup completely, so it doesn't have its final size, leading to Qt5 thinking the dive isn't visible and scrolling to it, and scrolling away the trip line. But somebody who actually knows Qt is needed. Anybody who understands Qt? Tomaz? Thiago? And this doesn't show up for everything. If I do ./build/subsurface dives/*.xml to try to show this with the test-dives we have, I don't get the same behavior as I do with . Then I *do* get the trip header visible. So if some Qt person doesn't go I know what's up, and cannot reproduce this, I can send you all my dives in an xml file in private to help you see the behavior.. Linus Linus, I have dirk`s dive file here, I`ll try to use them to check for this regression. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Qt5 scrolling problem
So I mentioned to Dirk last week that I had found a regression in subsurface, but I hadn't pinpointed the cause. I spent some time trying to figure out why current subsurface does the wrong thing, and quite frankly, I *still* don't get it, but by now I'm blaming Qt5 for being horrible and wrong. The regression is that when I start up subsurface, it scrolls the divelist view so that the latest dive is at the top. But that's what should happen! I hear you say. No it's not, actually. The dive list should start with the latest *trip* visible, and that's how it used to be. But current subsurface starts up with the dive itself at the top, and the trip description has scrolled off the list view. Explicitly to avoid that, our common scrolling pattern is that we first scroll to the trip that the dive is in, and then scroll to the dive itself. The reason we do that is exactly so that the trip would be visible, unless the trip is so big that scrolling to the specific dive ends up scrolling the trip header off the screen. Now, the reason seems to be currentChanged(), which does just if (!current.isValid()) return; scrollTo(current); but the reason I'm blaming Qt5 for this mess is that when I change it to do if (!current.isValid()) return; if (current.parent().isValid()) scrollTo(current.parent()); scrollTo(current); it still doesn't work. The last scrollTo(current) seems to scroll the parent (the trip) off the top of the window again, and you end up with the dive visible on the first line, but the trip not visible. Removing that final scrollTo(current): fixes things for me, but that will afaik do the wrong thing if a trip has a lot of dives, and we select one that isn't visible after you've scrolled the trip line to be visible. So I'm not sure what's going on. We've used some variation of that scroll to parent, then scroll to dive in several places, sometimes together with expand(parent); and setAnimated(false/true); around the parent scrolling so that we wouldn't be visibly jerking back-and-forth. The default for scrollTo() is ScrollHint::EnsureVisible, but the dive *is* visible when you've scrolled the trip to the top, so it shouldn't scroll the trip away. My *guess* is that this all happens before the window has been painted and setup completely, so it doesn't have its final size, leading to Qt5 thinking the dive isn't visible and scrolling to it, and scrolling away the trip line. But somebody who actually knows Qt is needed. Anybody who understands Qt? Tomaz? Thiago? And this doesn't show up for everything. If I do ./build/subsurface dives/*.xml to try to show this with the test-dives we have, I don't get the same behavior as I do with . Then I *do* get the trip header visible. So if some Qt person doesn't go I know what's up, and cannot reproduce this, I can send you all my dives in an xml file in private to help you see the behavior.. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: User manual changes for 4.5
On Sat, Apr 25, 2015 at 09:26:28AM +0300, Benjamin wrote: Hopefully I'll get to it early next week (this weekend is busy - I have my second dan black belt test tomorrow and will spend Sunday dealing with the pain and soreness :-D ) Good luck for the test. From personal experience, the pain should fade quickly :) Test went well. I'm rather sore (~6h of fairly serious workout yesterday) but I had fun. Ibuprofen helps with the pain :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Grey out unused UI elements
From 4973fa45ecf4d065364d64a9af4ab50530260e1c Mon Sep 17 00:00:00 2001
From: Robert C. Helling hell...@atdotde.de
Date: Sun, 26 Apr 2015 21:40:36 +0200
Subject: [PATCH] Disable planner UI elements without function
This disables planner UI elements in recreational mode that have no function
in that mode.
Signed-off-by: Robert C. Helling hell...@atdotde.de
---
qt-ui/diveplanner.cpp | 12
qt-ui/diveplanner.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/qt-ui/diveplanner.cpp b/qt-ui/diveplanner.cpp
index b21f7f9..a5b6e1e 100644
--- a/qt-ui/diveplanner.cpp
+++ b/qt-ui/diveplanner.cpp
@@ -376,6 +376,15 @@ void PlannerSettingsWidget::decoSacChanged(const double
decosac)
plannerModel-setDecoSac(decosac);
}
+void PlannerSettingsWidget::disableDecoElements(bool value)
+{
+ ui.lastStop-setDisabled(value);
+ ui.backgasBreaks-setDisabled(value);
+ ui.bottompo2-setDisabled(value);
+ ui.decopo2-setDisabled(value);
+ ui.reserve_gas-setDisabled(!value);
+}
+
void DivePlannerWidget::printDecoPlan()
{
MainWindow::instance()-printPlan();
@@ -457,6 +466,8 @@ PlannerSettingsWidget::PlannerSettingsWidget(QWidget
*parent, Qt::WindowFlags f)
connect(ui.gflow, SIGNAL(editingFinished()), plannerModel,
SLOT(triggerGFLow()));
connect(ui.backgasBreaks, SIGNAL(toggled(bool)), this,
SLOT(setBackgasBreaks(bool)));
connect(ui.rebreathermode, SIGNAL(currentIndexChanged(int)),
plannerModel, SLOT(setRebreatherMode(int)));
+ connect(DivePlannerPointsModel::instance(),
SIGNAL(recreationChanged(bool)), this, SLOT(disableDecoElements(bool)));
+
settingsChanged();
ui.gflow-setValue(prefs.gflow);
ui.gfhigh-setValue(prefs.gfhigh);
@@ -876,6 +887,7 @@ void DivePlannerPointsModel::setDisplayTransitions(bool
value)
void DivePlannerPointsModel::setRecreationalMode(bool value)
{
prefs.recreational_mode = value;
+ emit recreationChanged(value);
emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS
-1));
}
diff --git a/qt-ui/diveplanner.h b/qt-ui/diveplanner.h
index 6cfcc5e..988c908 100644
--- a/qt-ui/diveplanner.h
+++ b/qt-ui/diveplanner.h
@@ -100,6 +100,7 @@ signals:
void planCanceled();
void cylinderModelEdited();
void startTimeChanged(QDateTime);
+ void recreationChanged(bool);
private:
explicit DivePlannerPointsModel(QObject *parent = 0);
@@ -183,6 +184,7 @@ slots:
void setBottomPo2(double po2);
void setDecoPo2(double po2);
void setBackgasBreaks(bool dobreaks);
+ void disableDecoElements(bool value);
private:
Ui::plannerSettingsWidget ui;
--
1.9.5 (Apple Git-50.3)
Thanks Tomaz!
Best
Robert___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: osx fixes for marble / subsurface build.
this is the marble patch. On Sun, Apr 26, 2015 at 3:51 PM, Tomaz Canabrava tcanabr...@kde.org wrote: People, I got many many issues trying to make this works reasonably well: fixed issue with CMake on marble ( that used the incorrect path for the library ) fixed a few issues with build.sh / subsurface please note that this shouldn`t break anything for non mac users, and mac users - please note that this shouldn`t break anything, but instead make it work. we don`t need libgit from brew anymore, and it`s hardcoded to use our copy from the build script. I just rebuild my entire subsurface from scratch ( together with libgit, libmarble, libdivecomputer ) and it worked, I sincerely hope it will work for all of you. please note that one of the patches is a MARBLE patch, that Ill attach in a next e-mail to avoid confusion, but things should be applied in subsurface and marble before trying to compile. 0001-Fixed-deployment-of-the-marble-library-with-correct-.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
osx fixes for marble / subsurface build.
People, I got many many issues trying to make this works reasonably well: fixed issue with CMake on marble ( that used the incorrect path for the library ) fixed a few issues with build.sh / subsurface please note that this shouldn`t break anything for non mac users, and mac users - please note that this shouldn`t break anything, but instead make it work. we don`t need libgit from brew anymore, and it`s hardcoded to use our copy from the build script. I just rebuild my entire subsurface from scratch ( together with libgit, libmarble, libdivecomputer ) and it worked, I sincerely hope it will work for all of you. please note that one of the patches is a MARBLE patch, that Ill attach in a next e-mail to avoid confusion, but things should be applied in subsurface and marble before trying to compile. 0001-Don-t-deppend-on-CMake-to-find-the-right-libraries.patch Description: Binary data 0002-CMake-needs-hints-that-this-will-be-a-win32-or-a-mac.patch Description: Binary data 0003-Always-reconfigure-libdivecomputer.patch Description: Binary data 0004-Do-not-call-install_name_tool-for-Marble-library.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
