Re: GSoC Status - Week 5 (Customizable prints)
On 29 June 2015 at 05:08, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the list of tasks which I have discussed with Lubomir. Tasks completed so far: - QPrintPreviewDialog triggered from the main dialog nice - add print selected dives support this one doesn't work for me. i have a massive test list of dives and with print selected dives not selected, i expect it to print the entire list, instead it prints only a single page with two dives. - print in colors or gray scale does not work. the profile is still printed in color no matter the print dialog selection. do you simply attempt to greyscale the profile image before rendering on the HTML? note that when Tomaz implemented profile2 we lost the support for greyscale print support. i believe that was in qt-ui/profilegraphics.cpp via the isGreyscale flag. profile2 does not have that, so for now converting the rendered image to greyscale is the fast and simple solution. but using our pre-defined colors via the // Monochromes list in colors.h is nice-to-have. - fix dive profile bugs - fixed two dives per page template on large DPI printers. Tasks in progress: - TemplateEdit with print preview. Tasks I will work on next week: - I will finish the TemplateEdit dialog, and enhance a template to be user ready. sounds about right. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 5 (VPM-B)
Hi, This week I've solved all the remaining problems with the CVA and added ui deco algorithm selection. I've modified the original code so I could test the results. On few tests I run difference was ~1min. It's pretty good as we have completely different saturation calculation implemented. On Friday I've rebased my changes and prepared for merging with master. This week I will write the promised paper about the algorithm and maybe add Boyle's Law compensation. What also needs to be done is optimization of some calculations. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 5 (Android Port)
On Mon, Jun 29, 2015 at 06:01:54AM +0300, Grace Karanja wrote: Hi everyone, This week I was working on: -Saving the dive details to XML This surprises me - maybe I'm not understanding what you are doing there. Can you explain some more? -Loading and saving dives using the cloud back-end. I am currently still working on the back-end part, and I should have the work ready for a PR this week. Again, can you explain what exactly you are doing there? Since AFAIK you are still doing all this on the desktop and not on Android, these shouldn't be problems... on Android I can see issues with libgit2 or other parts of the code that haven't been tested on Android, but on the desktop all of this should be working. Have you discussed the problems with Tomaz? In general, if you are stuck on something you should explain the problem on the mailing list and look for support from other developers /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Claudiu, I've tested your patches, and your work looks great! Tested on Fedora 22, using a Shearwater Petrel 2 and onboard Bluetooth. On 29 June 2015 at 08:33, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: I didn't know that. Thanks for the heads up! In the beginning try to see if it connects to the device using this version. It attempts to make a connection to the Serial Port Profile. Therefore, if the service is listening on RFCOMM channel 5, then it should successfully connect. Before applying the patch, 0005-Use-channel-5-for-Shearwater-Petrel-2-devices, I was able to turn on my laptop's onboard Bluetooth and the scan worked successfully, but unfortunately the connection was not successful. My Petrel 2 had previously been paired. The hcidump output is attached. I've edited out the junk where it detected my TV. If not, please apply the attached patch. This is just a temporary solution :). After applying the patch to connect to channel 5, the connection was successful. Downloading dives worked as expected - every dive was downloaded into a new Subsurface logbook. To test a bit more, I unpaired my dive computer through the KDE Bluetooth system tray thing, and tried to pair it again through the Bluetooth dialog in Subsurface. I have to admit that right-clicking and choosing pair seemed less than intuitive, but it worked flawlessly. I did not need to use bluetoothctl. Downloading dives again 'worked', except there were no new dives after downloading everything previously, so nothing was downloaded. I deleted the few latest dives and tried again. This time it failed, but I think downloading several times in a row without powering off was just too much work for the Petrel (it's happened before and not not a real issue because normally you have no reason to download more than once at a time). I turned the Petrel off then on again. Unpaired through the Subsurface interface (worked), re-paired (worked), downloaded the three most recent dives (worked again). The hcidump output is attached after applying the use channel 5 patch. As you said, the patch to use channel 5 is only a temporary solution, as I'm sure it breaks things for every other dive computer. Unfortunately, the Petrel 2 identifies itself as a Petrel, and I believe the Petrel 1 uses channel 0. E.g. from my hcidump file: HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 00:12:34:56:78:9A name 'Petrel' One way to tell that it wants to use channel 5 from the command line is using sdptool. sdptool -i hci0 records 00:11:22:33:44:55 Service Name: Serial Port Service RecHandle: 0x1 Service Class ID List: Serial Port (0x1101) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Channel: 5 Can you do a similar query through qtbluetooth? Or perhaps try channel zero first (should work for OSTC computers, Shearwater Predator and Petrel v1), if that fails, try channel 5. I'm only aware of dive computers using those two channels, but you could try brute force after that. As further testing, I also tried using the Bluetooth dongle that came with the Petrel 2. The dialog in Subsurface only recognized the onboard Bluetooth device, i.e. hci0, even when I used hciconfig to turn hci0 off and hci1 on. I'm guessing you know this. Cheers, Rick HCI sniffer - Bluetooth packet analyzer ver 5.29 device: hci0 snap_len: 1500 filter: 0x HCI Event: Command Complete (0x0e) plen 4 Reset (0x03|0x0003) ncmd 1 status 0x00 HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Features (0x04|0x0003) ncmd 1 status 0x00 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83 HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 status 0x00 HCI Version: 2.1 (0x4) HCI Revision: 0x50eb LMP Version: 2.1 (0x4) LMP Subversion: 0x420e Manufacturer: Broadcom Corporation (15) HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 1 status 0x00 bdaddr 00:AB:CD:EF:12:34 HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 1 status 0x00 ACL MTU 1021:8 SCO MTU 64:1 HCI Event: Command Complete (0x0e) plen 7 Read Class of Device (0x03|0x0023) ncmd 1 status 0x00 class 0x00 HCI Event: Command Complete (0x0e) plen 252 Read Local Name (0x03|0x0014) ncmd 1 status 0x00 name 'BCM2046B1 Bluetooth Device' HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 1 status 0x00 voice setting 0x0060 HCI Event: Command Complete (0x0e) plen 5 Read Number of Supported IAC (0x03|0x0038) ncmd 1 HCI Event: Command Complete (0x0e) plen 8 Read Current IAC LAP (0x03|0x0039) ncmd 1 IAC 0x9e8b33 (General Inquiry Access Code) HCI Event: Command Complete (0x0e) plen 4 Set Event Filter (0x03|0x0005) ncmd 1 status 0x00 HCI Event: Command Complete (0x0e) plen 4 Write Connection
Re: GSoC Status - Week 5 (Android Port)
On Mon, Jun 29, 2015 at 5:02 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jun 29, 2015 at 06:01:54AM +0300, Grace Karanja wrote: Hi everyone, This week I was working on: -Saving the dive details to XML This surprises me - maybe I'm not understanding what you are doing there. Can you explain some more? Sorry I was not clear... Since I had already begun the feature of opening local XML files, I had to finish working on editing and saving the dive details back to the file. -Loading and saving dives using the cloud back-end. I am currently still working on the back-end part, and I should have the work ready for a PR this week. Again, can you explain what exactly you are doing there? Since AFAIK you are still doing all this on the desktop and not on Android, these shouldn't be problems... on Android I can see issues with libgit2 or other parts of the code that haven't been tested on Android, Yes we haven't tested all these on Android. Have you discussed the problems with Tomaz? In general, if you are stuck on something you should explain the problem on the mailing list and look for support from other developers My idea was to first come up with a working QML ui that, at the very least, load the remote dives and save back the changes. /D -- -- Grace K ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] libdivecomputer - custom implementation for serial communication
On 2015-06-26 01:33, Claudiu Olteanu wrote:
I attached some patches which can be used to make the *libdivecomputer
*
project to accept callbacks to custom functions used for serial
communication.
As I mentioned in my weekly report, I am not sure if I made the best
decisions on the implementation.
I didn't have time yet to go through all the bluetooth related emails
and do a detailed review of your work so far. Instead, I'll describe the
architectural changes that I had already planned for integrating my
bluetooth prototype. Conceptually there is really no difference with the
changes that are needed for your custom I/O backend.
There are three main steps:
1. Abstract serial interface
The very first step will be to change the serial communication layer
from a concrete implementation into a abstract interface. This will be
very similar to how the device and parser layer work. So if you wonder
how something should be done, just replace serial with device or
parser and look how it's done there.
We'll need three files here:
* include/libdivecomputer/serial.h
* src/serial-private.h
* src/serial.c
The first one is the public interface. This is basically the existing
src/serial.h file, but everything gets an extra dc_ prefix. There is
no need for the dc_serial_open() function, because each backend will
have to implement its own, and may need completely different parameters.
(If you're familiar with C++, a virtual constructor is not possible.)
(Note that the serial api will need some additional rework too in order
to become public, but let's ignore that for now.)
In the serial-private.h file, you define the base structure that is
shared by all implementations:
struct dc_serial_t {
const dc_serial_vtable_t *vtable;
dc_context_t *context;
};
and the virtual function table containing one function pointer for each
public method:
struct dc_serial_vtable_t {
int (*close) (dc_serial_t *serial);
...
};
In the serial.c file, you implement each function by calling the
corresponding function in the vtable.
Next, we need to modify the existing serial code, and turn it into an
implementation of our new interface. To do this, you add the new
dc_serial_t struct as the first member of the existing struct:
struct serial_t {
dc_serial_t base;
...
};
And setup a vtable:
static const dc_serial_vtable_t serial_vtable = {
serial_close, /* close */
...
};
Of course you'll need a bit more glue code here and there, but I think
you get the idea. If not, just ask.
Last but not least, you replace all serial_xxx calls with dc_serial_xxx
calls in the entire codebase.
At this point there should be no functional changes (e.g. everything is
still working as before), but we now have the necessary infrastructure
for implementing a custom serial I/O layer.
2. Custom serial backend
This will be very similar to the native backend. The public part should
contain a structure with the callback functions:
typedef struct dc_custom_serial_operations_t {
int (*close) (void *userdata);
...
} dc_custom_serial_operations_t;
Notice how I'm passing a void pointer here! The internals of the custom
backend are not exposed to the application! Instead we pass a userdata
cookie that needs to be supplied by the application in the custom open
function:
int
dc_custom_serial_open (dc_serial_t **out, dc_context_t *context, const
dc_serial_operations_t *ops, void *userdata);
And in the private implementation part:
struct dc_custom_serial_t {
dc_serial_t base;
const dc_custom_serial_operations_t *ops;
void *userdata;
};
static const dc_serial_vtable_t custom_serial_vtable = {
custom_serial_close, /* close */
...
};
static int
custom_serial_close(dc_serial_t *serial)
{
return serial-ops-close(serial-userdata);
}
At this point, the application can already create a custom I/O backend,
but libdivecomputer won't be able to use it yet, because it's still
hardcoded to use the native backend.
3. Modify the dc_device_open() function
The last remaining step is to replace the last const char *name
parameter of the dc_device_open() function with a dc_serial_t *serial
parameter. Of course this will also need similar changes to all dive
computer backends.
(To take into account irda and usb communication, we may actually need a
void* parameter here, so we can also pass a dc_irda_t parameter in the
future. Or we need to introduce a more generic I/O abstraction layer.
For example something like a dc_stream_t object, which can abstract both
serial and irda communication.)
This is a relative small change, but it does affect the application
side. So we'll have to decide how we're going to deal with this: modify
the existing function and break backwards compatibility, or add another
dc_device_open2() function and keep the old one around for a while?
(Note that after v0.5 backwards compatibility will get broken anyway,
because I want
Re: GSoC Status - Week 5 (Android Port)
On Mon, Jun 29, 2015 at 05:49:53PM +0300, Grace Karanja wrote: On Mon, Jun 29, 2015 at 5:02 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jun 29, 2015 at 06:01:54AM +0300, Grace Karanja wrote: Hi everyone, This week I was working on: -Saving the dive details to XML This surprises me - maybe I'm not understanding what you are doing there. Can you explain some more? Sorry I was not clear... Since I had already begun the feature of opening local XML files, I had to finish working on editing and saving the dive details back to the file. To be honest, I disagree. I find reading / writing local XML files pointless on Android (and even if it wasn't, I don't see what part of this would require special code for Android - unless you are talking about the UI to create file select boxes... which is exactly the thing I DON'T want the regular user exposed to). -Loading and saving dives using the cloud back-end. I am currently still working on the back-end part, and I should have the work ready for a PR this week. Again, can you explain what exactly you are doing there? Since AFAIK you are still doing all this on the desktop and not on Android, these shouldn't be problems... on Android I can see issues with libgit2 or other parts of the code that haven't been tested on Android, Yes we haven't tested all these on Android. Read my question: Again, can you explain what exactly you are doing there? Would you, please? Have you discussed the problems with Tomaz? In general, if you are stuck on something you should explain the problem on the mailing list and look for support from other developers My idea was to first come up with a working QML ui that, at the very least, load the remote dives and save back the changes. That's a worthwhile goal. I'm not quite sure how that takes a week and still isn't finished. Grace, I don't know how much time you spent on Subsurface last week. Things happen, people get distracted, but what you have explained so far doesn't match what I think a student should be able to work on in a week. It's possible you got stuck somewhere (I get stuck all the time), but then you need to ask for help. Tomaz tells me that you aren't talking to him, either. GSoC is about teaching students to work in open source projects. And as you know, this week is midterm which means we need to make the determination if you are progressing as expected and if we feel that you are likely to complete the project as envisioned. A big part of working in open source is communication. I'd argue it's the biggest part. You see all these discussions on the mailing list. Some calm requests for help, some frustrated about things not working as they should, some heated discussions where people just don't agree. That's how open source progresses. That's how we figure out what to do (and if you had talked to me and Tomaz about the XML saving you would have learned that that's NOT something you should have been working on). And that's how we figure stuff out that we can't quite get to work by ourselves. So please a) talk to us a LOT more frequently. Here or on IRC b) explain to us (or at least to Tomaz and me) what you will be working on in the next few weeks and let's get clear on where you are relative to your plan Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 5 (Android Port)
I just talked to her about not talking. :( On Mon, Jun 29, 2015, 11:02 Dirk Hohndel d...@hohndel.org wrote: On Mon, Jun 29, 2015 at 06:01:54AM +0300, Grace Karanja wrote: Hi everyone, This week I was working on: -Saving the dive details to XML This surprises me - maybe I'm not understanding what you are doing there. Can you explain some more? -Loading and saving dives using the cloud back-end. I am currently still working on the back-end part, and I should have the work ready for a PR this week. Again, can you explain what exactly you are doing there? Since AFAIK you are still doing all this on the desktop and not on Android, these shouldn't be problems... on Android I can see issues with libgit2 or other parts of the code that haven't been tested on Android, but on the desktop all of this should be working. Have you discussed the problems with Tomaz? In general, if you are stuck on something you should explain the problem on the mailing list and look for support from other developers /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
Re: dive site management enhancements (request)
On Tue, Jun 23, 2015 at 11:54:05AM +0200, Davide DB wrote: I agree with Miika that having a gps fix symbol near the dive would be nice. Even on a column in the dive sites list. I implemented that and pushed a change that shows a cute little globe as part of the location field in the the dive list for dives that have GPS data. Is this what you had in mind? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: great progress on dive site handling
On Monday 29 June 2015 06:59:55 Dirk Hohndel wrote: (gdb) bt #0 Marble::StackedTile::pixel (this=0x0, x=36, y=30) at /home/mturkia/source/static/test/marble-source/src/lib/marble/StackedT ile.cpp:85 Hmm. this=0x0 - that would explain the crash when accessing a member of this object. But how the heck did you get there? #1 0x7654036c in Marble::ScanlineTextureMapperContext::pixelValueApprox (this=0x7fff748dbd50, lon=optimized out, lat=optimized out, scanLine=0x240b660, n=optimized out) at /home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineT extureMapperContext.cpp:316 Happens to me quite frequently. Once I have working Internet, I'll try to do full build.sh and see if that helps. If I take this stack trace at face value it really doesn't make much sense. It shouldn't be crashing where it claims to be crashing. It this in StackedTile::pixel really was NULL it should crash in the caller when trying to dereference the member function. Thiago, any brilliant insights? Line 315-316 is: *scanLine = m_tile-pixel( ( ( iPosXf 7 ) + m_vTileStartX ) m_deltaLevel, ( ( iPosYf 7 ) + m_vTileStartY ) m_deltaLevel ); And frame 0 is StackedTile::pixel, so I conclude that m_tile is NULL and StackedTile::pixel is not a virtual function. m_tile had not been used yet in this function, so it's possible it was really null. m_tile is initialised to NULL in the constructor and is only assigned to in ScanlineTextureMapperContext::nextTile (both overloads). I also note that there are a couple places where m_tile is checked for NULL, but not in others. Both cases where m_tile is accessed without checking for null is preceded by a call to isOutOfTileRange. That's all I can tell: I don't know if m_tile is correctly supposed to be NULL there and the code should be checking for validity before dereferencing; or if it wasn't supposed to be NULL and loading of the tile was required. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: dive site management enhancements (request)
+1 (still diving) davide@mobile Il 29/giu/2015 19:59, Dirk Hohndel d...@hohndel.org ha scritto: On Tue, Jun 23, 2015 at 11:54:05AM +0200, Davide DB wrote: I agree with Miika that having a gps fix symbol near the dive would be nice. Even on a column in the dive sites list. I implemented that and pushed a change that shows a cute little globe as part of the location field in the the dive list for dives that have GPS data. Is this what you had in mind? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
I've tested your patches, and your work looks great!
Hi Rick,
First of all, thanks a lot for your help! It helps me a lot to know that
it worked for a device that I didn't have the chance to test personally.
It gives me hope that I am on the right track.
To test a bit more, I unpaired my dive computer through the KDE Bluetooth
system tray thing, and tried to pair it again through the Bluetooth dialog
in Subsurface. I have to admit that right-clicking and choosing pair
seemed less than intuitive, but it worked flawlessly. I did not need to
use bluetoothctl. Downloading dives again 'worked', except there were no
new dives after downloading everything previously, so nothing was
downloaded.
To be honest I don't have too much experience with the UI/UX. I though
that usually when an user wants to execute an action on a specific item,
he just uses the right button click and he selects the action from a
context menu. If you have other suggestions, please let me know.
Can you do a similar query through qtbluetooth? Or perhaps try channel
zero first (should work for OSTC computers, Shearwater Predator and Petrel
v1), if that fails, try channel 5. I'm only aware of dive computers using
those two channels, but you could try brute force after that.
I suspect that this is caused by the timer which after 5 seconds
without a feedback will stop the connecting process. This is just a
speculation but I believe that the device starts to interrogate each
channel (incrementally) and searches for the UUID of the required
service. It is possible that if the Serial Port Profile is available on
channel 5, the connection needs more time to succeeds.
Therefore, do you think that you can apply the attached patch and
try again? First remove the patch number 5 and then apply this one.
This patch increases the timeout from 5 seconds to 20. If the timeout
signal is raised and the device is in lookup service state, then it waits
another 30 seconds. I just want to eliminate this possibility.
As further testing, I also tried using the Bluetooth dongle that came with
the Petrel 2. The dialog in Subsurface only recognized the onboard
Bluetooth device, i.e. hci0, even when I used hciconfig to turn hci0 off
and hci1 on. I'm guessing you know this.
Yes, I am aware of this. The thing is that your onboard Bluetooth
device is set as default. If you set the Bluetooth dongle as default,
then it will be used in the Subsurface dialog. I will make a drop-down
list where the user can select which local Bluetooth device he
wants to use.
Best wishes,
Claudiu
From 47c3787ac376c608737eb56e66601469e2c21bfe Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu olteanu.clau...@ymail.com
Date: Mon, 29 Jun 2015 20:46:32 +0300
Subject: [PATCH 4/4] Increase the waiting time for Bluetooth LookUpSevice
If the lookup for Serial Port profile took more than expected
then wait another 30 seconds.
Signed-off-by: Claudiu Olteanu olteanu.clau...@ymail.com
---
qtserialbluetooth.cpp | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/qtserialbluetooth.cpp b/qtserialbluetooth.cpp
index 329907b..62a 100644
--- a/qtserialbluetooth.cpp
+++ b/qtserialbluetooth.cpp
@@ -4,6 +4,7 @@
#include QtBluetooth/QBluetoothSocket
#include QEventLoop
#include QTimer
+#include QDebug
#include libdivecomputer/custom_serial.h
@@ -43,16 +44,23 @@ static int qt_serial_open(serial_t **out, dc_context_t *context, const char* dev
loop.connect(serial_port-socket, SIGNAL(connected()), SLOT(quit()));
loop.connect(serial_port-socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
- // Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
+ // Create a timer. If the connection doesn't succeed after 20 seconds or no error occurs then stop the opening step
QTimer timer;
timer.setSingleShot(true);
loop.connect(timer, SIGNAL(timeout()), SLOT(quit()));
// Try to connect to the Serial Port Profile service
serial_port-socket-connectToService(QBluetoothAddress(devaddr), QBluetoothUuid::SerialPort);
- timer.start(5000);
+ timer.start(2);
loop.exec();
+ if (serial_port-socket-state() == QBluetoothSocket::ServiceLookupState) {
+ // It seems that the lookup for Serial Port profile took more than expected. Take a beer and wait another 30 seconds :)
+ qDebug() The lookup serice took more than expected. Wait another 30 seconds.;
+ timer.start(3);
+ loop.exec();
+ }
+
if (serial_port-socket-socketDescriptor() == -1 || serial_port-socket-state() != QBluetoothSocket::ConnectedState) {
free (serial_port);
--
2.1.4
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: great progress on dive site handling
On Mon, Jun 29, 2015 at 10:58:57AM -0700, Thiago Macieira wrote: On Monday 29 June 2015 06:59:55 Dirk Hohndel wrote: (gdb) bt #0 Marble::StackedTile::pixel (this=0x0, x=36, y=30) at /home/mturkia/source/static/test/marble-source/src/lib/marble/StackedT ile.cpp:85 Hmm. this=0x0 - that would explain the crash when accessing a member of this object. But how the heck did you get there? #1 0x7654036c in Marble::ScanlineTextureMapperContext::pixelValueApprox (this=0x7fff748dbd50, lon=optimized out, lat=optimized out, scanLine=0x240b660, n=optimized out) at /home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineT extureMapperContext.cpp:316 Happens to me quite frequently. Once I have working Internet, I'll try to do full build.sh and see if that helps. If I take this stack trace at face value it really doesn't make much sense. It shouldn't be crashing where it claims to be crashing. It this in StackedTile::pixel really was NULL it should crash in the caller when trying to dereference the member function. Thiago, any brilliant insights? Line 315-316 is: *scanLine = m_tile-pixel( ( ( iPosXf 7 ) + m_vTileStartX ) m_deltaLevel, ( ( iPosYf 7 ) + m_vTileStartY ) m_deltaLevel ); And frame 0 is StackedTile::pixel, so I conclude that m_tile is NULL and StackedTile::pixel is not a virtual function. m_tile had not been used yet in this function, so it's possible it was really null. m_tile is initialised to NULL in the constructor and is only assigned to in ScanlineTextureMapperContext::nextTile (both overloads). I also note that there are a couple places where m_tile is checked for NULL, but not in others. Both cases where m_tile is accessed without checking for null is preceded by a call to isOutOfTileRange. That's all I can tell: I don't know if m_tile is correctly supposed to be NULL there and the code should be checking for validity before dereferencing; or if it wasn't supposed to be NULL and loading of the tile was required. I have no idea, either. Thanks Thiago for taking a look. It confused me that this would thrown a SIGSEGV in the pixel() function and not when dereferencing m_title to get to the pixel member function... Miika, I pushed a change to our Marble branch that only tries to call pixel() if m_tile is not NULL. Let's see if that fixes your crash. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: great progress on dive site handling
On Monday 29 June 2015 11:07:08 Dirk Hohndel wrote:
Thanks Thiago for taking a look. It confused me that this would thrown a
SIGSEGV in the pixel() function and not when dereferencing m_title to get
to the pixel member function...
It wouldn't because pixel() is not a virtual function.
A non-virtual member function is just a regular function, called by name,
which takes an implicit first parameter that is the object in question.
For
struct Foo { void f(); };
Foo *foo;
The code
foo-f();
is equivalent to
_ZN3Foo1fEv(foo);
There's no pointer dereferencing before the actual call is placed, which is
why it only crashed inside the function, not before it.
To be clear, it's undefined behaviour to do the above on foo = NULL. But UB can
take many forms, including working as expected.
There's some on-going discussion in the C++ standards group to allow the code
f-foo();
to find a free function foo(Foo*) and call that. It's called Unified call
syntax [1] and I actually triggered that discussion about a year and a half
ago after seeing Linus rant here about some quirk of C++ :-)
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: dive site management enhancements (request)
On Mon, Jun 29, 2015 at 09:14:52PM +0200, Davide DB wrote: +1 (still diving) You have email while on a dive? Cool :-) I triggered new daily builds (and found that the libssh2 cmake issue wasn't fully fixed...) so you should be able to test this on Windows... Assuming your internet connection is good enough to download a new build /D Il 29/giu/2015 19:59, Dirk Hohndel d...@hohndel.org ha scritto: On Tue, Jun 23, 2015 at 11:54:05AM +0200, Davide DB wrote: I agree with Miika that having a gps fix symbol near the dive would be nice. Even on a column in the dive sites list. I implemented that and pushed a change that shows a cute little globe as part of the location field in the the dive list for dives that have GPS data. Is this what you had in mind? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
On 30 Jun 2015, at 05:29, Rick Walsh rickmwa...@gmail.com wrote: Hi Claudiu, On 30 June 2015 at 04:37, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: I've tested your patches, and your work looks great! Hi Rick, First of all, thanks a lot for your help! It helps me a lot to know that it worked for a device that I didn't have the chance to test personally. It gives me hope that I am on the right track. It looks to me like you are on the right track. To test a bit more, I unpaired my dive computer through the KDE Bluetooth system tray thing, and tried to pair it again through the Bluetooth dialog in Subsurface. I have to admit that right-clicking and choosing pair seemed less than intuitive, but it worked flawlessly. To be honest I don't have too much experience with the UI/UX. I though that usually when an user wants to execute an action on a specific item, he just uses the right button click and he selects the action from a context menu. If you have other suggestions, please let me know. I'm definitely not a UI designer. Don't lose sleep over what this, because what you have works, which is the main thing. The issue with the the context menu is that it doesn't prompt you if you don't know it's there. I expected there would be a 'pair' button, that is greyed out (or becomes 'unpair') when a paired device is selected. Even better, could you keep the context menu, but allow the user to select a device and exit the dialog with save, whether it's paired on not. If it isn't already paired, then pair at that point. The user doesn't need to understand what pairing is. We have similar need to know ui designs in other places as well. At least the selection of columns on dive list. But I haven't seen this dialog, so don't know how confusing it is. A button might really make sense. Anyway, the UI can be improved once the real functionality is in place. Can you do a similar query through qtbluetooth? Or perhaps try channel zero first (should work for OSTC computers, Shearwater Predator and Petrel v1), if that fails, try channel 5. I'm only aware of dive computers using those two channels, but you could try brute force after that. I suspect that this is caused by the timer which after 5 seconds without a feedback will stop the connecting process. This is just a speculation but I believe that the device starts to interrogate each channel (incrementally) and searches for the UUID of the required service. It is possible that if the Serial Port Profile is available on channel 5, the connection needs more time to succeeds. Therefore, do you think that you can apply the attached patch and try again? First remove the patch number 5 and then apply this one. This patch increases the timeout from 5 seconds to 20. If the timeout signal is raised and the device is in lookup service state, then it waits another 30 seconds. I just want to eliminate this possibility. It doesn't appear to be a timeout issue. Upon selecting download, there's no pause - I immediately get the dialog Unable to connect to xx:xx:xx:xx:xx:xx Shearwater (Petrel). It's exactly the same with or without the 20s timeout patch. In both cases, the display on the Petrel continues its Wait PC 2:10 timer (it counts down from 3:00), which suggests it isn't responding to a failed connection, but is waiting for another attempt (no error message). When a connection is made to channel 5, (either with your previous patch, or with rfcomm), the display changes to Wait CMD, then Sending when downloading starts. I have no idea how qtbluetooth works, and haven't even tried to understand the code, but it appears that on initial failure, we are getting unable to connect, and giving up, rather than trying the next channel. Could you force it to try again with the next channel? Alternatively, create a new dive computer type, Petrel 2, and if that is selected, go straight to channel 5. The problem with this is that it relies on the user knowing their computer is a Petrel 2 - they look the same as the Petrel 1, and are almost the same dive computer - only differences I'm aware of is the new version has a digital compass, and a new Bluetooth chip. This selection would not be a big issue as current serial dl requires that as well. But of course it would be better if user was not bothered with these details. miika___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] VPM-B
Hi, here is the request for the basic vpm algorithm. Right now it doesn't include Boyle's law compensation so the deco plans it generates can be too short in some situations. The following changes since commit f763da66b3db17347954272b9f856df6f8b9888d: Implement planner option to switch only at required stops (2015-06-26 06:14:28 -0700) are available in the git repository at: https://github.com/Slagvi/subsurface.git beta-vpm for you to fetch changes up to 2ce3f0289d446a1b32a932128f1640dc0bc11291: Cleaned up VPM-B work, improved coding style, removed redundant conditions. (2015-06-26 20:47:13 +0200) Jan Darowski (11): Added basic VPM-B deco algorithm settings. Added crushing pressure state and is_vpmb parameter. Added basic crushing pressure calculation, without calculating current radius in the impermeable part. Added simple radius calculation for crushing pressure. Using bin search with const number of iterations. Refactored crushing pressure a little bit. Added simple nuclear regeneration. All the parameters for the deco should be ready. Probably units adjustments needed. Fixed vpmb rs value in nuclear regeneration. VPM-B improvements: Scaled constants Added initial supersaturation calculation Fixed minor calculation bugs VPM-B critical volume algorithm implemented VPM-B CVA fixed. Added ui option to choose deco algorithm. Cleaned up VPM-B work, improved coding style, removed redundant conditions. deco.c | 168 +++ dive.h | 4 + planner.c | 298 - pref.h | 8 +- qt-models/diveplannermodel.cpp | 6 +- qt-models/diveplannermodel.h | 2 +- qt-ui/diveplanner.cpp | 20 ++- qt-ui/diveplanner.h| 2 + qt-ui/plannerSettings.ui | 23 +++- subsurfacestartup.c| 4 +- 10 files changed, 398 insertions(+), 137 deletions(-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] libdivecomputer - custom implementation for serial communication
Hello Jef,
Thanks for making time to let us know what you
have in mind for the next release. More or less it is
similar with the changes I made, except that I tried
to avoid to modify the native serial implementation.
I will make you a short resume about the changes
I did because I believe that there were too many
posts and it is not easy to keep the track.
The dc_serial_t structure is declared as:
struct dc_serial_t {
serial_t *port; //serial device port
dc_transport_t type; //the type of the transport (USB, SERIAL, IRDA,
BLUETOOTH)
void *data; //specific data for serial device
const dc_serial_operations_t *ops; //reference to a custom set of operations
} dc_serial_t;
As you can see, the only difference is that I
added a new member (dc_transport_type).
I thought that this can be used to identify the
type of the transport and to do some specific
operations if they are needed.
Also I used a pointer member for serial_t.
Dirk suggested to remove the pointer but
it was easier for me to use it :).
I choose to represent all functions which are
used for the communication and may need
a custom implementation, depending on the
protocol used (Bluetooth, IRDA, etc).
The dc_serial_operations_t is:
struct dc_serial_operations_t
{
int (*open) (serial_t **device, dc_context_t *context, const char *name);
int (*close) (serial_t *device);
int (*read) (serial_t *device, void* data, unsigned int size);
int (*write) (serial_t *device, const void* data, unsigned int size);
int (*flush) (serial_t *device, int queue);
int (*get_received) (serial_t *device);
int (*get_transmitted) (serial_t *device);
} dc_serial_operations_t;
As I said, I tried to avoid modifications on
native serial implementation. Therefore I used
the same signatures for needed functions.
I preferred to do that because I wanted to keep
backwards compatibility and to do as few changes
as possible. So I created a dc_device_custom_open
method where the application can pass a reference
to a dc_serial_t structure.
Also I added a dc_serial_native_open which
creates a dc_serial_t structure for the
native serial implementation. In this way I could
use it in the DEVICE_FAMILY_device_open
method and maintain the backwards compatibility.
It is obvious that you have a clear idea about
how the libdivecomputer API should look
like and which are the things that need to be
refactored/cleaned.
I would definitely like to help you (now or later).
Dirk, Thiago, do you think that I should refactor
again the libdivecomputer? Should I change
again the design? Or I should continue my current
work, use the current design for all vendors
which have Bluetooth support, implement the
Bluetooth transfer on Windows platforms and finally
start to modify the design as Jef suggested?
I ask this because in the end the Subsurface
custom serial implementation doesn't need
many changes to be integrated with a new
version of libdivecomputer and with its design.
Also, I already have a functional prototype.
I am not sure how to prioritize things. :)
So please let me know what you think.
Thanks,
Claudiu
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families
Hi Claudiu, On 30 June 2015 at 04:37, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: I've tested your patches, and your work looks great! Hi Rick, First of all, thanks a lot for your help! It helps me a lot to know that it worked for a device that I didn't have the chance to test personally. It gives me hope that I am on the right track. It looks to me like you are on the right track. To test a bit more, I unpaired my dive computer through the KDE Bluetooth system tray thing, and tried to pair it again through the Bluetooth dialog in Subsurface. I have to admit that right-clicking and choosing pair seemed less than intuitive, but it worked flawlessly. To be honest I don't have too much experience with the UI/UX. I though that usually when an user wants to execute an action on a specific item, he just uses the right button click and he selects the action from a context menu. If you have other suggestions, please let me know. I'm definitely not a UI designer. Don't lose sleep over what this, because what you have works, which is the main thing. The issue with the the context menu is that it doesn't prompt you if you don't know it's there. I expected there would be a 'pair' button, that is greyed out (or becomes 'unpair') when a paired device is selected. Even better, could you keep the context menu, but allow the user to select a device and exit the dialog with save, whether it's paired on not. If it isn't already paired, then pair at that point. The user doesn't need to understand what pairing is. Can you do a similar query through qtbluetooth? Or perhaps try channel zero first (should work for OSTC computers, Shearwater Predator and Petrel v1), if that fails, try channel 5. I'm only aware of dive computers using those two channels, but you could try brute force after that. I suspect that this is caused by the timer which after 5 seconds without a feedback will stop the connecting process. This is just a speculation but I believe that the device starts to interrogate each channel (incrementally) and searches for the UUID of the required service. It is possible that if the Serial Port Profile is available on channel 5, the connection needs more time to succeeds. Therefore, do you think that you can apply the attached patch and try again? First remove the patch number 5 and then apply this one. This patch increases the timeout from 5 seconds to 20. If the timeout signal is raised and the device is in lookup service state, then it waits another 30 seconds. I just want to eliminate this possibility. It doesn't appear to be a timeout issue. Upon selecting download, there's no pause - I immediately get the dialog Unable to connect to xx:xx:xx:xx:xx:xx Shearwater (Petrel). It's exactly the same with or without the 20s timeout patch. In both cases, the display on the Petrel continues its Wait PC 2:10 timer (it counts down from 3:00), which suggests it isn't responding to a failed connection, but is waiting for another attempt (no error message). When a connection is made to channel 5, (either with your previous patch, or with rfcomm), the display changes to Wait CMD, then Sending when downloading starts. I have no idea how qtbluetooth works, and haven't even tried to understand the code, but it appears that on initial failure, we are getting unable to connect, and giving up, rather than trying the next channel. Could you force it to try again with the next channel? Alternatively, create a new dive computer type, Petrel 2, and if that is selected, go straight to channel 5. The problem with this is that it relies on the user knowing their computer is a Petrel 2 - they look the same as the Petrel 1, and are almost the same dive computer - only differences I'm aware of is the new version has a digital compass, and a new Bluetooth chip. Cheers, Rick HCI sniffer - Bluetooth packet analyzer ver 5.29 btsnoop version: 1 datalink type: 1002 HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 11 bdaddr 00:12:34:56:78:9A type ACL encrypt 0x00 HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 11 Features: 0xbf 0x02 0x24 0x78 0x58 0x1e 0x1a 0x81 HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 11 page 1 max 1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 HCI Event: Command Status (0x0f) plen 4 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1 HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 00:12:34:56:78:9A name 'Petrel' HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00
Re: GSoC Status - Week 5 (Customizable prints)
On 29 June 2015 at 05:08, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the list of tasks which I have discussed with Lubomir. Tasks completed so far: - QPrintPreviewDialog triggered from the main dialog - add print selected dives support - print in colors or gray scale - fix dive profile bugs - fixed two dives per page template on large DPI printers. Tasks in progress: - TemplateEdit with print preview. Tasks I will work on next week: - I will finish the TemplateEdit dialog, and enhance a template to be user ready. good work, i will review the github commits today or tomorrow. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: great progress on dive site handling
On Mon, Jun 29, 2015 at 12:05 AM, Dirk Hohndel d...@hohndel.org wrote:
On Sun, Jun 28, 2015 at 05:27:16PM +0800, Miika Turkia wrote:
With the commit I just pushed the following happens.
IFF you have a dive site that was downloaded from the companion app and
IFF you either type in a new name or you type in an existing dive site
name that has no GPS data,
THEN the GPS data from the downloaded fix will be used and added to the
new dive site that is created (or the existing dive site that didn't have
a GPS fix).
This sounds like sane logic to me. However, I do also see your concern
about this if one only records the site name on that field. I still
type the locations like Indonesia - Lembeh Strait - Hairball so I am
not going to change a Blue Hole in Belize into a Blue Hole in Egypt
(if there are no previous coordinates for the site).
So once you have GPS data we will show the tags that you have chosen
(Country, State, whatever) in the UI. I'm not 100% clear how we should do
this when autocompleting but given the workflow that you and Linus
describe my guess is that we'd update those tags as well as we see and
find a awy to make sure that dive sites with identical names but different
GPS locations are handled in a somewhat sane manner... I can kind of
envision how this would look... Tomaz will love me for this...
I have actually never seen these tags to be added. Now I see that I
need to enable it in the prefs...
So let's say you have three different GPS coordinates for Blue Hole. One
in Belize, two in Palau that are different anchoring spots. As you type
Blue H your autocompletion shows three lines of Blue Hole. As you use
cursor up and down to scroll through them the tags above the location
field change to Belize and Palau, respectively, and the map jumps (not
flies, that's to slow) to the correct marker - this way you can even tell
the different anchor points appart even though you just entered the name.
Which other possible workflow am I still missing with this?
Seems that I get an empty location field on first name edit, and
second edit sticks.
Can you explain the steps that got you to the empty location field?
I tried a few scenarios and can't reproduce that.
This time I was not able to edit the Location without restarting
subsurface. Following steps:
- Download from DC
- Download from second DC
- Sync GPS
- Try to edit locations
I guess I will have to try to remember your workflow, so things will
be easier for me :D
- It would be great if the currently selected divesite was highlighted
somehow on the map, it is really hard to spot it now when the sites
are close to each other, maybe the dive map changed or something to
ensure the correct spot is recognized.
That has been unchanged for a long time. I'll think about something.
Yes, I have suffered from it for years :) Anyway, it is more prominenet
when using the companion app and trying to see where the last dive was..
Changes that implement that have been pushed as well. The current dive now
has a 25% bigger and quite significantly brighter flag.
Just got a crash when trying to test this out.
---8---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff748dc700 (LWP 25410)]
Marble::StackedTile::pixel (this=0x0, x=36, y=30) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/StackedTile.cpp:85
85if ( m_depth == 8 ) {
Are you sure that you are linked against a library that these sources are
from? It seems pretty hard to me to get a SIGSEGV on that line...
(gdb) bt
#0 Marble::StackedTile::pixel (this=0x0, x=36, y=30) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/StackedTile.cpp:85
Hmm. this=0x0 - that would explain the crash when accessing a member of
this object. But how the heck did you get there?
#1 0x7654036c in
Marble::ScanlineTextureMapperContext::pixelValueApprox (this=0x7fff748dbd50,
lon=optimized out, lat=optimized out, scanLine=0x240b660, n=optimized
out)
at
/home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineTextureMapperContext.cpp:316
#2 0x7654196d in
Marble::SphericalScanlineTextureMapper::RenderJob::run (this=optimized
out) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/SphericalScanlineTextureMapper.cpp:271
#3 0x72c25af0 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4 0x72c28b0e in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x769676aa in start_thread (arg=0x7fff748dc700) at
pthread_create.c:333
#6 0x72094eed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No clue. Obviously this worked for me (and I tried jumping around between
dive sites, etc).
Happens to me quite frequently. Once I have working Internet, I'll try
to do full build.sh and see if that helps.
miika
___
Re: GSoC Status - Week 5 (Customizable prints)
On Mon, Jun 29, 2015 at 4:13 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 29 June 2015 at 05:08, Gehad Elrobey gehadelro...@gmail.com wrote: Hello all, This week I was working on the list of tasks which I have discussed with Lubomir. Tasks completed so far: - QPrintPreviewDialog triggered from the main dialog nice - add print selected dives support this one doesn't work for me. i have a massive test list of dives and with print selected dives not selected, i expect it to print the entire list, instead it prints only a single page with two dives. That was working for me before I merged commit 094264014dc47, it seems that amount_selected in display.h is not working as expected, I will look into this and push a commit. - print in colors or gray scale does not work. the profile is still printed in color no matter the print dialog selection. do you simply attempt to greyscale the profile image before rendering on the HTML? I use QPrinter::setColorMode() which selects the color mode for the printer to be RGB or Gray scale, anyway the output in the QPrintPreviewDialog is always in RGB mode, while actual printing using the printer is working correctly for me. note that when Tomaz implemented profile2 we lost the support for greyscale print support. i believe that was in qt-ui/profilegraphics.cpp via the isGreyscale flag. profile2 does not have that, so for now converting the rendered image to greyscale is the fast and simple solution. but using our pre-defined colors via the // Monochromes list in colors.h is nice-to-have. - fix dive profile bugs - fixed two dives per page template on large DPI printers. Tasks in progress: - TemplateEdit with print preview. Tasks I will work on next week: - I will finish the TemplateEdit dialog, and enhance a template to be user ready. sounds about right. lubomir -- -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Feature request - Moving the info pane around the screen?
Hi All, So I've been looking at the graphs with the translucent info pane showing depth, temp, NDL etc. I find it kinda intrusive or obstructive at its current location at the top left corner of the graph pane. It eats into the graph pane when I want to see a full view of the chart. But I still want it always on in the screen. It would be great if a user could drag and drop it somewhere else out of the way like the left pane. For example when the the equipment or dive info tab is selected, the screen is mostly empty unless filled in with some data and dragging it there would be preferable. Alternatively, the info pane could follow the mouse cursor only when it hovers over the slope for depth or tank pressure and toggled on or off quickly with a right click. Yet another option is to provide a button in the middle bar to quickly toggle it on or off. I do appreciate the full screen view of the profile is quite uncluttered, but there are times when one wants to see all the panes and yet view the profile chart uncluttered. What do you folks think? Pardon me if this has been discussed before. -- --G0bbleDeGeek ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
