Re: OSTCTools import support
Hi Anton, i'm on the phone, so expect every kind of sintax errors. El 12/07/2015 20:53, Salvador Cuñat salvador.cu...@gmail.com escribió: Looks like the first byte is a version(?) marker to. 0x64 in the old files in dives/ and 0x65 in the ones posted on the forum. Yes it's correct, but this byte doesn't seem to be related to the software tool but to the data type downloaded from the dc. This way, it happens to be 0x64 for OSTC 2N and 0x65 for OSTC3 (I've dowloaded recent dives with latest release and the files are still marked 0x64 and seem to be just the same structure than older files). You were right and me absolutely wrong because my software wasn't the latest release. Stupid me. 0x65 type uses 3rd, 4th and 5th bytes of the file. 4th and 5th are the device's serial number, while 3rd looks like a marker for the model (2 for my 2N and 3 for OSTC3). The rest of the file seems to have the same structure. In actual situation, we can parse both file types as we use the unchanged data structure, which looks better to me, and will just use the model marker once we get some .dive files from other hwOS models. Regards. Salva. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: build fails: -DSSRF_CUSTOM_SERIAL / dc_serial_t
On 14 July 2015 at 13:02, Lubomir I. Ivanov neolit...@gmail.com wrote: hello, i'm building libdc from the latest: git://subsurface-divelog.org/libdc i've noticed that -DSSRF_CUSTOM_SERIAL is need so that: rc = hw_ostc_parser_create (parser, data-context, data-deviceid, 0); works in libdc_buffer_parser() (libdivecomputer.c) with the extra argument. i understand that this adds some sort of custom serial support, but why don't we have this in the cmake options? adding the definition manually solves the above issue, but now i get a: libdivecomputer.h:58:38: error: 'dc_serial_t' was not declared in this scope there is no such thing, when greping the libdc /include folder. any ideas how to solve the issue? alright, if i don't use -DSSRF_CUSTOM_SERIAL and revert back before 14d95a03ec2d37 (the libdc commit that adds the extra 'frog' argument to hw_ostc_parser_create()) i can build. but i doubt this is the correct solution! lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:20, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). ok, i see. i will test rest of the commits, once i get the build working again. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
build fails: -DSSRF_CUSTOM_SERIAL / dc_serial_t
hello, i'm building libdc from the latest: git://subsurface-divelog.org/libdc i've noticed that -DSSRF_CUSTOM_SERIAL is need so that: rc = hw_ostc_parser_create (parser, data-context, data-deviceid, 0); works in libdc_buffer_parser() (libdivecomputer.c) with the extra argument. i understand that this adds some sort of custom serial support, but why don't we have this in the cmake options? adding the definition manually solves the above issue, but now i get a: libdivecomputer.h:58:38: error: 'dc_serial_t' was not declared in this scope there is no such thing, when greping the libdc /include folder. any ideas how to solve the issue? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote:
On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote:
On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote:
Should I convert the dive profile to QImage during previewing only or
should
I convert it during actual printing also which will affect the printing
quality?
i can't build ATM, but i think the logic here is a bit wrong:
https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673
We must pass a QPaintDevice with type QPixmap for previewing and with
type QPrinter for actual printing.
does that include QPrintPreviewDialog as well? if so that's wrong.
you can use a QPixmap if you are rendering an image to be shown in the
template edit dialog, but the actual QPrintPreviewDialog contents
should be pretty much the same as the printed contents (on a hardcopy
or in a PDF).
No, the preview function is used for the QPixmap in the TemplateEdit only,
while the QPrintPreviewDialog uses the actual print() function.
qt-ui\templateedit.cpp:134:9: warning: enumeration value 'NoButton'
not handled in switch [-Wswitch]
switch (standardButton) {
^
qt-ui\templateedit.cpp:134:9: warning: enumeration value 'Save' not
handled in switch [-Wswitch]
...
more related warnings here
please add a 'default' switch so that these warnings are eliminated.
in general, building with -Wall is a good idea.
reviewing the patches now.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue... 2) print in color doesn't work - always prints in color; i guess you haven't finished the correct to-greyscale conversation yet, as we were discussing it just yesterday 3) i get no text / data in the tables under the profiles. could this be a bug on my end? i see these as important to have before the next pull request. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 14:29, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. never mind, this is a tricky one. i'm just going to leave it be for now, so that users can actually test it from master eventually. can we at least have names for the colors (e.g. Background, Table...etc) instead of color 1, color 2...? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 2:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? The font-size is initialized to 9 in PrintDialog if the QSettingsGroup is not stored, I think the font-size is not initialized because you already had the QSettingsGroup but this specific item was missing as it was not initialized before. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 03:10:30PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. So there are two different UIs here. One is when showing a dive. The other is when editing dive sites. And regardless whether we love the little quick edit or not (that just adds the ability to edit notes and description right from the dive view... I'm not sure it's worth the amount of work that it currently absorbs but Tomaz keeps telling me it's really easy), we need to cover the ability of the user to make changes starting from the dive view, as that is how existing users will use it (and that's certainly how I will use it and Linus will use it). And like it or not, our preferences do matter a bit here. That's why I want to make sure we actually clearly define what happens when the user is looking at a dive and making a change to the dive site. I think your scenarios are good. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. I think much of what we agreed upon was about the dive site management mode. The one that is gone and has not been reimplemented, yet. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. Excellent BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) Yes, if we have another fix within 20m we should show that. Which tells me that if you have GPS data and type something in, not only should we auto-complete on name but we should ALSO list dives that are within 20m (or maybe a little more) of that GPS fix. Which adds a whole list of other cases here, doesn't it? -- I'll keep the use cases 2... existing text in the location field for another email. Good call. I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 13:19, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 14, 2015 12:15 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 00:16, Gehad Elrobey gehadelro...@gmail.com wrote: Should I convert the dive profile to QImage during previewing only or should I convert it during actual printing also which will affect the printing quality? i can't build ATM, but i think the logic here is a bit wrong: https://github.com/Gehadelrobey/subsurface/commit/d5b9e8424f82f4960d44a2f16abda1cbf27d7673 We must pass a QPaintDevice with type QPixmap for previewing and with type QPrinter for actual printing. does that include QPrintPreviewDialog as well? if so that's wrong. you can use a QPixmap if you are rendering an image to be shown in the template edit dialog, but the actual QPrintPreviewDialog contents should be pretty much the same as the printed contents (on a hardcopy or in a PDF). No, the preview function is used for the QPixmap in the TemplateEdit only, while the QPrintPreviewDialog uses the actual print() function. both the preview and print profiles are in vector for me, which is good. also the color and edit seems to be working and the preferred colors are stored (in the settings/registry(win32), apparently). we *might* have to get some user feedback on the colors...i think storing them globally is a bad idea. will create a thread on the ML for that. 1) the per-template vs global colors issue.. Sorry, what do you mean by global colors? do you mean the almond_colors instance of the color struct? . 2) print in color doesn't work - always prints in color; i guess you haven't finished the correct to-greyscale conversation yet, as we were discussing it just yesterday Yes, Print in color works well in the printing mode only and not in the QPrintPreviewDialog, as I didn't implement what we have discussed yesterday yet. 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 15:08, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 2:01 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? The font-size is initialized to 9 in PrintDialog if the QSettingsGroup is not stored, I think the font-size is not initialized because you already had the QSettingsGroup but this specific item was missing as it was not initialized before. yes, that seems to be the case. i've deleted the settings group from the win32 registry and now, after running subsurface the font size is correct (i.e. 9). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. I think your scenarios are good. I'm really sorry for Tomaz. I did not mean to waste his time. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) -- I'll keep the use cases 2... existing text in the location field for another email. Maybe all of them are related to a dive site management scenarios rather than new dive being added. Once we are set with the above cases I can rewrite them from scratch and I will tattoo them on my left cheek :) -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (Customizable prints)
On 14 July 2015 at 14:51, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:46 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:43, Lubomir I. Ivanov neolit...@gmail.com wrote: On 14 July 2015 at 14:38, Gehad Elrobey gehadelro...@gmail.com wrote: 3) i get no text / data in the tables under the profiles. could this be a bug on my end? I am not sure why this happens, it works correctly for me, can you send me the dive you are trying to print? any of the test dives in /dives. screenshot attached. This is so weird, even the static text in the HTML page is not appearing, I tested with the dives in /dives and they worked correctly, I will try to figure out what is happening and update you. apparently the text size was super small, once i've clicked the (^ / v) arrows next to the font size the text in the dialog preview appeared. could it be that the default text size is set to 0 or something similar as the initial value instead of 9? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Happy Bastille day all, On 14 Jul 2015 11:10 pm, Davide DB dbdav...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. I think your scenarios are good. I'm really sorry for Tomaz. I did not mean to waste his time. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. I mostly agree with how you think the cases should be handled. And definitely agree with the objective of determining and agreeing on the best method. I've added a few comments. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu I don't think the auto-prompt should include sites with existing gps data further than x m from the new gps coordinates. BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) As I said above, I think the 'alert' should be that existing nearby sites show in the prompt, before a name is selected. -- I'll keep the use cases 2... existing text in the location field for another email. Maybe all of them are related to a dive site management scenarios rather than new dive being added. Once we are set with the above cases I can rewrite them from scratch and I will tattoo them on my left cheek :) -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:45 PM, Dirk Hohndel d...@hohndel.org wrote: So the summary of those last couple of cases should be If the user picks an existing dive site from the auto completion no existing data in that dive site is changed, but if that dive site has no GPS data, then that data may be added from the current dive the user is on. Makes sense? Yes And you are right - now we have all this wonderful information, distributed across ten emails. We need a better way to store this. Right now, instead of a dive site I have to pick up my child at the school :) I will try to resume all these use cases again in a new email later today so it will be easy to review everything again. I hope in the meantime Linus and others could chime in with other comments. Bye -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: build fails: -DSSRF_CUSTOM_SERIAL / dc_serial_t
On 14 July 2015 at 16:54, Dirk Hohndel d...@hohndel.org wrote: On Tue, Jul 14, 2015 at 01:02:42PM +0300, Lubomir I. Ivanov wrote: hello, i'm building libdc from the latest: git://subsurface-divelog.org/libdc which branch? master or Subsurface-testing or something else? i've noticed that -DSSRF_CUSTOM_SERIAL is need so that: rc = hw_ostc_parser_create (parser, data-context, data-deviceid, 0); works in libdc_buffer_parser() (libdivecomputer.c) with the extra argument. This gets defined in version.h in libdivecomputer when you have the latest Subsurface-testing branch. But one thing that I have noticed is that this file doesn't always get reliably recreated by the libdivecomputer build system. So if you are on the latest Subsurface-testing branch and you don't get that define, please remove the version.h from your build directory and try again. i understand that this adds some sort of custom serial support, but why don't we have this in the cmake options? Because we get it from libdivecomputer. adding the definition manually solves the above issue, but now i get a: libdivecomputer.h:58:38: error: 'dc_serial_t' was not declared in this scope Which makes me think that you are on the wrong branch in libdc yeah, apparently i was on 'master' and didn't know that i had to use 'Subsurface-testing'... i can see the SSRF_CUSTOM_SERIAL define in version.h.in. builds fine now. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GPS positions with companion app
On Tue, Jul 14, 2015 at 07:30:00AM +0200, Salvador Cuñat wrote: Good morning. The gps import has worked fine for me with last dives. ... processing gpsfix @ lun. 13 de jul. de 2015 9:34 which is withing six hours of dive from lun. 13 de jul. de 2015 10:01 until lun. 13 de jul. de 2015 10:52 look at the next gps fix @ lun. 13 de jul. de 2015 9:44 which is closer to the start of the dive, do continue with that processing gpsfix @ lun. 13 de jul. de 2015 9:44 which is withing six hours of dive from lun. 13 de jul. de 2015 10:01 until lun. 13 de jul. de 2015 10:52 look at the next gps fix @ lun. 13 de jul. de 2015 9:54 which is closer to the start of the dive, do continue with that processing gpsfix @ lun. 13 de jul. de 2015 9:54 which is withing six hours of dive from lun. 13 de jul. de 2015 10:01 until lun. 13 de jul. de 2015 10:52 look at the next gps fix @ lun. 13 de jul. de 2015 10:14 which is during the dive, pick that one ... The logic has applied fine even for a dive that had a bogus time in the DC (subsurface has just taken the last fix, which was the closest one to the bogus time) Thank for that update. I'm glad there is SOMETHING that actually works these days. As I said, I completely rewrote that code as it was a convoluted mess and I hope that the new mess, err, code that I created will be easier to understand, easier to maintain and easier to keep working. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
ok, who was that joker...?
Someone just tried to sign up for a cloud account with subsurf...@hohndel.org - the mailing list address :-) Those people with IP addresses in Germany... which ISP does reverse lookup to mwn.de, anyway? Ahhh, some googling shows that's IP addresses that the Ludwig-Maximilians-Universitaet Muenchen hands out. Robert, you have been identified... :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 11:40:06PM +1000, Rick Walsh wrote: BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. Well, I don't know. Scenario. I keep doing boat dives to the same sites (we'll be in Palau the fourth time this fall and I bet we'll go back to the Blue Corner and many other sites we've been to frequently). I use the phone app to track GPS points, anyway, and download them. Now I have a site with no name and a GPS location (well, I won't because I always do names first before downloading GPS, but Linus and some others do it the other way around). So now Subsurface showme that this was really close to the Blue Corner and I say right, I remember, we dove the Blue Corner today. Now if I want a new location because it's a different boat anchor point, I completely type in Blue Corner and save that. New site, same name, close by the others. Or I just want to pick the existing one (or one of the existing ones, I have three distinct anchor points for Blue Corner because they are different dives, depending where you start). And I get the GPS coordinates from that dive site that I picked. The interesting question is assuming I have GPS data, assuming I remember the site was also called Blue Corner, assuming that site is in Hawaii, should the Blue Corner from Palau even be offered as completion? I'm leaning towards no (not knowing how easy or hard that would be for Tomaz to do). At the very least it should be marked differently in the completion list if possible... maybe the completion list could add distances if both the current dive site and the completion dive site have GPS locations. And here I go again, coming up with fun ideas to distract Tomaz from doing what he's working on :-( BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Existing. See above. You pick a site, you use those coordinates. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu I don't think the auto-prompt should include sites with existing gps data further than x m from the new gps coordinates. See above - we should give the distance and let the user decide. 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) As I said above, I think the 'alert' should be that existing nearby sites show in the prompt, before a name is selected. After talking to Tomaz in a hangout I have learned that that is very hard to do on the completer (as that is just text based). But of course if the user has Marble enabled then they can see the dive sites nearby on the globe. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 03:52:39PM +0200, Davide DB wrote: Happy Bastille day all, Happy Bastille to you :) I hear from my history teachers that it was a very happy day for the people at the Bstille back then as well... If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. I see you point. I forgot to mention it in my previous email. Actually this involve a pre-check or pre-filtering selections once GPS data are imported. This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 04:05:57PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: And like it or not, our preferences do matter a bit here. Absolutely unnecessary statement. Nah - the occasional reminder that there are people here who have certain preferences... I'm not trying to impose my view but just contributing with my view for the sake of a better application. You are. And I'm grateful. Very grateful. Your work has really brought us along. I just pointed out that we need to make sure that the workflows we come up with make sense for Linus and I as well. See the emails that Linus sent on that topic. That was not at all intended to be perceived as a negative comment on the awesome work that you do helping us to figure out what the right flow should be in the end. I think this is just another case of email being an imperfect communication mechanism. Sorry that I chose my words poorly. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu This one? I really think that if the completion has GPS data that's the GPS data we pick. We can add something like by picking this dive site your GPS location moved by approximately m/km/miles/light years for cases where that move is more than 20m or 50m. I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in the same state as before this edit operation started. This was my intention. For the sake of simplicity Good. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: build fails: -DSSRF_CUSTOM_SERIAL / dc_serial_t
On Tue, Jul 14, 2015 at 01:02:42PM +0300, Lubomir I. Ivanov wrote: hello, i'm building libdc from the latest: git://subsurface-divelog.org/libdc which branch? master or Subsurface-testing or something else? i've noticed that -DSSRF_CUSTOM_SERIAL is need so that: rc = hw_ostc_parser_create (parser, data-context, data-deviceid, 0); works in libdc_buffer_parser() (libdivecomputer.c) with the extra argument. This gets defined in version.h in libdivecomputer when you have the latest Subsurface-testing branch. But one thing that I have noticed is that this file doesn't always get reliably recreated by the libdivecomputer build system. So if you are on the latest Subsurface-testing branch and you don't get that define, please remove the version.h from your build directory and try again. i understand that this adds some sort of custom serial support, but why don't we have this in the cmake options? Because we get it from libdivecomputer. adding the definition manually solves the above issue, but now i get a: libdivecomputer.h:58:38: error: 'dc_serial_t' was not declared in this scope Which makes me think that you are on the wrong branch in libdc /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:24 PM, Dirk Hohndel d...@hohndel.org wrote: This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. CANCELLED BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. OK. You pick an existing one and you stick with its whole data. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D Ouch, Actually it's there but I numbered it in a wrong way. It's Branch #Six BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.2 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 3:40 PM, Rick Walsh rickmwa...@gmail.com wrote: Happy Bastille day all, Happy Bastille to you :) If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. I see you point. I forgot to mention it in my previous email. Actually this involve a pre-check or pre-filtering selections once GPS data are imported. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: And like it or not, our preferences do matter a bit here. Absolutely unnecessary statement. I'm not trying to impose my view but just contributing with my view for the sake of a better application. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu This one? I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in the same state as before this edit operation started. This was my intention. For the sake of simplicity -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:16 PM, Dirk Hohndel d...@hohndel.org wrote: Scenario. I keep doing boat dives to the same sites (we'll be in Palau the fourth time this fall and I bet we'll go back to the Blue Corner and many other sites we've been to frequently). I use the phone app to track GPS points, anyway, and download them. Now I have a site with no name and a GPS location (well, I won't because I always do names first before downloading GPS, but Linus and some others do it the other way around). So now Subsurface showme that this was really close to the Blue Corner and I say right, I remember, we dove the Blue Corner today. Now if I want a new location because it's a different boat anchor point, I completely type in Blue Corner and save that. New site, same name, close by the others. Or I just want to pick the existing one (or one of the existing ones, I have three distinct anchor points for Blue Corner because they are different dives, depending where you start). And I get the GPS coordinates from that dive site that I picked. The interesting question is assuming I have GPS data, assuming I remember the site was also called Blue Corner, assuming that site is in Hawaii, should the Blue Corner from Palau even be offered as completion? I'm leaning towards no (not knowing how easy or hard that would be for Tomaz to do). At the very least it should be marked differently in the completion list if possible... maybe the completion list could add distances if both the current dive site and the completion dive site have GPS locations. And here I go again, coming up with fun ideas to distract Tomaz from doing what he's working on :-( I agree After talking to Tomaz in a hangout I have learned that that is very hard to do on the completer (as that is just text based). But of course if the user has Marble enabled then they can see the dive sites nearby on the globe. Of course. It's impossible making a user comfortable with the above choices only via a text autocompletion. Using Marble for UI interaction open other completely different scenario/interactions I guess... We should use Marble as visual aid while adding new dives. PS When I add dives, I'm of the gps-before-name party -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 04:33:12PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 4:24 PM, Dirk Hohndel d...@hohndel.org wrote: This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. CANCELLED Let's say marked for later consideration :-) BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. OK. You pick an existing one and you stick with its whole data. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D Ouch, Actually it's there but I numbered it in a wrong way. It's Branch #Six BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.2 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. So the summary of those last couple of cases should be If the user picks an existing dive site from the auto completion no existing data in that dive site is changed, but if that dive site has no GPS data, then that data may be added from the current dive the user is on. Makes sense? And you are right - now we have all this wonderful information, distributed across ten emails. We need a better way to store this. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Dive Location Management: getting a bit tired of it.
Okay - those are the patches I did yesterday + today.
Dirk asked me to focus on something else, so those are the patches that I
did.
I'll try to implement davide's mockup for the full dive site management
later.
From 39401bb643ef5bd959d0553341f203f828f2f0bc Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava tomaz.canabr...@intel.com
Date: Tue, 14 Jul 2015 14:29:48 -0300
Subject: [PATCH 6/6] Remove Quick Edit Dive Site Widget
Voted down by common consent.
Signed-off-by: Tomaz Canabrava tomaz.canabr...@intel.com
---
qt-ui/locationinformation.cpp | 98 ---
qt-ui/locationinformation.h | 21 --
qt-ui/maintab.cpp | 14 ---
qt-ui/maintab.h | 1 -
qt-ui/maintab.ui | 27
qt-ui/simpledivesiteedit.ui | 68 --
6 files changed, 8 insertions(+), 221 deletions(-)
delete mode 100644 qt-ui/simpledivesiteedit.ui
diff --git a/qt-ui/locationinformation.cpp b/qt-ui/locationinformation.cpp
index b9d985b..47ceb65 100644
--- a/qt-ui/locationinformation.cpp
+++ b/qt-ui/locationinformation.cpp
@@ -227,104 +227,6 @@ void LocationInformationWidget::resetPallete()
ui.diveSiteNotes-setPalette(p);
}
-SimpleDiveSiteEditDialog::SimpleDiveSiteEditDialog(QWidget *parent) :
- QDialog(parent, Qt::FramelessWindowHint | Qt::WindowSystemMenuHint | Qt::Popup),
- ui(new Ui::SimpleDiveSiteEditDialog()), changed_dive_site(false)
-{
- ui-setupUi(this);
- ui-diveSiteDescription-installEventFilter(this);
- ui-diveSiteNotes-installEventFilter(this);
-}
-
-SimpleDiveSiteEditDialog::~SimpleDiveSiteEditDialog()
-{
- delete ui;
-}
-
-bool SimpleDiveSiteEditDialog::eventFilter(QObject *obj, QEvent *ev)
-{
- if (ev-type() != QEvent::FocusOut)
- return false;
-
- if (obj == ui-diveSiteDescription) {
- diveSiteDescription_editingFinished();
- } else if (obj == ui-diveSiteNotes) {
- diveSiteNotes_editingFinished();
- }
- return false;
-}
-
-void SimpleDiveSiteEditDialog::showEvent(QShowEvent *ev)
-{
- const int heigth = 275;
- const int width = 450;
-
- // Position.
- QDialog::showEvent(ev);
- QRect currGeometry = geometry();
- currGeometry.setX(QCursor::pos().x() + 15);
- currGeometry.setY(QCursor::pos().y() - heigth / 2);
- currGeometry.setWidth(width);
- currGeometry.setHeight(heigth);
- setGeometry(currGeometry);
- ev-accept();
-
- //Da
- ui-diveSiteName-setText(displayed_dive_site.name);
- ui-diveSiteNotes-setPlainText(displayed_dive_site.notes);
- ui-diveSiteDescription-setPlainText(displayed_dive_site.description);
-
- const char *gps_text = printGPSCoords(displayed_dive_site.latitude.udeg, displayed_dive_site.longitude.udeg);
- ui-diveSiteCoordinates-setText(QString(gps_text));
- free( (void*) gps_text);
-
- changed_dive_site = false;
-}
-
-void SimpleDiveSiteEditDialog::on_diveSiteName_editingFinished()
-{
- if (ui-diveSiteName-text() == displayed_dive_site.name)
- return;
- free(displayed_dive_site.name);
- displayed_dive_site.name = copy_string(qPrintable(ui-diveSiteName-text()));
- changed_dive_site = true;
-}
-
-void SimpleDiveSiteEditDialog::on_diveSiteCoordinates_editingFinished()
-{
- double lat, lon;
- uint32_t uLat, uLon;
-
- parseGpsText(ui-diveSiteCoordinates-text(), lat, lon);
- uLat = lat * 100;
- uLon = lon * 100;
-
- if (uLat == displayed_dive_site.latitude.udeg uLon == displayed_dive_site.longitude.udeg)
- return;
-
- displayed_dive_site.latitude.udeg = uLat;
- displayed_dive_site.longitude.udeg = uLon;
- changed_dive_site = true;
-}
-
-void SimpleDiveSiteEditDialog::diveSiteDescription_editingFinished()
-{
- if (ui-diveSiteDescription-toPlainText() == displayed_dive_site.description)
- return;
- free(displayed_dive_site.description);
- displayed_dive_site.description = copy_string(qPrintable(ui-diveSiteDescription-toPlainText()));
- changed_dive_site = true;
-}
-
-void SimpleDiveSiteEditDialog::diveSiteNotes_editingFinished()
-{
- if (ui-diveSiteNotes-toPlainText() == displayed_dive_site.notes)
- return;
- free(displayed_dive_site.notes);
- displayed_dive_site.notes = copy_string(qPrintable(ui-diveSiteNotes-toPlainText()));
- changed_dive_site = true;
-}
-
bool LocationManagementEditHelper::eventFilter(QObject *obj, QEvent *ev)
{
QListView *view = qobject_castQListView*(obj);
diff --git a/qt-ui/locationinformation.h b/qt-ui/locationinformation.h
index b1746f7..b377319 100644
--- a/qt-ui/locationinformation.h
+++ b/qt-ui/locationinformation.h
@@ -44,27 +44,6 @@ private:
mode current_mode;
};
-
-#include ui_simpledivesiteedit.h
-class SimpleDiveSiteEditDialog : public QDialog {
-Q_OBJECT
-public:
- SimpleDiveSiteEditDialog(QWidget *parent);
- virtual ~SimpleDiveSiteEditDialog();
- bool changed_dive_site;
- bool eventFilter(QObject *obj, QEvent *ev);
-public slots:
- void on_diveSiteName_editingFinished();
- void on_diveSiteCoordinates_editingFinished();
- void diveSiteDescription_editingFinished();
- void diveSiteNotes_editingFinished();
-protected:
- void
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 11:51:40AM -0700, Linus Torvalds wrote: On Mon, Jul 13, 2015 at 4:42 PM, Dirk Hohndel d...@hohndel.org wrote: 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions 1.1.2. user types in name, doesn't pick one of the completions ... So quite frankly, I think the fact that 1.1.1 and 1.1.2 might be different is a big design mistake. I really think the very fact that you ask what should. the semantics be ends up being a sign that the interface is bad. Because even if we pick semantics that everybody agrees on, what does it mean that we had to ask that question? Really? It means that this is complecated. And that we want to think about the different cases and make sure that what we pick makes sense. To me, it means that any new user who wasn't part of the discussion is clearly *not* going to find whatever semantics we picked - whether we all agree on them or not - to be intuitive. I don't think you can draw that conclusion. What we are doing here is that we are breaking it down to make sure we understand the scenarios and we ask ourselves what would be the reasonably expected thing to do in those scenarios. So let me suggest something that is at least easier to explain than your 16 scenarios so far. I suggest that we really have two VERY CLEARLY separate cases: - the user wants to type in the dive site name (with name completion, the same way we have text completion for buddy names etc etc) - the user wants to pick a previous dive site that he/she has dove many times before. No, that's not the distinction. Because both start with typing in the name and Subsurface doesn't know which of the two cases it is. and I think we should keep those two cases separate, and not ever mix them up. So the two cases are: (1) when the user types in a dive site name, whether it is a completion or not is entirely immaterial - all it does is set the name. Nothing else. And by definition, since the user didn't pick an old dive site, the newly created dive site is a new unique dive site. This never changes any other dive sites, and it never changes the GPS coordinates fro this dive. You *only* edited the name for that dive. (2) when the user picks a dive site from a list, the user picks *that* dive site (and that GPS information). We throw the old dive site away. Now, we *might* want to warn and ask for confirmation if throw the old dive site away means that we actually lose the GPS information. The test for that would basically be: (a) does the dive site we throw away have GPS information, and (b) was this the last user of that dive site, so that it now is orphan. But the important part - for me - is that these two choices are very *clear* and obvious. I think the thing I really really hate about the current dive site model is how that text entry field we have now does *both*. And that is exactly the thing that I WANT. Because that's how users USE the field. So I think *that* is the real bug we have now. The text-field/drag-down that mixes old dives sites with new is wrong. It mixes up those two choices, which means that any semantics we give it is automatically wrong and confusing. In other words, I really think that the Location entry text field should _just_ be a text field. Yes, it autocompletes, but even when it auto-completes it does nothing else. So it would be (1). And I think the button to the right of it is what should open a list of pre-existing dive sites. So we'd have a clearly separate way to actually pick old dive sites, and this would be (2). No, that is not what I want. That's a horrible user experience. So now there is clear separation, and no question about semantics. Add a tool-tip thing maybe to *explain* it, so that when a person hovers over the button on the right it says pick an existing dive site and its GPS information, and when the user hovers over the divemaster text-field it says edit the name of the dive for this dive, creating a new dive site. So the advantage of this is that it's fairly easy to explain, and it supports very naturally the whole notion of (a) diving a lot at the same sites (perhaps a local one) for when you do *not* tend to use the companion app to get GPS locations (since why would you: using the companion app every time you dive at the Yellow House would just be crazy) (b) you use the companion app, and you basically start off assuming that you'll just create new dive sites, but you may still want to auto-complete the name, and the workflow should *not* behave differently whether you download the GPS location first or last. So note how there are no 16 cases. There are two fairly simple cases, and they have clearly separate GUI elements. So there's never any mix-up between the two. Hmm? NACK This makes sense to you because of the way
Re: GSoC Status - Week 7 (VPM-B)
Jan, On 13 Jul 2015, at 22:53, Jan Darowski jan.darow...@gmail.com wrote: This week I wrote a Boyles law compensation and checked all the calculations to find the root of the differences of results against the original implementation. I found that there is a difference between the code and papers in one of the CVA formulas. I need to add one more calculation, which will estimate the time at the surface required for the diver to fully regenerate. is your code available somewhere, e.g. on github? I would like to have a look (although maybe not tonight). Best Robert signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 12:34:27PM -0700, Linus Torvalds wrote: On Tue, Jul 14, 2015 at 12:15 PM, Dirk Hohndel d...@hohndel.org wrote: Now I fly to Hawaii and go diving. I run the companion app. I am one of the people who first download the GPS fixes before they start editing the dives. You realize that in many places you can't even do this? Because you may not have interenet? Any workflow that depends on order of companion app is broken. Right. You are the one who was yelling at me when you were in Hawaii and did exactly that. Exactly the steps that I described. And it didn't do exactly what I described as the output here. How do you expect anyone to be able to implement what's in your rants if your rants keep changing? Seriously. You haven't thought this through. Your model cannot work. Hmm, in the last email you were complaining about the fact that we actually ARE thinking it through. And now you are complaining that we are NOT thinking it through. Complicated. And the fundamental reason it cannot work is that you mix up two things. If you get GPS information from typing a name, the behavior is broken, because that breaks the I had no internet, so I'll have to download GPS data later, but now I have GPS data because I happened to picka name that already existed, so now it will never do that. No it doesn't. You aren't paying attention. You aren't reading what people are writing. If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Picking Blue Corner but not getting the GPS location is a ridiculous idea - what's the point of having dive sites to auto-complete from if you don't get their data. And stop ranting about the fact that you somehow need to explicitly tell Subsurface whether you want an existing dive site or a new one. You may not know if you have that site. And you don't have to. And if it acts differently depending on whether you write the whole name, or whether you then see the name and auto-complete, that's also obviously a complete disaster because that kind of difference is a UI disaster. I may not be a UI person, but I know shit when I see it. Excellent. Thank you for your constructive commentary. So exactly *how* do you suggest you solve it in your world-view? See above - start typing the name (if this is what you want to be the beginning point) - the completion needs to have the *choice* of cases, ie a drop-down menu, where the first choice is no GPS, but the other choices have that GPS marker (that we have in the divelist too). Why would there BE a completion with no GPS if the only dive site of that name has a GPS location attached to it? And if you explicitly press cursor down (and _only_ if you do that), then the globe scrolls to that entry. There could be multiple entries there, you need some way to see where it scrolls. HAVE YOU EVEN USED THE CURRENT CODE That's exactly what happens. But it's also important that the globe *not* scroll until you do that, because maybe you had the globe at the explicit point it was, because you were looking up the dive site names around that area! And again, it's important that this is an explicit choice. Really. It *has* to be. If it's not a button press ahead of time, it needs to be a button press (or keyboard action) after you've seen the list. Not some implicit if you complete the name thing. Because that cannot work, and you need to admit that. And you need to admit that you are just rambling and aren't following what's being developed. It IS an explicit choice. It has been discussed here as an explicit choice. It has been implemented as an explicit choice. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 5:07 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Jul 14, 2015 at 12:56 PM, Dirk Hohndel d...@hohndel.org wrote: If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. Dirk, YOU are the one not reading things. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Not intuitive at all. We went through this already. Thats' what we had in Hawaii, and it sucked. If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. It sure as hell is not intuitive. Seriously, Dirk. We *had* that interface. I used it. I wasn't the only one confused by it. See the whole previous discussion about it, where Miika did the exact same thing. linus - the thing you tested wasn't what we have today ( and I *think* I never made it fully work ), so no - we didn't had this interface. You cannot call ti intuitive if two people independently made the mistake of picking the textual auto-complete, and were surprised when it screwed up the data. So my suggestion was that the first entry in the list NEVER ADD GPS LOCATION. Even if all the *divesites* with that name have GPS location. Exactly so that you *can* auto-complete the name, without screwing up GPS. Because I thought we already agreed that that was a requirement. Your argument is crap, and let me quote it: I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. Picking Blue Corner but not getting the GPS location is a ridiculous idea NO IT IS NOT! I know have new GPS location. I want to pick Blue Corner without getting the new GPS locations screwed up. Calling that thing a ridiculous idea is wrong. It's not ridiculous, it's *obvious*. I may have old GPS information. Or, it can be a big dive site with the same name but different GPS information (my Turtle Reef example). Pick a slightly longer name just to drive the concept home. Pick something that isn't as easy to type. I want to auto-complete the *name* of the dive site, not get GPS data that screws things up. Linus - this is simple to add - in a way that will be easy to auto complete the name picking it in the list and not screwing up the location data OR to use an already created location if the user chooses so. this would work for you? : - First entry of the Complete Popup should *always* only complete without gettting any gps information - Other entries would complete gps information ( remember that the new list is very different from the old one and it shows the country / place / coords ) and if user selects those it would set the dive site instead of creating a new one. That is _not_ ridiculous, and I don't understand how you can even claim it is. It's how things used to work, and they worked very well indeed. Right now the dive site model has actually made things *worse*. Linus ___ 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: GSoC Status - Week 7 (VPM-B)
Yes, I've seen this link first time you sent it. Parameters are not the problem here. We have a different tissue saturation calculation method, so results differ a little bit at the beginning of the ascent. So the first stop is a little bit later (6m), It has a big influence on the total deco time because later gradients are calculated against this depth. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 1:19 PM, Tomaz Canabrava tcanabr...@kde.org wrote: If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. Note that I have no GPS, because I haven't done the companion app sync yet, because I have no internet can also be important. Because if that fills in GPS information, then that means that my _future_ sync with the companion app will not fill in the GPS data any more. See? This is what I was talking about when I said that behavior should not depend on whether you have synced with the companion app before or after editing the dive location name. Because there just isn't one correct case. Yes, sometimes you want GPS data, because you didn't even have a companion app running, or you just decide that yeah, I have a good enough fix from before. And sometimes you _don't_ want GPS data, even if you don't have any yet, because you want to fill it later. I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. But I do actually want the name expansion, not the type it out. I don't want to write the whole name if I already have it. For example, the name might not be Blue Hole. It could be Laje Dois Irmâos, Fernando de Noronha, Brazil. Things with special characters that I figured out after-the-fact, and can't necessarily even type with my keyboard without looking up the keyboard map (just out of curiosity, I checked: Right-Alt+6 to get a dead ^, followed by 'a'. Although apparently it *should* have been 'ã' - Shift-RightAlt-Tidle + 'a' on my keyboard). Do you really want em to type it out, just because I know I don't want GPS information, because I'm going to get the GPS info from the companion app when the internet starts working again? Fernando de Noronha did have intenet, but it was kind of flaky. Some other places have been even worse. So maybe I already have the dive site name, but I do *not* have GPS location, and I don't *want* GPS location (because I know it I have better info on my phone, or one of those Turtle Reef is 20 miles of west Maui coast-line things), but I do want to just get auto-complete. Hey, I use auto-complete for dive buddy names. And that's despite the fact that the most common dive buddy name I have has four letters. For something like Molokini Backwall drift: Reef's End? Yeah, I'll auto-complete it, thank you very much. And I just think that in general, the whole we have to have a discussion spread out over several weeks, three different versions, and people can't even agree on the semantics is a sign that we should *not* have some kind of subtle rules and implicit behavior. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Good morning, On 15 Jul 2015 7:11 am, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Jul 14, 2015 at 1:19 PM, Tomaz Canabrava tcanabr...@kde.org wrote: If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. Note that I have no GPS, because I haven't done the companion app sync yet, because I have no internet can also be important. Because if that fills in GPS information, then that means that my _future_ sync with the companion app will not fill in the GPS data any more. See? This is what I was talking about when I said that behavior should not depend on whether you have synced with the companion app before or after editing the dive location name. Because there just isn't one correct case. Yes, sometimes you want GPS data, because you didn't even have a companion app running, or you just decide that yeah, I have a good enough fix from before. And sometimes you _don't_ want GPS data, even if you don't have any yet, because you want to fill it later. I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. But I do actually want the name expansion, not the type it out. I don't want to write the whole name if I already have it. For example, the name might not be Blue Hole. It could be Laje Dois Irmâos, Fernando de Noronha, Brazil. Things with special characters that I figured out after-the-fact, and can't necessarily even type with my keyboard without looking up the keyboard map (just out of curiosity, I checked: Right-Alt+6 to get a dead ^, followed by 'a'. Although apparently it *should* have been 'ã' - Shift-RightAlt-Tidle + 'a' on my keyboard). Do you really want em to type it out, just because I know I don't want GPS information, because I'm going to get the GPS info from the companion app when the internet starts working again? Fernando de Noronha did have intenet, but it was kind of flaky. Some other places have been even worse. So maybe I already have the dive site name, but I do *not* have GPS location, and I don't *want* GPS location (because I know it I have better info on my phone, or one of those Turtle Reef is 20 miles of west Maui coast-line things), but I do want to just get auto-complete. Hey, I use auto-complete for dive buddy names. And that's despite the fact that the most common dive buddy name I have has four letters. For something like Molokini Backwall drift: Reef's End? Yeah, I'll auto-complete it, thank you very much. Could the best solution be broken into two parts? 1. You haven't yet synced the companion app but you select your dive site from the list, so that new dive is assigned that existing site. 2. You sync the app, and the coordinates for that dive put it 20m (or whatever) from that site. IIf this occurs you are prompted with 3 options: -Adopt existing coordinates (leave as is) -Create a new site with same name (might be a different mooring, might be a different ocean, either way you consider it different) -Update that site's location with the just downloaded coordinates And I just think that in general, the whole we have to have a discussion spread out over several weeks, three different versions, and people can't even agree on the semantics is a sign that we should *not* have some kind of subtle rules and implicit behavior. Linus ___ 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: More Location Fixes.
On Tue, Jul 14, 2015 at 12:15 PM, Dirk Hohndel d...@hohndel.org wrote: Now I fly to Hawaii and go diving. I run the companion app. I am one of the people who first download the GPS fixes before they start editing the dives. You realize that in many places you can't even do this? Because you may not have interenet? Any workflow that depends on order of companion app is broken. Seriously. You haven't thought this through. Your model cannot work. And the fundamental reason it cannot work is that you mix up two things. If you get GPS information from typing a name, the behavior is broken, because that breaks the I had no internet, so I'll have to download GPS data later, but now I have GPS data because I happened to picka name that already existed, so now it will never do that. And it used to be broken the other way, where typing in the name would overwrite GPS data. That was obvious crap too, although you used to defend *that* behavior as well. And if it acts differently depending on whether you write the whole name, or whether you then see the name and auto-complete, that's also obviously a complete disaster because that kind of difference is a UI disaster. I may not be a UI person, but I know shit when I see it. So exactly *how* do you suggest you solve it in your world-view? I claim you need that extra button. You *have* to have some actually visually obvious way to decide between just pick the name or pick this dive site. Really. Not 16 rules for implicitly doing something magical. Now, *how* that extra button works might be tweakable, but not whether it exists. If you don't have that explicit choice, and if it's not clear, your model really *cannot* work. You need to face the truth, not make up some workflow up front that can be shown to be obviously broken. See above. Really. Now, if you don't like the button press ahead of time, make it a completion choice. But it needs to be an *explicit* choice. Do something like: - start typing the name (if this is what you want to be the beginning point) - the completion needs to have the *choice* of cases, ie a drop-down menu, where the first choice is no GPS, but the other choices have that GPS marker (that we have in the divelist too). And if you explicitly press cursor down (and _only_ if you do that), then the globe scrolls to that entry. There could be multiple entries there, you need some way to see where it scrolls. But it's also important that the globe *not* scroll until you do that, because maybe you had the globe at the explicit point it was, because you were looking up the dive site names around that area! And again, it's important that this is an explicit choice. Really. It *has* to be. If it's not a button press ahead of time, it needs to be a button press (or keyboard action) after you've seen the list. Not some implicit if you complete the name thing. Because that cannot work, and you need to admit that. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 12:56 PM, Dirk Hohndel d...@hohndel.org wrote: If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. Dirk, YOU are the one not reading things. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Not intuitive at all. We went through this already. Thats' what we had in Hawaii, and it sucked. If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. It sure as hell is not intuitive. Seriously, Dirk. We *had* that interface. I used it. I wasn't the only one confused by it. See the whole previous discussion about it, where Miika did the exact same thing. You cannot call ti intuitive if two people independently made the mistake of picking the textual auto-complete, and were surprised when it screwed up the data. So my suggestion was that the first entry in the list NEVER ADD GPS LOCATION. Even if all the *divesites* with that name have GPS location. Exactly so that you *can* auto-complete the name, without screwing up GPS. Because I thought we already agreed that that was a requirement. Your argument is crap, and let me quote it: Picking Blue Corner but not getting the GPS location is a ridiculous idea NO IT IS NOT! I know have new GPS location. I want to pick Blue Corner without getting the new GPS locations screwed up. Calling that thing a ridiculous idea is wrong. It's not ridiculous, it's *obvious*. I may have old GPS information. Or, it can be a big dive site with the same name but different GPS information (my Turtle Reef example). Pick a slightly longer name just to drive the concept home. Pick something that isn't as easy to type. I want to auto-complete the *name* of the dive site, not get GPS data that screws things up. That is _not_ ridiculous, and I don't understand how you can even claim it is. It's how things used to work, and they worked very well indeed. Right now the dive site model has actually made things *worse*. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATH] try to make people happy.
From 109fab3285bc116bde056ba40c9f33255fdce503 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava tomaz.canabr...@intel.com
Date: Tue, 14 Jul 2015 18:43:47 -0300
Subject: [PATCH 7/7] Offer an option to just complete the text
Make the kids fight no more.
Signed-off-by: Tomaz Canabrava tomaz.canabr...@intel.com
---
qt-models/divelocationmodel.cpp | 53 -
qt-models/divelocationmodel.h | 4
qt-ui/maintab.cpp | 3 ++-
qt-ui/modeldelegates.cpp| 22 +++--
4 files changed, 73 insertions(+), 9 deletions(-)
diff --git a/qt-models/divelocationmodel.cpp b/qt-models/divelocationmodel.cpp
index 42af4f6..bddca8f 100644
--- a/qt-models/divelocationmodel.cpp
+++ b/qt-models/divelocationmodel.cpp
@@ -1,6 +1,8 @@
#include divelocationmodel.h
#include dive.h
#include QDebug
+#include QLineEdit
+#include QIcon
bool dive_site_less_than(dive_site *a, dive_site *b)
{
@@ -13,7 +15,9 @@ LocationInformationModel *LocationInformationModel::instance()
return self;
}
-LocationInformationModel::LocationInformationModel(QObject *obj) : QAbstractTableModel(obj), internalRowCount(0)
+LocationInformationModel::LocationInformationModel(QObject *obj) : QAbstractTableModel(obj),
+ internalRowCount(0),
+ textField(NULL)
{
}
@@ -25,19 +29,45 @@ int LocationInformationModel::columnCount(const QModelIndex parent) const
int LocationInformationModel::rowCount(const QModelIndex parent) const
{
Q_UNUSED(parent);
- return internalRowCount;
+ return internalRowCount + 1;
}
QVariant LocationInformationModel::data(const QModelIndex index, int role) const
{
if (!index.isValid())
return QVariant();
- struct dive_site *ds = get_dive_site(index.row());
+
+ // Special case to handle the 'create dive site' with name.
+ if (index.row() == 0) {
+ if (index.column() == UUID)
+ return 0;
+ switch(role) {
+ case Qt::DisplayRole : {
+struct dive_site *ds;
+int i;
+for_each_dive_site(i, ds) {
+ QString dsName(ds-name);
+ if (dsName.startsWith(textField-text()))
+ return dsName;
+}
+return textField-text();
+ }
+ case Qt::ToolTipRole : {
+return QString(tr(Create dive site));
+ }
+ case Qt::EditRole : return textField-text();
+ case Qt::DecorationRole : return QIcon(:plus);
+ }
+ }
+
+ // The dive sites are -1 because of the first item.
+ struct dive_site *ds = get_dive_site(index.row()-1);
if (!ds)
return QVariant();
switch(role) {
+ case Qt::EditRole:
case Qt::DisplayRole :
switch(index.column()) {
case UUID: return ds-uuid;
@@ -52,11 +82,22 @@ QVariant LocationInformationModel::data(const QModelIndex index, int role) cons
case TAXONOMY_3: return TODO;
}
break;
+ case Qt::DecorationRole : {
+ if (dive_site_has_gps_location(ds))
+ return QIcon(:geocode);
+ else
+ return QVariant();
+ }
}
return QVariant();
}
+void LocationInformationModel::setFirstRowTextField(QLineEdit *t)
+{
+ textField = t;
+}
+
void LocationInformationModel::update()
{
beginResetModel();
@@ -71,7 +112,7 @@ int32_t LocationInformationModel::addDiveSite(const QString name, int lon, int
latitude.udeg = lat;
longitude.udeg = lon;
- beginInsertRows(QModelIndex(), dive_site_table.nr, dive_site_table.nr);
+ beginInsertRows(QModelIndex(), dive_site_table.nr + 1, dive_site_table.nr + 1);
uint32_t uuid = create_dive_site_with_gps(name.toUtf8().data(), latitude, longitude);
qSort(dive_site_table.dive_sites, dive_site_table.dive_sites + dive_site_table.nr, dive_site_less_than);
internalRowCount = dive_site_table.nr;
@@ -81,7 +122,7 @@ int32_t LocationInformationModel::addDiveSite(const QString name, int lon, int
bool LocationInformationModel::setData(const QModelIndex index, const QVariant value, int role)
{
- if (!index.isValid())
+ if (!index.isValid() || index.row() == 0)
return false;
if (role != Qt::EditRole)
@@ -99,7 +140,7 @@ bool LocationInformationModel::removeRows(int row, int count, const QModelIndex
if(row = rowCount())
return false;
- beginRemoveRows(QModelIndex(), row, row);
+ beginRemoveRows(QModelIndex(), row + 1, row + 1);
struct dive_site *ds = get_dive_site(row);
if (ds)
delete_dive_site(ds-uuid);
diff --git a/qt-models/divelocationmodel.h b/qt-models/divelocationmodel.h
index 8cae3a0..ee52d2b 100644
--- a/qt-models/divelocationmodel.h
+++ b/qt-models/divelocationmodel.h
@@ -5,6 +5,8 @@
#include QStringListModel
#include stdint.h
+class QLineEdit;
+
class LocationInformationModel : public QAbstractTableModel {
Q_OBJECT
public:
@@ -16,12 +18,14 @@ public:
int32_t addDiveSite(const QString name, int lat = 0, int lon = 0);
bool setData(const QModelIndex index, const QVariant value, int role);
bool removeRows(int row, int count, const QModelIndex parent = QModelIndex());
+ void setFirstRowTextField(QLineEdit *textField);
public slots:
void update();
private:
LocationInformationModel(QObject *obj = 0);
int internalRowCount;
+
Re: [PATCH] Bluetooth support for Android
On Monday 13 July 2015 23:53:56 Claudiu Olteanu wrote:
I attached some patches which can be used to fix the issues
related to Bluetooth connectivity on Android platforms.
On Android, a connection to a service cannot be established
using a port. The first patch should fix this issue using the uuid
of the SPP service on the connection step.
Hi Claudiu
Is this method supposed to work elsewhere too? Is there a reason not to use it
everywhere?
On my device with a Android 5.1.1 I observed that if I start the
download process without waiting for the scanning process to
end, then the devices gets stuck after downloading a few
packages. I did over 20 tests for both my dive computers
(HW OSTC2 and HW OSTCs) and I got the same results.
I looked over the Android logs using the logcat tool and I saw
that the download mode always gets stuck when the scanning
process is stopped. I am not sure if this is a bug on the Android
platform, or on the Qt framework.
You can find some logs below.
It would be interesting to test whether this happens on other Android devices
too, especially those using BlueZ instead of Bluedroid.
Thanks for the patches. Comments on them:
+ if (serial_port-socket-state() ==
QBluetoothSocket::ConnectingState ||
+ // It seems that the connection step took more than
expected. Wait another 20 seconds.
+ qDebug() The connection step took more than expected.
Wait another 20 seconds;
+ timer.start(4 * msec);
+ loop.exec();
+ }
What's the use for this? How likely is answering in 20 seconds when in 5 it
didn't answer? If 25 seconds is better, why not always wait for 25 seconds?
+#if defined(Q_OS_ANDROID)
+ if (remoteDeviceDiscoveryAgent-isActive()) {
+ ui-dialogStatus-setText(QString(The device %1 can
be used for connection. Wait until the device scanning is done and press
the Save button.)
+
.arg(remoteDeviceInfo.address().toString()));
+ return;
+ }
+#endif
Please add a simple comment to the source code why this is done, in addition
to the commit. Something like // on Android, the device gets stuck in if we
try to use it before discovery is done
--
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
Linux USB-to-serial driver ch341 not supported?
Love the subsurface program. I bought a Suunto Zoop cable from Amazon: USB download DIY cable Suunto Zoop Vyper Vytec Mosquito HelO2 works with Subsurface and Dive Log at Amazon link http://www.amazon.com/gp/product/B00SYZIJXI?psc=1redirect=trueref_=oh_aui_detailpage_o01_s00 Sold by a Bulgarian firm, at Amazon link http://www.amazon.com/gp/aag/main/ref=olp_merch_name_1?ie=UTF8asin=B00SYZIJXIisAmazonFulfilled=0seller=A2IZ2CWVOIWGRU It works on Windows 7, but not on Linux mint 17.1. Linux loads the cable driver as a ch341-uart: Jul 10 11:06:02 ankh kernel: [90601.188079] usb 5-3: new full-speed USB device number 4 using ohci-pci Jul 10 11:06:02 ankh kernel: [90601.352734] usb 5-3: New USB device found, idVendor=1a86, idProduct=7523 Jul 10 11:06:02 ankh kernel: [90601.352742] usb 5-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Jul 10 11:06:02 ankh kernel: [90601.352747] usb 5-3: Product: USB2.0-Ser! Jul 10 11:06:02 ankh mtp-probe: checking bus 5, device 4: /sys/devices/pci:00/:00:13.0/usb5/5-3 Jul 10 11:06:02 ankh mtp-probe: bus: 5, device: 4 was not an MTP device Jul 10 11:06:02 ankh kernel: [90601.414559] usbcore: registered new interface driver usbserial Jul 10 11:06:02 ankh kernel: [90601.414609] usbcore: registered new interface driver usbserial_generic Jul 10 11:06:02 ankh kernel: [90601.414644] usbserial: USB Serial support registered for generic Jul 10 11:06:02 ankh kernel: [90601.417837] usbcore: registered new interface driver ch341 Jul 10 11:06:02 ankh kernel: [90601.417850] usbserial: USB Serial support registered for ch341-uart Jul 10 11:06:02 ankh kernel: [90601.417869] ch341 5-3:1.0: ch341-uart converter detected Jul 10 11:06:02 ankh kernel: [90601.440802] usb 5-3: ch341-uart converter now attached to ttyUSB0 In Linux subsurface reports error reading device Maybe the ch341 driver is at fault? Thanks, Greg ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Guys I could not follow you trough all the exchanges. I'm not sure I understood everything hence I'm not able to recap the workflow as I promised. I'm convinced that most of the misunderstanding originate from the fact that emails are the wrong tool for this. Tomaz save us all :) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 4:42 PM, Dirk Hohndel d...@hohndel.org wrote: 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions 1.1.2. user types in name, doesn't pick one of the completions ... So quite frankly, I think the fact that 1.1.1 and 1.1.2 might be different is a big design mistake. I really think the very fact that you ask what should. the semantics be ends up being a sign that the interface is bad. Because even if we pick semantics that everybody agrees on, what does it mean that we had to ask that question? Really? To me, it means that any new user who wasn't part of the discussion is clearly *not* going to find whatever semantics we picked - whether we all agree on them or not - to be intuitive. So let me suggest something that is at least easier to explain than your 16 scenarios so far. I suggest that we really have two VERY CLEARLY separate cases: - the user wants to type in the dive site name (with name completion, the same way we have text completion for buddy names etc etc) - the user wants to pick a previous dive site that he/she has dove many times before. and I think we should keep those two cases separate, and not ever mix them up. So the two cases are: (1) when the user types in a dive site name, whether it is a completion or not is entirely immaterial - all it does is set the name. Nothing else. And by definition, since the user didn't pick an old dive site, the newly created dive site is a new unique dive site. This never changes any other dive sites, and it never changes the GPS coordinates fro this dive. You *only* edited the name for that dive. (2) when the user picks a dive site from a list, the user picks *that* dive site (and that GPS information). We throw the old dive site away. Now, we *might* want to warn and ask for confirmation if throw the old dive site away means that we actually lose the GPS information. The test for that would basically be: (a) does the dive site we throw away have GPS information, and (b) was this the last user of that dive site, so that it now is orphan. But the important part - for me - is that these two choices are very *clear* and obvious. I think the thing I really really hate about the current dive site model is how that text entry field we have now does *both*. So I think *that* is the real bug we have now. The text-field/drag-down that mixes old dives sites with new is wrong. It mixes up those two choices, which means that any semantics we give it is automatically wrong and confusing. In other words, I really think that the Location entry text field should _just_ be a text field. Yes, it autocompletes, but even when it auto-completes it does nothing else. So it would be (1). And I think the button to the right of it is what should open a list of pre-existing dive sites. So we'd have a clearly separate way to actually pick old dive sites, and this would be (2). So now there is clear separation, and no question about semantics. Add a tool-tip thing maybe to *explain* it, so that when a person hovers over the button on the right it says pick an existing dive site and its GPS information, and when the user hovers over the divemaster text-field it says edit the name of the dive for this dive, creating a new dive site. So the advantage of this is that it's fairly easy to explain, and it supports very naturally the whole notion of (a) diving a lot at the same sites (perhaps a local one) for when you do *not* tend to use the companion app to get GPS locations (since why would you: using the companion app every time you dive at the Yellow House would just be crazy) (b) you use the companion app, and you basically start off assuming that you'll just create new dive sites, but you may still want to auto-complete the name, and the workflow should *not* behave differently whether you download the GPS location first or last. So note how there are no 16 cases. There are two fairly simple cases, and they have clearly separate GUI elements. So there's never any mix-up between the two. Hmm? Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
