[PATCH] Fix a couple of typos
Signed-off-by: Torstein Husebø
---
libdivecomputer.c| 2 +-
qt-ui/mainwindow.cpp | 2 +-
qt-ui/modeldelegates.cpp | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libdivecomputer.c b/libdivecomputer.c
index 942b1ec149..950b9da4ed 100644
--- a/libdivecomputer.c
+++ b/libdivecomputer.c
@@ -107,7 +107,7 @@ static int parse_gasmixes(device_data_t *devdata, struct
dive *dive, dc_parser_t
* dive computer, fill in the default tank information
(if set) */
fill_default_cylinder(&dive->cylinder[i]);
}
- /* whatever happens, make sure there is a name for the cylidner
*/
+ /* whatever happens, make sure there is a name for the cylinder
*/
if (same_string(dive->cylinder[i].type.description, ""))
dive->cylinder[i].type.description =
strdup(translate("gettextFromC", "unknown"));
}
diff --git a/qt-ui/mainwindow.cpp b/qt-ui/mainwindow.cpp
index b9e0f9877f..21d36d92f2 100644
--- a/qt-ui/mainwindow.cpp
+++ b/qt-ui/mainwindow.cpp
@@ -613,7 +613,7 @@ void MainWindow::on_actionDivePlanner_triggered()
graphics()->setPlanState();
- // create a simple starting dive, using the first gas from the just
copied cylidners
+ // create a simple starting dive, using the first gas from the just
copied cylinders
setupForAddAndPlan("planned dive"); // don't translate, stored in XML
file
DivePlannerPointsModel::instance()->setupStartTime();
DivePlannerPointsModel::instance()->createSimpleDive();
diff --git a/qt-ui/modeldelegates.cpp b/qt-ui/modeldelegates.cpp
index c6c46aa46a..66533b652c 100644
--- a/qt-ui/modeldelegates.cpp
+++ b/qt-ui/modeldelegates.cpp
@@ -252,7 +252,7 @@ TankInfoDelegate::TankInfoDelegate(QObject *parent) :
ComboBoxDelegate(TankInfoM
void TankInfoDelegate::reenableReplot(QWidget *widget,
QAbstractItemDelegate::EndEditHint hint)
{
MainWindow::instance()->graphics()->setReplot(true);
- // FIXME: We need to replot after a cylidner is selected but the replot
below overwrites
+ // FIXME: We need to replot after a cylinder is selected but the replot
below overwrites
//the newly selected cylinder.
// MainWindow::instance()->graphics()->replot();
}
--
2.3.3
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC 2015] An introduction
Hi, I want to introduce myself to all of you. I am Harshal Jalan. I am a freshman, doing my B. Tech.at the Indian Institute of Technology (IIT) Bombay, India. I would be applying for two projects, both under subsurface. One is for implementing the VPM algorithm in c/c++ and the other is for enhancing CCR support. I have successfully built subsurface on Ubuntu and tried some tinkering around using Qt creator. I am trying to solve #839 (addition of another stop at 5m/15ft). I have been coding in C++ and embedded C for about six months and I still have a lot of coding to learn. I have been coding in embedded C as part of a group (we are making a student satellite!) so I have an experience similar to Open source coding, but this is my first foray into open source coding. I have already learnt a lot of things while preparing for the GSoC application and am really excited about it. I am here to learn coding from the subsurface community and, eventually, contribute to the FOSS community. Harshal Jalan PS I am not a diver but i would really like to learn diving one day...! ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: How to reduce row height in table print
On 19 March 2015 at 01:28, Lutz Vieweg wrote: > Hi, > > I would like to print more dives per page in "table" mode, > just reducing the number sr=4 in >> >> const int sr = 12; // smallest row height in pixels >> profilePrintRowHeights.append(sr); > that's for the table in profile print. > does not help, even if also reducing the model.setFontsize(). > > Is there some easy way to tell subsurface to not put that much > margin above/below the table row texts? > that's a good question and i quickly experimented with some code to try to answer it. nothing works for me: CSS, Qt::SizeHintRole, explicit row heights, etc. thus, i don't have an answer ATM, so please wait for the print layout rework which is coming in the next few months. in the meantime if someone has a better idea why QTableView is so stubborn, you can give this a try. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Which protocol to implement on a home brewed diving computer ?
On 17 March, 2015 - Thomas Schrein (mailinglists) wrote: > Robert, > > Am 16.03.2015 um 17:35 schrieb Robert Helling: > >Thomas, > > > >>On 16.03.2015, at 14:29, Thomas Schrein (mailinglists) > >>mailto:tsx...@schrein.de>> wrote: > >> > >>The housing of oDiCo is made from plexiglas version 0.1 and filled with > >>silicon oel. The next housing 0.2 will be milled from POM and the > >>electronic will be an industry factored PCB. Awating to have it in the > >>lake in June ... > > > >once you are in the habit of making housings, you might be interested in a > >project idea that came up here a while ago: We all love to have cylinder > >pressure graphs in our logs. But for the dive computer to records those > >you either need a hose that tends to be in your way or a radio > >transmission which is hard to make reliable. The idea was, during the dive > >to stick with an analogue gauge (as the history is mainly important in the > >log only) but attach a little data recorder with pressure sensor directly > >to the first stage to be read out later together with the dive computer. > > > >I did not really pursue this idea much further since all the pressure > >sensors I could find that fit the specs (up to 400bar with at most a few > >bar resolution an simple readout) almost costed as much as the pressure > >radio transmitters (120-150 Euro/pcs) and, more importantly, my total lack > >of experience in building watertight housings. > > > >You might be at least the solution to part two of the problem. What do you > >think? > > Nice idea, never thought about such a logger. > > Let me first give you an overview about our approach: > We have an 400bar industry sensor in test. We will connect it to our > hardware version 0.1 in the next weeks and go diving. > We made an adapter to connect it to the high pressure hole on the regulator > and connect it with an M12-Sensor wire to the existing odico housing. > http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2159.JPG_1997443631.jpg > It works on the land, but we are not sure if its really watertight, that we > will see in the dive. > http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2179.JPG_1997443631.jpg > > One option (may be you better say vision ;-) in our project is to use the > odico electronics to control a rebreather using CANBUS (the controller has > it build in already) and therefore the high pressure sensor would act as an > CANBUS node with its own buildin controller, in particular a STMF1x, less > then 5€ each. The electronics could be sealed with casting resin. > For our rebreather approach we accept the existence of wires, so we don't > need to care about energy and communication. The pressure sensors cost about > 80€, plus the adapter for the high pressure, plus the wiring, but that costs > are not a big deal to run a rebreather. > My fellow, Marco, also doesn't care to much building even an self made > pressure sensor with build in electronics . He has a degree as mechanical > engineer and he's really gifted for job! > So we don't care too much to get it water tight. > > From my point of view a logger could be designed like this: > - located at the high pressure hole of the first stage > - length about 5 - 10 cm, cylindrical > - collecting data for pressure + time > - as an option: collection depth+temp > - energy by an AAA or 1/2 AA lithium 3v cell than could be replaced once a > year > - communication via radio (bluetooth, ...) > - shop price < 200 € > > Again, I never thought that would be worth to think about it. I will discuss > with Marco! > If you like we can discuss more. > I would be interested in such a device, even if they would be built as one off jobs. Only thing i would argue is really important is to make sure they fail in a sane manner, and doesn't leak or dump my gas. Now this one is seriously OT but a idea i hand a couple of mates had as a idea, a depth/time logger with a accelerometer/gyro and try to use that as a mapping device to try to figure out how your movements under water actually where. I talked with another mate who's in the defense industry and they have such devices on there (semi)autonomous rovs, but they combine the accelerometer/gyro with sonar and doppler radar against its surroundings for more input to their odometry models. That would be really cool =) //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt Bluetooth in 5.5
On 18 March 2015 at 05:48, Dirk Hohndel wrote: > > Thiago, > > would Subsurface benefit from using Qt Bluetooth for our intended Bluetooth > integration? > This would cause some interesting architectural challenges with > libdivecomputer (as that most definitely doesn’t want to depend on Qt), but I > find it very intriguing that Qt now supports all of the platforms we are > interested in… or am I missing something here? > i can see that libDC has a parser API exposed, but i don't know if / how does that works, but if Subsurface uses Qt's BT it can in theory just use libDC as a parser (Thiago mentioned the same). i think it would be better for the student to first help Jeff get the BT working in libDC for Win32 and Linux and then start working on the Subsurface side. but...if the OSX code is not going to be donated soon (or maintained well in that aspect), i suggest we just use Qt's BT. there is also the option for libDC to expose API to allow the libDC user to specify the BT backend (e.g.. built-in VS external C-wrapped Qt BT), but that's probably a ton of extra work for Jeff. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Which protocol to implement on a home brewed diving computer ?
Am 19.03.2015 um 14:14 schrieb Anton Lundin: > On 17 March, 2015 - Thomas Schrein (mailinglists) wrote: > >> Robert, >> >> Am 16.03.2015 um 17:35 schrieb Robert Helling: >>> Thomas, >>> On 16.03.2015, at 14:29, Thomas Schrein (mailinglists) mailto:tsx...@schrein.de>> wrote: The housing of oDiCo is made from plexiglas version 0.1 and filled with silicon oel. The next housing 0.2 will be milled from POM and the electronic will be an industry factored PCB. Awating to have it in the lake in June ... >>> >>> once you are in the habit of making housings, you might be interested in a >>> project idea that came up here a while ago: We all love to have cylinder >>> pressure graphs in our logs. But for the dive computer to records those >>> you either need a hose that tends to be in your way or a radio >>> transmission which is hard to make reliable. The idea was, during the dive >>> to stick with an analogue gauge (as the history is mainly important in the >>> log only) but attach a little data recorder with pressure sensor directly >>> to the first stage to be read out later together with the dive computer. >>> >>> I did not really pursue this idea much further since all the pressure >>> sensors I could find that fit the specs (up to 400bar with at most a few >>> bar resolution an simple readout) almost costed as much as the pressure >>> radio transmitters (120-150 Euro/pcs) and, more importantly, my total lack >>> of experience in building watertight housings. >>> >>> You might be at least the solution to part two of the problem. What do you >>> think? >> >> Nice idea, never thought about such a logger. >> >> Let me first give you an overview about our approach: >> We have an 400bar industry sensor in test. We will connect it to our >> hardware version 0.1 in the next weeks and go diving. >> We made an adapter to connect it to the high pressure hole on the regulator >> and connect it with an M12-Sensor wire to the existing odico housing. >> http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2159.JPG_1997443631.jpg >> It works on the land, but we are not sure if its really watertight, that we >> will see in the dive. >> http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2179.JPG_1997443631.jpg >> >> One option (may be you better say vision ;-) in our project is to use the >> odico electronics to control a rebreather using CANBUS (the controller has >> it build in already) and therefore the high pressure sensor would act as an >> CANBUS node with its own buildin controller, in particular a STMF1x, less >> then 5€ each. The electronics could be sealed with casting resin. >> For our rebreather approach we accept the existence of wires, so we don't >> need to care about energy and communication. The pressure sensors cost about >> 80€, plus the adapter for the high pressure, plus the wiring, but that costs >> are not a big deal to run a rebreather. >> My fellow, Marco, also doesn't care to much building even an self made >> pressure sensor with build in electronics . He has a degree as mechanical >> engineer and he's really gifted for job! >> So we don't care too much to get it water tight. >> >> From my point of view a logger could be designed like this: >> - located at the high pressure hole of the first stage >> - length about 5 - 10 cm, cylindrical >> - collecting data for pressure + time >> - as an option: collection depth+temp >> - energy by an AAA or 1/2 AA lithium 3v cell than could be replaced once a >> year >> - communication via radio (bluetooth, ...) >> - shop price < 200 € >> >> Again, I never thought that would be worth to think about it. I will discuss >> with Marco! >> If you like we can discuss more. >> > > I would be interested in such a device, even if they would be built as > one off jobs. > > > Only thing i would argue is really important is to make sure they fail > in a sane manner, and doesn't leak or dump my gas. It seems there's at least some interest in such a device but to get a retail price below 200 € one needs to produce/sell more then a couple... I also doubt a kickstarter project will help here :( Maybe the only option would be to design such a device in the public... I have some contacts to a pressure sensor company and a university, maybe that's a nice student project... > Now this one is seriously OT but a idea i hand a couple of mates had as > a idea, a depth/time logger with a accelerometer/gyro and try to use that > as a mapping device to try to figure out how your movements under water > actually where. > > I talked with another mate who's in the defense industry and they have > such devices on there (semi)autonomous rovs, but they combine the > accelerometer/gyro with sonar and doppler radar against its surroundings > for more input to their odometry models. > > > That would be really cool =) Personally I doubt you get the needed accura
Re: How to reduce row height in table print
On Thu, Mar 19, 2015 at 10:07 AM, Lubomir I. Ivanov wrote: > On 19 March 2015 at 01:28, Lutz Vieweg wrote: > > Hi, > > > > I would like to print more dives per page in "table" mode, > > just reducing the number sr=4 in > >> > >> const int sr = 12; // smallest row height in pixels > >> profilePrintRowHeights.append(sr); > > > > that's for the table in profile print. > > > does not help, even if also reducing the model.setFontsize(). > > > > Is there some easy way to tell subsurface to not put that much > > margin above/below the table row texts? > > > > that's a good question and i quickly experimented with some code to > try to answer it. > nothing works for me: CSS, Qt::SizeHintRole, explicit row heights, etc. > thus, i don't have an answer ATM, so please wait for the print layout > rework which is coming in the next few months. > > in the meantime if someone has a better idea why QTableView is so > stubborn, you can give this a try. > you need to create a new QStyledItemDelegate with a different width and pass it to QTableView it's not hard to do, there are lots of different delegates written for subsurface. the easier to change is the StarDelegate - just remove the paint method and add the sizeHint methods. > > lubomir > -- > ___ > 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] [datatrak.c] Add support for divemode if dive is SCR
Not necesary for OC as this is the default.
Signed-off-by: Salvador Cuñat
---
datatrak.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/datatrak.c b/datatrak.c
index fc46ff4..2544eed 100644
--- a/datatrak.c
+++ b/datatrak.c
@@ -404,6 +404,7 @@ static struct dive dt_dive_parser(FILE *archivo, struct
dive *dt_dive)
if (byte[1] != 0) {
taglist_add_tag(&dt_dive->tag_list, strdup("rebreather"));
is_SCR = 1;
+ dt_dive->dc.divemode = PSCR;
}
/*
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] [datatrak.c] Avoid duplicities on dive sites while importing
Instead of create an uuid for every imported dive, check if it exists. If not create a new one. Signed-off-by: Salvador Cuñat --- datatrak.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/datatrak.c b/datatrak.c index 2544eed..573796c 100644 --- a/datatrak.c +++ b/datatrak.c @@ -217,7 +217,9 @@ static struct dive dt_dive_parser(FILE *archivo, struct dive *dt_dive) * Locality and Dive points. */ snprintf(buffer, sizeof(buffer), "%s, %s", locality, dive_point); - dt_dive->dive_site_uuid = create_dive_site(buffer); + dt_dive->dive_site_uuid = get_dive_site_uuid_by_name(buffer, NULL); + if (dt_dive->dive_site_uuid == 0) + dt_dive->dive_site_uuid = create_dive_site(buffer); free(locality); free(dive_point); -- 2.1.4 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
HighPressureLogger, Odometer/ Re: Which protocol to implement on a home brewed diving computer ?
Martin, Anton, Am 19.03.2015 um 15:01 schrieb Martin Gysel: Am 19.03.2015 um 14:14 schrieb Anton Lundin: On 17 March, 2015 - Thomas Schrein (mailinglists) wrote: . . . I would be interested in such a device, even if they would be built as one off jobs. Only thing i would argue is really important is to make sure they fail in a sane manner, and doesn't leak or dump my gas. Doesn't matter, I have 2 bottles ;-) No, joking aside: you are right, it has to be reliable! But I don't see a big deal with that, just copy proven concepts. It seems there's at least some interest in such a device but to get a retail price below 200 € one needs to produce/sell more then a couple... I also doubt a kickstarter project will help here :( Making only a few parts is a funny hobby, making a lot parts is a funny business, both is worth to think about :-)) Maybe the only option would be to design such a device in the public... I have some contacts to a pressure sensor company and a university, maybe that's a nice student project... You need to know about the mechanical aspects+electronic+diving; don't think a students project is the right way, but may be I am wrong. I discussed yesterday with my friend Marco, the mechanical chap in out team; he did not see too much problems building such a device, our problem is the lack of time, because we want to concentrate on the progress developing odico. But let's discuss about the features of such a logger; may be we have a time gap during the next month and we can build some parts, in particular because we planned to have a high pressure Sensor as CANbus node. About the sensor: as a first idea we found this: http://www.amsys.info/sheets/amsys.en.me501_d.e.pdf May you have an other sensor from the sensor company ? Now this one is seriously OT but a idea i hand a couple of mates had as a idea, a depth/time logger with a accelerometer/gyro and try to use that as a mapping device to try to figure out how your movements under water actually where. I talked with another mate who's in the defense industry and they have such devices on there (semi)autonomous rovs, but they combine the accelerometer/gyro with sonar and doppler radar against its surroundings for more input to their odometry models. That would be really cool =) Personally I doubt you get the needed accuracy by only using the accelerometer and gyro... but you could also couple it with some buoys which sends a ultrasonic beacon on which you can triangulate (like gps) /martin That's an other story ... By the way: you don't need a gyro, a 3-axis compass (+ accelerometer) is enough. I also saw some activities in the mil section .. and I agree, not so easy to get the needed accuracy. If we have odico build up stable, we can modify/add some parts and go for a trial. /Tom ___ 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: [PATCH] Fix a couple of typos
Clean, simple patch. Thanks /D On Thu, Mar 19, 2015 at 01:32:43PM +0100, Torstein Husebø wrote: > Signed-off-by: Torstein Husebø > --- > libdivecomputer.c| 2 +- > qt-ui/mainwindow.cpp | 2 +- > qt-ui/modeldelegates.cpp | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC 2015] Project proposal
Hi there, I just finished my proposal. It would be very useful if you can give me some feedback. The application can be found on [1] link. I didn't write it in this e-mail because I was afraid that it will lose the format. Thanks in advance, Claudiu [1] - https://docs.google.com/document/d/10RBySMv4BgzaA9SjHdgLGGtsvt4okFTAUHQnPfvS0cg/edit?usp=sharing ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt Bluetooth in 5.5
On Thu, Mar 19, 2015 at 03:23:28PM +0200, Lubomir I. Ivanov wrote: > On 18 March 2015 at 05:48, Dirk Hohndel wrote: > > > > Thiago, > > > > would Subsurface benefit from using Qt Bluetooth for our intended Bluetooth > > integration? > > This would cause some interesting architectural challenges with > > libdivecomputer (as that most definitely doesn’t want to depend on Qt), but > > I find it very intriguing that Qt now supports all of the platforms we are > > interested in… or am I missing something here? > > > > i can see that libDC has a parser API exposed, but i don't know if / > how does that works, but if Subsurface uses Qt's BT it can in theory > just use libDC as a parser (Thiago mentioned the same). > > i think it would be better for the student to first help Jeff get the > BT working in libDC for Win32 and Linux and then start working on the > Subsurface side. > but...if the OSX code is not going to be donated soon (or maintained > well in that aspect), i suggest we just use Qt's BT. My thinking was to have the student look at QtBt and figure out if that would be sufficient. If it is, then we'll use that and connect to the parser ourselves. Otherwise back to plan A :-) > there is also the option for libDC to expose API to allow the libDC > user to specify the BT backend (e.g.. built-in VS external C-wrapped > Qt BT), but that's probably a ton of extra work for Jeff. Jef and I talked briefly about the options we have for BT. The last thing I want to do is to create a ton of extra work for him... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] uemis-downloader - resource leak
Hi,
I noticed that some resources are not being freed in 'uemis-downloader.c' -
please, see attached patch...
All the best,
Marcos
From ec63d6c78c17f26220c5571fddf7c9c4e49b53e0 Mon Sep 17 00:00:00 2001
From: Marcos CARDINOT
Date: Thu, 19 Mar 2015 16:32:31 -0300
Subject: [PATCH] uemis-downloader - resource leaks
Some resources are not being freed.
Signed-off-by: Marcos CARDINOT
---
uemis-downloader.c |9 +
1 file changed, 9 insertions(+)
diff --git a/uemis-downloader.c b/uemis-downloader.c
index b9ea57b..7b5a93a 100644
--- a/uemis-downloader.c
+++ b/uemis-downloader.c
@@ -718,6 +718,8 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
/* is it a valid entry or nothing ? */
if (strcmp(tp, "1.0") != 0 || strstr(inbuf, "divelog{1.0")) {
free(buf);
+ free(tp);
+ free(bp);
return false;
}
} else if (strcmp(tp, "dive") == 0) {
@@ -725,11 +727,15 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
tp = next_token(&bp);
if (strcmp(tp, "1.0") != 0) {
free(buf);
+ free(tp);
+ free(bp);
return false;
}
} else {
/* don't understand the buffer */
free(buf);
+ free(bp);
+ free(tp);
return false;
}
if (log) {
@@ -742,6 +748,9 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
fprintf(debugfile, "p_r_b entry deleted\n");
#endif
/* oops, this one isn't valid, suggest to try the previous one */
+ free(buf);
+ free(bp);
+ free(tp);
return false;
}
}
--
1.7.9.5
From ec63d6c78c17f26220c5571fddf7c9c4e49b53e0 Mon Sep 17 00:00:00 2001
From: Marcos CARDINOT
Date: Thu, 19 Mar 2015 16:32:31 -0300
Subject: [PATCH] uemis-downloader - resource leaks
Some resources are not being freed.
Signed-off-by: Marcos CARDINOT
---
uemis-downloader.c |9 +
1 file changed, 9 insertions(+)
diff --git a/uemis-downloader.c b/uemis-downloader.c
index b9ea57b..7b5a93a 100644
--- a/uemis-downloader.c
+++ b/uemis-downloader.c
@@ -718,6 +718,8 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
/* is it a valid entry or nothing ? */
if (strcmp(tp, "1.0") != 0 || strstr(inbuf, "divelog{1.0")) {
free(buf);
+ free(tp);
+ free(bp);
return false;
}
} else if (strcmp(tp, "dive") == 0) {
@@ -725,11 +727,15 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
tp = next_token(&bp);
if (strcmp(tp, "1.0") != 0) {
free(buf);
+ free(tp);
+ free(bp);
return false;
}
} else {
/* don't understand the buffer */
free(buf);
+ free(bp);
+ free(tp);
return false;
}
if (log) {
@@ -742,6 +748,9 @@ static bool process_raw_buffer(device_data_t *devdata, uint32_t deviceid, char *
fprintf(debugfile, "p_r_b entry deleted\n");
#endif
/* oops, this one isn't valid, suggest to try the previous one */
+ free(buf);
+ free(bp);
+ free(tp);
return false;
}
}
--
1.7.9.5
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] uemis-downloader - typo?
Hi, Please, see attached patch... Is there any reason to change the order of these arguments? typo? All the best, Marcos From b04b2a168c08002ddc7058da8b968a74dd73afdd Mon Sep 17 00:00:00 2001 From: Marcos CARDINOT Date: Thu, 19 Mar 2015 17:20:03 -0300 Subject: [PATCH] uemis-downloader - arguments in wrong order method's signature: void uemis_set_divelocation(int divespot, char *text, double longitude, double latitude) Signed-off-by: Marcos CARDINOT --- uemis-downloader.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/uemis-downloader.c b/uemis-downloader.c index b9ea57b..b2d2583 100644 --- a/uemis-downloader.c +++ b/uemis-downloader.c @@ -635,7 +635,7 @@ static void parse_divespot(char *buf) latitude = ascii_strtod(val, NULL); } } while (tag && *tag); - uemis_set_divelocation(divespot, locationstring, latitude, longitude); + uemis_set_divelocation(divespot, locationstring, longitude, latitude); } static void track_divespot(char *val, int diveid, uint32_t dive_site_uuid) -- 1.7.9.5 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] uemis-downloader - typo?
Jikes. Goes to show that no one sane would ever enter a GPS location on the Uemis SDA... Thanks for the patches. Both look good (even the one you sent twice) :-) /D On Thu, Mar 19, 2015 at 05:32:41PM -0300, Marcos Cardinot wrote: > From b04b2a168c08002ddc7058da8b968a74dd73afdd Mon Sep 17 00:00:00 2001 > From: Marcos CARDINOT > Date: Thu, 19 Mar 2015 17:20:03 -0300 > Subject: [PATCH] uemis-downloader - arguments in wrong order > > method's signature: void uemis_set_divelocation(int divespot, char *text, > double longitude, double latitude) > > Signed-off-by: Marcos CARDINOT > --- > uemis-downloader.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/uemis-downloader.c b/uemis-downloader.c > index b9ea57b..b2d2583 100644 > --- a/uemis-downloader.c > +++ b/uemis-downloader.c > @@ -635,7 +635,7 @@ static void parse_divespot(char *buf) > latitude = ascii_strtod(val, NULL); > } > } while (tag && *tag); > - uemis_set_divelocation(divespot, locationstring, latitude, longitude); > + uemis_set_divelocation(divespot, locationstring, longitude, latitude); > } > > static void track_divespot(char *val, int diveid, uint32_t dive_site_uuid) > -- > 1.7.9.5 > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: HighPressureLogger, Odometer/ Re: Which protocol to implement on a home brewed diving computer ?
Am 19.03.2015 um 20:09 schrieb Robert C. Helling: > Hi, > > On 19 Mar 2015, at 18:30, Thomas Schrein (mailinglists) > wrote: > >> About the sensor: as a first idea we found >> this:http://www.amsys.info/sheets/amsys.en.me501_d.e.pdf >> May you have an other sensor from the sensor company ? > > Did you see the MSG3500 from the same Swiss manufacturer: > www.servoflo.com/power/download/283/556/17.html > This seems to be specifically for scuba applications already with the correct > port for first stage fitting. > > Too bad I cannot find a dealer/price quote. for low volume, I suggest a sensor with integrated amplifier and temperature compensation like the Serie 23 SY from Keller http://www.keller-druck.ch/home_g/paprod_g/23y_25y_g.asp It may also be available with the correct HP port although no mentioned in the datasheet. /martin ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: How to reduce row height in table print
On 19 March 2015 at 18:12, Tomaz Canabrava wrote: > > > On Thu, Mar 19, 2015 at 10:07 AM, Lubomir I. Ivanov > wrote: >> >> On 19 March 2015 at 01:28, Lutz Vieweg wrote: >> > Hi, >> > >> > I would like to print more dives per page in "table" mode, >> > just reducing the number sr=4 in >> >> >> >> const int sr = 12; // smallest row height in pixels >> >> profilePrintRowHeights.append(sr); >> > >> >> that's for the table in profile print. >> >> > does not help, even if also reducing the model.setFontsize(). >> > >> > Is there some easy way to tell subsurface to not put that much >> > margin above/below the table row texts? >> > >> >> that's a good question and i quickly experimented with some code to >> try to answer it. >> nothing works for me: CSS, Qt::SizeHintRole, explicit row heights, etc. >> thus, i don't have an answer ATM, so please wait for the print layout >> rework which is coming in the next few months. >> >> in the meantime if someone has a better idea why QTableView is so >> stubborn, you can give this a try. > > > you need to create a new QStyledItemDelegate with a different width and pass > it to QTableView > it's not hard to do, there are lots of different delegates written for > subsurface. > the easier to change is the StarDelegate - just remove the paint method and > add the sizeHint methods. > doesn't work, the sizeHint() of the delegate is not called. google shows this and another similar thread: https://forum.qt.io/topic/5624/solved-my-overloaded-qstyleditemdelegate-sizehint-is-not-called/4 but we have this by default, anyhow: table.verticalHeader()->setResizeMode(QHeaderView::ResizeToContents); calling table.resizeRowsToContents() explicitly at any point does not help, either. table.setContentsMargins(...), also doesn't work. there is probably some weird undocumented concurrency of settings. we should instead focus on the new functionality to come... lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] [datatrak.c] Improve error management
Show error messages in main window, instead of stdout.
Use translated strings.
Remove redundant error message.
Signed-off-by: Salvador Cuñat
---
datatrak.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/datatrak.c b/datatrak.c
index 573796c..7357b05 100644
--- a/datatrak.c
+++ b/datatrak.c
@@ -140,7 +140,7 @@ static dtrakheader read_file_header(FILE *archivo)
fread(lector, 1, headerbytes, archivo);
if (two_bytes_to_int(lector[0], lector[1]) != 0xA100) {
- puts("Error: the file does not appear to be a DATATRAK
divelog");
+ report_error(translate("gettextFromC", "Error: the file does
not appear to be a DATATRAK divelog"));
return fileheader;
}
fileheader.header = (lector[0] << 8) + lector[1];
@@ -652,7 +652,7 @@ void datatrak_import(const char *file, struct dive_table
*table)
int i = 0;
if ((archivo = subsurface_fopen(file, "rb")) == NULL) {
- puts("Error: couldn't open the file");
+ report_error(translate("gettextFromC", "Error: couldn't open
the file %s"), file);
return;
}
@@ -660,14 +660,11 @@ void datatrak_import(const char *file, struct dive_table
*table)
* Verify fileheader, get number of dives in datatrak divelog
*/
*fileheader = read_file_header(archivo);
-
- if (fileheader->header == 0)
- puts("Error: not a DATATRAK/WLOG file\n");
while (i < fileheader->divesNum) {
struct dive *ptdive = alloc_dive();
*ptdive = dt_dive_parser(archivo, ptdive);
if (!ptdive)
- puts("Error: no dive\n");
+ report_error(translate("gettextFromC", "Error: no
dive"));
i++;
record_dive(ptdive);
}
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 18 March 2015 at 23:22, Gehad Elrobey wrote: > Hello Lubomir, > > I am attaching a draft of my proposal in pdf format, Please review it. > your feedback is most welcome :) Gehad, your application is very well formed. other students can take this into account when they write their own applications. here are some entry level notes and questions that will emphasize on eventual topics of interest for the *actual* user base. > Pre Existing layouts technical information > ● Supported Paper size : A4 – A5 > ● Supported Quality : 300 dpi > ● Supported Orientation : Portrait we need to extract settings from the QPrinterDialog and from the user configuration QSettings and adjust the CSS ".media" related sections before the pagination. i'm pretty sure this is doable. > III. Design solid ideas. we may have to adjust the naming of the classes slightly (e.g. just Printer instead of CustomPrinter), but we also have to consider the support for social networks, related class names and to plan the class inheritance. > Grantlee templates > This are the preexisting templates that can be used directly. yes, keeping the current templates is nice. > Figure(3.1) Printing block diagram the graph looks good. if can you visualize what i mean by the above comment about QPrinterDialog, basically the CSS / HTML will be fed (e.g. with search-and-replace amends) with stored settings in the user configuration (from QSettings) and also with on-the-spot configuration such as margins, orientation etc. from the QPrinterDialog, then QPrinter will receive the rendered result as a paint device. > Rendering the QWebView will take place by scrolling the QPainter viewport > over the > whole content as shown in Figure(3.2) hmm, when i experimented with a paginated CSS template there was no need to scroll the viewport and QWebView simply, magically paginated my pages with render(). i may be missing something, but if you think that the viewport rendering is better i'm glad to hear why? > The proposed new dialog figure(3.4) nice, in general this is the idea about the new dialog. user suggestions are welcome about this one. > Template options the 3 tabs cover what is required pretty much. how do you plan to generate the previews BTW e.g. QWebView rendering some sort of default contents on a QPixmap that is placed in the dialog? user suggestions are welcome about the layout and functionality listing of the dialog. > General > user can choose paper size, printing quality, margin size. all of these seem fine to be on the rendered side (e.g. Chrome has them), but if the user chooses something from the printer dialog (lower level - read closer to the OS and hardware) we may have to override some of them with or without notification. > Style > user can control the font, font size, and colors. > random color generator can be included. nice. users will surely voice about more things in here. we should keep this tab's contents to a minimum at first, but best would be to consider a QScrollArea, just in case, as the CSS flexibility will open more feature requests. there are two options here. the contents of this tab: 1) should make sense for any possible template. 2) will update based on what is copy-pasted in the next tab option 1) is much easier as we don't have to deal with the dynamic creation of Qt UI. we may have to discuss this further. but i would say, consider 1) for now... > Template > this will add the ability to change the source code of the template, this > will provide very > advanced customization and the ability to change where and how does the data > appear. an "update" button will be needed to re-visualize the theme in the preview. > 1 dive per page > 2 dives per page > 4 dives per page > Flow layout > Column flow layout i'm sure "Flow layout" and "Column flow layout" will be good examples for what is possible with the new template stack. > A. Milestones > B. Timeline it's up to you how you are going to plan your work. here is how i will proceed, but i don't want to change your planned workflow much: i would start by cleaning absolutely *all* details on the UI part, which is usually the most demanding and pretentious part - i.e. there are users involved :-). then, i would sit for a while and think of how i'm going to organize all the functionality in terms of code, naming, classes, inter-module communication and so on. (keep in mind we also have to safely remove the current printer related classes). starting with Grantlee backend seems about right. i would feed it with some basic templates, until the QWebView renderer part is done. only at that point i would start implementing some of the templates and the UI changes. > VII. Documentation > A. User-Manual > I ll document the new printing features in the user manual. > B. Online tutorial > I will write an online tutorial (may be on subsurfacedivelog.org ) to > describe > how to create a new template and use it with subsurface printing module from > scratch
GSoC 2015 - Introduction
Hi everyone, Firstly, I would like to introduce myself... I'm a computer engineer and a physics student who wishes to apply for GSoC this year. In order to get familiar with the source code, I have been studying it and working on some bugs. I've sent four patches so far... so, it means that I've read the 'contribution guidelines', compiled and ran subsurface from source successfully =D There are two projects for which I would be very pleased to apply: 'Unit testing' and 'Asset management'. It seems that the mentors are not assigned yet (?) Please, let me know if I'm wrong, in this case, it would be nice to know who are the potential mentors for each of these projects. =D I also have a couple of initial questions about them... *- Unit testing* I saw that there are a few tests implemented using the Qt Test framework. However, I would suggest using the Google Test Framework. It is far more sophisticated and featureful unit testing framework, especially if we use it with Google Mock. Is there any objection against the use of this framework? should I consider another one? Of course, the QtTest has some good features to test basic GUI events and we could use it for this purpose. Is there a plan to test the GUI in this project as well? in this case, what about using something like Sikuli [1]? *- Asset Management* The main concept of this project is very clear[2], but as I'm not a diver, I really appreciate your help to better understand all the details expected for this project. In this way I would have more knowledge to think about the data structure. Do you recommend any specific documentation/software which would give me ideas about what would be expected from the user point of view (I mean, assets)? Would you expect to have the data being stored in the same log file (xml)? Do you expect to have it placed as a new view or a new dialog? - Any of these projects have a higher priority? I think that the answer for this one will be 'NO' - but, as I'm considering these two projects, it would be awesome to hear from the community which one would make more people happy! =D All the best, Marcos Cardinot [1] www.sikuli.org [2] http://trac.subsurface-divelog.org/wiki/Subsurface_GSOC_2015_Idea_List#Assetmanagement ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC 2015 - Introduction
Oh, I forgot to mention - I'm 'cardinot' in #subsurface 2015-03-19 22:27 GMT-03:00 Marcos Cardinot : > Hi everyone, > > Firstly, I would like to introduce myself... > I'm a computer engineer and a physics student who wishes to apply for GSoC > this year. > > In order to get familiar with the source code, I have been studying it and > working on some bugs. > I've sent four patches so far... so, it means that I've read the > 'contribution guidelines', compiled and ran subsurface from source > successfully =D > > There are two projects for which I would be very pleased to apply: 'Unit > testing' and 'Asset management'. > It seems that the mentors are not assigned yet (?) Please, let me know if > I'm wrong, in this case, it would be nice to know who are the potential > mentors for each of these projects. =D > I also have a couple of initial questions about them... > > *- Unit testing* > I saw that there are a few tests implemented using the Qt Test framework. > However, I would suggest using the Google Test Framework. It is far more > sophisticated and featureful unit testing framework, especially if we use > it with Google Mock. > > Is there any objection against the use of this framework? should I > consider another one? > > Of course, the QtTest has some good features to test basic GUI events and > we could use it for this purpose. > Is there a plan to test the GUI in this project as well? in this case, > what about using something like Sikuli [1]? > > *- Asset Management* > > The main concept of this project is very clear[2], but as I'm not a diver, > I really appreciate your help to better understand all the details expected > for this project. In this way I would have more knowledge to think about > the data structure. > > Do you recommend any specific documentation/software which would give me > ideas about what would be expected from the user point of view (I mean, > assets)? > > Would you expect to have the data being stored in the same log file (xml)? > > Do you expect to have it placed as a new view or a new dialog? > > - > > Any of these projects have a higher priority? > I think that the answer for this one will be 'NO' - but, as I'm > considering these two projects, it would be awesome to hear from the > community which one would make more people happy! =D > > All the best, > Marcos Cardinot > > [1] www.sikuli.org > [2] > http://trac.subsurface-divelog.org/wiki/Subsurface_GSOC_2015_Idea_List#Assetmanagement > > -- MARCOS CARDINOT ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] critical bug #858 - 'log' -> 're-plan dive' crashes subsurface
Hi,
Regarding to the bug #858:
http://trac.subsurface-divelog.org/ticket/858
Please, see attached patch...
Question, should we print something in this case?
All the best,
Marcos
From 8cf432d8fc7fba53df9d174f37e6de8673dad5a4 Mon Sep 17 00:00:00 2001
From: Marcos CARDINOT
Date: Fri, 20 Mar 2015 01:05:41 -0300
Subject: [PATCH] bugfix #858 - 'log' -> 're-plan dive' crashes subsurface
test case:
1 - make sure that you DO NOT have anything selected on the 'Dive list;
2 - in the menu bar, click on 'Log'->'Re-plan dive';
3 - crash!
Signed-off-by: Marcos CARDINOT
---
qt-ui/mainwindow.cpp |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qt-ui/mainwindow.cpp b/qt-ui/mainwindow.cpp
index 21d36d9..54c0ce7 100644
--- a/qt-ui/mainwindow.cpp
+++ b/qt-ui/mainwindow.cpp
@@ -584,9 +584,9 @@ void MainWindow::setupForAddAndPlan(const char *model)
void MainWindow::on_actionReplanDive_triggered()
{
- if (!plannerStateClean())
+ if (!plannerStateClean() || !current_dive || !current_dive->dc.model)
return;
- if (!current_dive || !current_dive->dc.model || strcmp(current_dive->dc.model, "planned dive")) {
+ else if (strcmp(current_dive->dc.model, "planned dive")) {
qDebug() << "trying to replan a dive that's not a planned dive:" << current_dive->dc.model;
return;
}
--
1.7.9.5
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
