Re: GSoC Status - Week 7 (Customizable prints)
On 20 July 2015 at 13:06, Gehad Elrobey gehadelro...@gmail.com wrote:
On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 19 July 2015 at 13:23, Gehad Elrobey gehadelro...@gmail.com wrote:
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@gmail.com
wrote:
Yes it does, you can test it on current master.
this is technically a Qt bug of sorts, because the QPrintEngine
greyscale property for some *very odd* doesn't work in the preview
dialog.
(edit) some *very odd* reason.
will need to go AFK in a bit; drop me a line when you need me to
review again - e.g. tomorrow.
I have fixed the gray-scale issue as we discussed, Now we always use
QPrinter::setColorMode() during actual printing which produce nice
grayscale
prints, and use the css filter with the profile rasterization only
during
the previewing in the QPrintPreviewDialog with grayscale selected, I
pushed
the updates to my branch.
just pulled the latest commits (at 185eff2a60).
the preview works as expected - rasterized when greyscale and vector
when in color.
but the actual print always ends in color for me (table and profile)!
looking at the code the branch here is entered correctly:
if (printOptions-color_selected printerPtr-colorMode()) {
printerPtr-setColorMode(QPrinter::Color);
} else {
printerPtr-setColorMode(QPrinter::GrayScale); // -
this is called when print in color is unchecked
}
but setColorMode() simply doesn't work!
are you sure this works for you?
if it works for you but not for me, it could be Qt version specific in
which case setColorMode() is *completely unreliable* and we need to
use the raster/greyscale/css thing for the actual print as well.
Yes, setColorMode works fine for me using Qt 5.5.0 on arch linux, I have
attached a colored and gray-scale printouts with the current settings.
ok, in that case won't use setColorMode() at all. just make it raster
for greyscale - same as the preview method and vector for color mode.
the whole greyscale thing has taken too much time already and is very
questionable on application level as most modern drivers and spoolers
should have a greyscale override anyway.
BTW there is something very annoying in cmake and we need to fix that...
I ll try to figure out this.
thanks.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Enable android build on Mac.
This adds system specific versions to certain parameters when building the Android package on a Mac. 0001-Enable-Android-build-on-Mac.patch Description: Binary data /Jocke ___ 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 Mon, Jul 20, 2015 at 12:20 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 20 July 2015 at 13:06, Gehad Elrobey gehadelro...@gmail.com wrote:
On Sun, Jul 19, 2015 at 9:56 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 19 July 2015 at 13:23, Gehad Elrobey gehadelro...@gmail.com wrote:
On Fri, Jul 17, 2015 at 9:28 PM, Lubomir I. Ivanov
neolit...@gmail.com
wrote:
On 17 July 2015 at 22:17, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 17 July 2015 at 22:10, Gehad Elrobey gehadelro...@gmail.com
wrote:
Yes it does, you can test it on current master.
this is technically a Qt bug of sorts, because the QPrintEngine
greyscale property for some *very odd* doesn't work in the preview
dialog.
(edit) some *very odd* reason.
will need to go AFK in a bit; drop me a line when you need me to
review again - e.g. tomorrow.
I have fixed the gray-scale issue as we discussed, Now we always use
QPrinter::setColorMode() during actual printing which produce nice
grayscale
prints, and use the css filter with the profile rasterization only
during
the previewing in the QPrintPreviewDialog with grayscale selected, I
pushed
the updates to my branch.
just pulled the latest commits (at 185eff2a60).
the preview works as expected - rasterized when greyscale and vector
when in color.
but the actual print always ends in color for me (table and profile)!
looking at the code the branch here is entered correctly:
if (printOptions-color_selected printerPtr-colorMode()) {
printerPtr-setColorMode(QPrinter::Color);
} else {
printerPtr-setColorMode(QPrinter::GrayScale); // -
this is called when print in color is unchecked
}
but setColorMode() simply doesn't work!
are you sure this works for you?
if it works for you but not for me, it could be Qt version specific in
which case setColorMode() is *completely unreliable* and we need to
use the raster/greyscale/css thing for the actual print as well.
Yes, setColorMode works fine for me using Qt 5.5.0 on arch linux, I have
attached a colored and gray-scale printouts with the current settings.
ok, in that case won't use setColorMode() at all. just make it raster
for greyscale - same as the preview method and vector for color mode.
the whole greyscale thing has taken too much time already and is very
questionable on application level as most modern drivers and spoolers
should have a greyscale override anyway.
Now we always rasterize for grayscale, I pushed the updates.
--
regards,
Gehad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] GSoC Printing: part 4
Part 4 of the new GSoC printing module from Gehad. Adds: 1) Better greyscale conversations when print in color is de-selected. Due to a QPrinter-setColorMode() bug we are forced to rasterize the entire page (profile, tables, everything) when in greyscale. We have faced some limitations here including the fact that Profile2 support for custom color tables is incomplete. Consider this the cheaper solution and if the GSoC timeframe allows it, we can invest more time into attempting proper greyscale vector prints using the custom color table and so on. 2) A preview graphic in the Template edit dialog When editing a template, gitting Apply will allow you to review your changes in the dialog itself. 3) Custom CSS colors and color themes Basically you can save your preferred color scheme, containing a set of common colors and use it for all templates. Also, you can edit a template itself directly and use a hardcoded color e.g. #fafafa for backgrounds. 4) More generic fixes... ATM this is useable, but the stock templates aren't pretty yet; an important thing on the TODO list is to get the already present templates to look similar to what we in the previous print module (i.e. user-ready). Feedback on the usability itself will soon be needed from the community! ATM, given you have libgrantlee installed you can try building with NO_PRINTING=0 and submit feedback to one of the related ML threads. -- The following changes since commit 05109b2d6c7e8ef816b1290c583492dec78b3f07: Don't hide location completion when user types space (2015-07-18 13:39:19 -0700) are available in the git repository at: g...@github.com:neolit123/subsurface.git custom-print for you to fetch changes up to 599920c6cfd87a213634097045e29f592390438b: Printing: export grayscale filter value to template (2015-07-20 15:29:05 +0300) Gehad elrobey (24): Printing: overwrite the old custom template file Printing: show confirmation message before overwriting the template Printing: enhance the one_dive per page template Printing: handle memory leak in printer class Printing: refactoring printer class Printing: change QPrinter to parent class QPaintDevice Printing: check for different printing modes Printing: add preview to TemplateEdit dialog Printing: save only if data is changed in template_options Printing: add apply button to TemplateEdit class Printing: update preview on apply settings Printing: update preview on field changes Printing: add colors tab to edit window Printing: show colors in edit tab Printing: implement edit buttons in color tab Printing: save custom color palette to QSettings Printing: export color settings to grantlee Printing: make templates support custom colors Printing: add custom color palette Printing: change 'Discard' to 'Cancel' button Printing: add default case to switch Printing: transfer profile to QImage if grayscale Printing: add css filter to templates Printing: export grayscale filter value to template printer.cpp | 109 +++- printer.h | 15 ++- printing_templates/one_dive.html | 44 --- printing_templates/two_dives.html | 10 +- qt-ui/printdialog.cpp | 33 - qt-ui/printoptions.h | 25 +++- qt-ui/templateedit.cpp| 140 ++-- qt-ui/templateedit.h | 9 +- qt-ui/templateedit.ui | 261 ++ templatelayout.cpp| 3 + templatelayout.h | 21 +++ 11 files changed, 581 insertions(+), 89 deletions(-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ctrl-+ and Qt5.5
On Sun, Jul 19, 2015 at 07:43:19PM -0700, Thiago Macieira wrote: On Sunday 19 July 2015 19:38:25 Thiago Macieira wrote: On Sunday 19 July 2015 06:28:37 Gaetan Bisson wrote: [2015-07-19 17:06:48 +0300] Claudiu Olteanu: I have a Fedora 22 with Qt 5.5.0 and the shortcut is working. Subsurface version: 4.4.2-1040-g5cbbff008411c322. It might be related to this patch, then: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/keypad-sh or tcuts.patch?h=packages/qt5 I'll ask our Qt maintainer. Testing it here. Doesn't fix the issue for me. I assume this is something that you will address upstream, Thiago - so we might get this fixed in 5.5.1 ? I was hoping to switch Mac and Windows builds to Qt5.5 soon but a regression like this is rather annoying. Since I'm building my own Qt packages on those two platforms it would be easy enough to cherry pick a fix if it was available. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ctrl-+ and Qt5.5
On Sun, Jul 19, 2015 at 05:06:48PM +0300, Claudiu Olteanu wrote: Hi there, I have a Fedora 22 with Qt 5.5.0 and the shortcut is working. Subsurface version: 4.4.2-1040-g5cbbff008411c322. Given Thiago's email I at first was confused... but then of course I'm not familiar with Romanian keyboards. And a bit of searching appears to show that there are two different layouts tagged as Romanian keyboards, and one of them has the '+' without shift on the key next to the '0' - which would explain why this works for you, based on Thiago's description of the nature of the bug. /D ___ 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 Mon, Jul 20, 2015 at 04:17:28PM +0300, Lubomir I. Ivanov wrote: - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: CMakeFiles\printing_templatesLink.dir\build.make:48: recipe for target 'CMakeFil es/printing_templatesLink' failed make[2]: *** [CMakeFiles/printing_templatesLink] Error 1 CMakeFiles\Makefile2:215: recipe for target 'CMakeFiles/printing_templatesLink.d ir/all' failed make[1]: *** [CMakeFiles/printing_templatesLink.dir/all] Error 2 I don't get this, either. And I usually build on my ArchLinux box with printing enabled. Same goes for the Windows and Mac builds... do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
On Sun, Jul 19, 2015 at 11:25:17PM +0300, Claudiu Olteanu wrote: Child QObjects don't need to be cleaned. But I'm not seeing any parent-child relationship here. I'm deferring to you here. I'm just pointing out, I haven't done any investigation. Would you like me to? I don't have too much experience with C++ and Qt framework. If you have time, it would be safer if do some investigation? In general the mentor is not necessarily the clean up person... I know, Thiago offered, but just to put this out here. I will admit that I put somewhat less focus on making sure that we are leak free than on some other cleanup tasks. I saw that Q_OS_MAC doesn't include the open source version and I didn't know which is that :). Huh? I didn't look over the implementation. I just read the description from here[1] and it is mentioned something about an open source version :). [1] - http://doc.qt.io/qt-5.5/qtglobal.html#Q_OS_MAC Fun. But of course Thiago already clarified. I'll update the commit to be consistent with what we use elsewhere (not that we are all that consistent about these to be honest). /D ___ 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 20 July 2015 at 16:10, Gehad Elrobey gehadelro...@gmail.com wrote: On Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: CMakeFiles\printing_templatesLink.dir\build.make:48: recipe for target 'CMakeFil es/printing_templatesLink' failed make[2]: *** [CMakeFiles/printing_templatesLink] Error 1 CMakeFiles\Makefile2:215: recipe for target 'CMakeFiles/printing_templatesLink.d ir/all' failed make[1]: *** [CMakeFiles/printing_templatesLink.dir/all] Error 2 do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] GSoC Printing: part 4
On 20 July 2015 at 16:22, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 03:48:32PM +0300, Lubomir I. Ivanov wrote: Part 4 of the new GSoC printing module from Gehad. I merged this. thanks. 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 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( do you think the timings are OK for the pencils down date? what else is on your TODO list? mind that there might be user feedback which will require some effort - e.g. feature requests usually do that. thanks 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 Mon, Jul 20, 2015 at 3:02 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 20 July 2015 at 14:59, Gehad Elrobey gehadelro...@gmail.com wrote: Now we always rasterize for grayscale, I pushed the updates. PR sent. thank you for bearing with the greyscale issues... some important things TODO would be: - add the old 6 dives per page template. some of the users will probably bring up that's it's missing. - add the table print. this should be a template and not an option from the radio group. you can leave the statistics print as an option as it will be fed different type of data. this is nice-to-have if the GSoC timings allow it. - make all the default templates as close as they were in the old version! HTML/CSS work. for this one, just checkout a 4.x version of subsurface and print-screen how the 6 dives, 2 dives, 1 dive, table print look. - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. -- 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 Mon, Jul 20, 2015 at 5:27 PM, Gehad Elrobey gehadelro...@gmail.com wrote: On Jul 20, 2015 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 04:17:28PM +0300, Lubomir I. Ivanov wrote: - the cmake issues! can you even reproduce those? :-( No I couldn't, it always works correctly with me. this could be windows cmake specific, but it's quite bad as it breaks the entire build the second time make is called. if this is localized to me only, i guess i need to investigate why it happens...smells like a cmake folder recipe issue. if other users (e.g. someone on Linux) reports the same it becomes a high-priority issue, for sure! for anyone else reading that understands cmake, the error was: CMakeFiles\printing_templatesLink.dir\build.make:48: recipe for target 'CMakeFil es/printing_templatesLink' failed make[2]: *** [CMakeFiles/printing_templatesLink] Error 1 CMakeFiles\Makefile2:215: recipe for target 'CMakeFiles/printing_templatesLink.d ir/all' failed make[1]: *** [CMakeFiles/printing_templatesLink.dir/all] Error 2 I don't get this, either. And I usually build on my ArchLinux box with printing enabled. Same goes for the Windows and Mac builds... do you think the timings are OK for the pencils down date? what else is on your TODO list? Most of the remaining work is related to grantlee templates while the backend code is mostly finished, So I don't think I am late in the schedule, although I need to finish the templates and make them user ready as soon as possible, So as to have enough time for user documentation. ok, good to hear. Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] GSoC Printing: part 4
On Mon, Jul 20, 2015 at 04:29:50PM +0300, Lubomir I. Ivanov wrote: On 20 July 2015 at 16:22, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 03:48:32PM +0300, Lubomir I. Ivanov wrote: Part 4 of the new GSoC printing module from Gehad. I merged this. ATM this is useable, but the stock templates aren't pretty yet; an important thing on the TODO list is to get the already present templates to look similar to what we in the previous print module (i.e. user-ready). Yes, the templates are really ugly :-) But my biggest issue is that on my system (ArchLinux) I don't get any useful text at all. It looks like all the text boxes are compressed into thin orange lines. I can tell from the samples that Gehad sent that this isn't how it is supposed to look... any idea what's wrong here? seems to happen due to a font size of 0. i've already complained about that and Gehad said that i need to delete the local QSettings group (e.g. registry key on windows). once i've deleted the QSettings group and started Subsurface again the default font size of 9 worked as expected. not 100% sure why it happens but users should not encounter the issue. Yeah, that's an interesting set of settings I have there: [PrintDialog] color_palette=0 color_selected=true custom_color_1=#00 custom_color_2=#00 custom_color_3=#00 custom_color_4=#00 custom_color_5=#00 font=0 font_size=0 line_spacing=0 print_selected=true template_selected=0 type=0 Removing that fixed it. Adding some special handling that refuses to accept a font_size of 0 might not be a bad idea, but since regular users won't run into this (I assume this is the result of a buggy intermediate version I must have tried?) I'm not to concerned. Thanks for the quick response /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] GSoC Printing: part 4
On 20 July 2015 at 16:22, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 03:48:32PM +0300, Lubomir I. Ivanov wrote: Part 4 of the new GSoC printing module from Gehad. I merged this. ATM this is useable, but the stock templates aren't pretty yet; an important thing on the TODO list is to get the already present templates to look similar to what we in the previous print module (i.e. user-ready). Yes, the templates are really ugly :-) But my biggest issue is that on my system (ArchLinux) I don't get any useful text at all. It looks like all the text boxes are compressed into thin orange lines. I can tell from the samples that Gehad sent that this isn't how it is supposed to look... any idea what's wrong here? seems to happen due to a font size of 0. i've already complained about that and Gehad said that i need to delete the local QSettings group (e.g. registry key on windows). once i've deleted the QSettings group and started Subsurface again the default font size of 9 worked as expected. not 100% sure why it happens but users should not encounter the issue. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] GSoC Printing: part 4
On 20 July 2015 at 16:34, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 04:29:50PM +0300, Lubomir I. Ivanov wrote: On 20 July 2015 at 16:22, Dirk Hohndel d...@hohndel.org wrote: On Mon, Jul 20, 2015 at 03:48:32PM +0300, Lubomir I. Ivanov wrote: Part 4 of the new GSoC printing module from Gehad. I merged this. ATM this is useable, but the stock templates aren't pretty yet; an important thing on the TODO list is to get the already present templates to look similar to what we in the previous print module (i.e. user-ready). Yes, the templates are really ugly :-) But my biggest issue is that on my system (ArchLinux) I don't get any useful text at all. It looks like all the text boxes are compressed into thin orange lines. I can tell from the samples that Gehad sent that this isn't how it is supposed to look... any idea what's wrong here? seems to happen due to a font size of 0. i've already complained about that and Gehad said that i need to delete the local QSettings group (e.g. registry key on windows). once i've deleted the QSettings group and started Subsurface again the default font size of 9 worked as expected. not 100% sure why it happens but users should not encounter the issue. Yeah, that's an interesting set of settings I have there: [PrintDialog] color_palette=0 color_selected=true custom_color_1=#00 custom_color_2=#00 custom_color_3=#00 custom_color_4=#00 custom_color_5=#00 font=0 font_size=0 line_spacing=0 print_selected=true template_selected=0 type=0 Removing that fixed it. Adding some special handling that refuses to accept a font_size of 0 might not be a bad idea, but since regular users won't run into this (I assume this is the result of a buggy intermediate version I must have tried?) I'm not to concerned. Gehad, if you are reading this...can we get a confirmation that users installing the new print module for the first time will not encounter the 0-sized font issue, also things like font=0? do we need sanity checks for the settings group in case it's corrupted and we need to fallback to some default values? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
So I pushed these patches and learned that they require at least Qt5.3 as QBluetoothDeviceDiscoveryAgent::InvalidBluetoothAdapterError isn't defined yet in Qt5.2. But that got me thinking - what is actually the reasonable minimum version for QtBluetooth support to be enabled in Subsurface builds? I know that a lot of work went into this over the last couple of releases. Should we disable it unless the platform has Qt5.3? 5.4? 5.5??? Thiago, do you have input on that? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Add tooltip for geolocation lookup
Signed-off-by: Miika Turkia miika.tur...@gmail.com --- qt-ui/maintab.ui | 3 +++ 1 file changed, 3 insertions(+) diff --git a/qt-ui/maintab.ui b/qt-ui/maintab.ui index c83d12e..4390d04 100644 --- a/qt-ui/maintab.ui +++ b/qt-ui/maintab.ui @@ -213,6 +213,9 @@ property name=text string.../string /property + property name=toolTip + stringPerform a location lookup based on GPS information (country, city, body of water, etc.)/string + /property property name=icon iconset resource=../subsurface.qrc normaloff:/geocode/normaloff:/geocode/iconset -- 2.1.4 ___ 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 Jul 20, 2015, at 07:30, Miika Turkia miika.tur...@gmail.com wrote: Agreed. Better looking templates or at least templates that look closer to what we had. I'll admit that the shades of orange and beige color scheme isn't high on my list of favorites. If we really want to play with colors there, make it different shades of blue... this is about diving after all :-) I want to admit that I am not a clever color chooser, I will add another color theme with shades of blue. Did you try the Template Edit dialog? Can you make that resizable? First thing I did when opening up the editor was to try to increase the size of the text area. And that remains the same even though the window size is increased. Funny, that was my first reaction as well. And no, I haven't spent enough time with it. And I think it is well known that I am not great when it comes to colors and design and stuff... I'm sure we'll get some user contributed templates if we make it easy enough to do so. Which reminds me. How would one export / import a template? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ctrl-+ and Qt5.5
On Monday 20 July 2015 08:40:24 Thiago Macieira wrote: I have an external USB with numeric keypad in the office. I'll see if I can test that. Ctrl+KP_Plus works for me even without the patch. I can't tell what the patch is fixing then. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ctrl-+ and Qt5.5
On Monday 20 July 2015 05:54:17 Dirk Hohndel wrote: On Sun, Jul 19, 2015 at 07:43:19PM -0700, Thiago Macieira wrote: On Sunday 19 July 2015 19:38:25 Thiago Macieira wrote: On Sunday 19 July 2015 06:28:37 Gaetan Bisson wrote: [2015-07-19 17:06:48 +0300] Claudiu Olteanu: I have a Fedora 22 with Qt 5.5.0 and the shortcut is working. Subsurface version: 4.4.2-1040-g5cbbff008411c322. It might be related to this patch, then: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/keypa d-sh or tcuts.patch?h=packages/qt5 I'll ask our Qt maintainer. Testing it here. Doesn't fix the issue for me. I assume this is something that you will address upstream, Thiago - so we might get this fixed in 5.5.1 ? I was hoping to switch Mac and Windows builds to Qt5.5 soon but a regression like this is rather annoying. Since I'm building my own Qt packages on those two platforms it would be easy enough to cherry pick a fix if it was available. I'd apply the patch. It seems to fix Ctrl-+ when + is KP_Plus. That is not my case, as I don't have a numeric keypad. I have an external USB with numeric keypad in the office. I'll see if I can test that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
In general the mentor is not necessarily the clean up person... I know, Thiago offered, but just to put this out here. When I said that he should do some investigations I didn't mean to start hunting memory leaks on my code. I can do that by myself using their best friend - Valgring :). I just wanted to point out that I have more background in C and I don't have too much experience with C++ and Qt. Therefore, I certainly can do some design mistakes or I can make the code more complicated than it should be. I am more than pleased with the hints he gave me. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
On Monday 20 July 2015 06:59:30 Dirk Hohndel wrote: So I pushed these patches and learned that they require at least Qt5.3 as QBluetoothDeviceDiscoveryAgent::InvalidBluetoothAdapterError isn't defined yet in Qt5.2. But that got me thinking - what is actually the reasonable minimum version for QtBluetooth support to be enabled in Subsurface builds? I know that a lot of work went into this over the last couple of releases. Should we disable it unless the platform has Qt5.3? 5.4? 5.5??? Thiago, do you have input on that? I don't have anything exact in terms of functionality, but I'd say anything besides 5.4 and 5.5 is not a good idea, as no one is testing it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
Hi, I agree with Thiago. Probably it is a good idea to keep the Bluetooth download feature only for versions = 5.4. This is due the fact that in version 5.4 they added support for BlueZ 5.X stack and probably most of the users have this stack. To be honest I didn't take into account to test the implementation using a lower version than 5.4. If you want I can do that. I know that QtBluetooth library was introduced in version 5.2. The main feature from version 5.3 is that the module was ported to Android. Also both 5.2 and 5.3 versions have support only for Bluez 4.X. I expect the source code to work with Qt version 5.2 for a Linux platform with BlueZ 4.X (excepting the part where I tested that the discovery agent was successfully created). As I said before, I can create a new environment and I can do some tests for Qt 5.2 on Linux and for Qt 5.3 on Linux and Android. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Bluetooth improvements
On Mon, Jul 20, 2015 at 07:59:15PM +0300, Claudiu Olteanu wrote: Hi, I agree with Thiago. Probably it is a good idea to keep the Bluetooth download feature only for versions = 5.4. This is due the fact that in version 5.4 they added support for BlueZ 5.X stack and probably most of the users have this stack. To be honest I didn't take into account to test the implementation using a lower version than 5.4. If you want I can do that. I restricted this to 5.4 and newer. Changes to enforce that were pushed. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[GSoC] Week 8 (Native Bluetooth support)
Hello, Here is a summary about what I did last week: - tested and fixed some issues for Android platform - implemented a combobox which can be used to choose the local Bluetooth adapter - continue the documentation and developing the sample for Windows platform - created a new environment with Windows 7 - implemented the device discovery functionality and tested for Windows 7 and 8.1 (using MS stack) - implemented a service discovery functionality and tested for Windows 7 and 8.1 (using MS stack) Below you can find some things that I discovered and you should know: - there are 4 stacks for Bluetooth on Windows ( Microsoft, Widcomm, Stonestreet One Bluetopia Bluetooth and BlueSoleil) - not all devices work with the MS stack - Bluetooth functionalities like connection to serial devices was introduced in Windows XP SP2 - more details about Bluetooth support on Windows platforms [1] - I didn't find an API which can be used to control the local adapter (turn on/off, get/set device information) - I didn't find an API which can be used to pair/unpair devices Now I don't know exactly which version of Windows our users use. If it is greater than 8 then I am not sure if we should put effort on adding support for Window platforms. As you probably know from Thiago, on Qt 5.6 they are planning to add Bluetooth support for Windows 8.X and Windows 10. This will be released by the end of this year. What I know is that programming with Win32/Winsock2 API is quite tricky (at least for me..:) ). Also, after I installed the driver (BlueSoleil) for my dongle something went wrong and my sample with device discovery didn't work anymore. The only way to make it work again was to remove the BlueSoleil driver. To be honest I didn't expect to be harder to work on Windows :). Next I am planning to try to connect the devices and to do some data transfer. Claudiu [1] - https://msdn.microsoft.com/en-us/library/windows/hardware/dn133849%28v=vs.85%29.aspx?f=255MSPPError=-2147217396 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Fixes for Location selection on Mac
So, I was working in the location management but some of the things on mac where pissing me off - Wrong colors, Wrong selection marker and stuff like this. This fixes it. Let me continue on the other stuff here now. 0001-Code-uneeded-because-the-drawControw-does-this-by-it.patch Description: Binary data 0002-Try-to-fix-paint-issues-on-windows.patch Description: Binary data 0003-Use-correct-colors-on-selection.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 8 (Native Bluetooth support)
On Tuesday 21 July 2015 00:46:07 Claudiu Olteanu wrote: What I know is that programming with Win32/Winsock2 API is quite tricky (at least for me..:) ). Not just you. And it only gets worse with WinRT, which lacks even Winsock2... Fortunately, that's not a target for Subsurface. -- 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
