Re: Building on OSX
Em quinta-feira, 29 de dezembro de 2016, às 23:47:59 BRST, Dirk Hohndel escreveu: > Which version of Qt are you building against? > Qt 5.7 no longer includes the Qt5WebKitWidgets - and Qt 5.6 doesn't include > it by default (but you can build it from source). 5.5 should still include > it. You can build it from source in 5.7 too: http://download.qt.io/community_releases/5.7/5.7.1/ 5.8 will be the same. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Warn user about wrong characters in date/time format strings
On domingo, 23 de outubro de 2016 00:07:20 PDT Robert Helling wrote: > Subject: [PATCH] Warn user about wrong characters in date/time format > strings To: subsurface@subsurface-divelog.org > > fixes #1098 Technically speaking, they aren't invalid. You are allowed to set the date format to dd" de "MM" de " -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt theme ignored in AppImage
On segunda-feira, 26 de setembro de 2016 15:08:11 PDT Thiago Macieira wrote: > Is it Gtk3? The qgtk3 plugin would need to be supplied in the AppImage, > which could trigger including of the Gtk libraries in the AppImage too. Actually, Dirk could ship the plugin without the Gtk libraries. If the user has them in their system, the libs get loaded and the plugin works. If the Gtk libs are not present, then the plugin will fail to load and will be ignored by the Qt theme system. That may need some hacking of the AppImage scripts so that one .so is allowed to be shipped with "not found" libraries. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: BT on Mac
On domingo, 25 de setembro de 2016 12:47:23 PDT Dirk Hohndel wrote: > So we now have a few reports that this isn’t working anymore… > I can reproduce things here but have no clue how to fix it. > > First I get this error > > QObject::connect: Cannot queue arguments of type 'QBluetoothServiceInfo' > (Make sure 'QBluetoothServiceInfo' is registered using qRegisterMetaType().) I remember seeing this elsewhere. It might be a Qt bug. > which appears to be caused by this code in qtserialbluetooth: > > #elif defined(Q_OS_ANDROID) || (QT_VERSION >= 0x050500 && defined(Q_OS_MAC)) > // Try to connect to the device using the uuid of the Serial Port Profile > service QBluetoothAddress remoteDeviceAddress(devaddr); > serial_port->socket->connectToService(remoteDeviceAddress, > QBluetoothUuid(QBluetoothUuid::SerialPort)); > timer.start(msec); > loop.exec(); There's no QBluetoothServiceInfo in there. The only reference in the source code is serial_port->socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol); I don't remember the Bluetooth code implementation anymore (even though I mentored the student who wrote it). Is the code in qtserialbluetooth.cpp running in an auxiliary thread, started by libdc? I've attached a blind attempt at fixing this. I have no idea if it helps in any way. It may make things even worse. Can you run with QT_FATAL_WARNINGS=1 and then give me the backtrace of that QObject::connect warning? (this requires that Qt print no other warnings before this one) My guess is that this is the emission of the QBluetoothServiceDiscoveryAgent::serviceDiscovered signal starting at QBluetoothServiceDiscoveryAgentPrivate::performMinimalServiceDiscovery. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center >From 8634a0299afa65440b714d0831206c780a31a35a Mon Sep 17 00:00:00 2001 From: Thiago Macieira <thiago.macie...@intel.com> Date: Mon, 26 Sep 2016 14:59:55 -0700 Subject: [PATCH 1/1] Register the QtBluetooth metatypes for Qt Blind attempt. It looks like we're using a thread, which makes the Qt cross-thread signal delivery fail. Signed-off-by: Thiago Macieira <thi...@macieira.org> --- core/qtserialbluetooth.cpp | 5 + 1 file changed, 5 insertions(+) diff --git a/core/qtserialbluetooth.cpp b/core/qtserialbluetooth.cpp index 1b227cf..893be8a 100644 --- a/core/qtserialbluetooth.cpp +++ b/core/qtserialbluetooth.cpp @@ -89,6 +89,11 @@ static dc_status_t qt_serial_open(void **userdata, const char* devaddr) qDebug() << "Succesfully connected to device"; #else + // Register metatypes for Qt + qRegisterMetaType(); + qRegisterMetaType(); + qRegisterMetaType(); + // Create a RFCOMM socket serial_port->socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol); -- 2.10.0 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: thank you, Yahoo
On terça-feira, 12 de julho de 2016 17:05:19 PDT Dirk Hohndel wrote: > I'm not sure what the smartest course of action is, right now I'm thinking > I'll prevent people with Yahoo addresses from posting to our mailing list > and politely ask Axel and others to please get an email account with a > sane email provider like gmail... but before I do that... any other > suggestions how to work around this problem? There's an option in Mailman to rewrite if the sender has strict-DMARC requirement headers. I don't know what it is called, but we had to enable it in several other mailing lists I subscribe to. I will ask someone and let you know what it is called. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Time zones (again)
On sexta-feira, 1 de julho de 2016 11:04:32 PDT Robert Helling wrote: > Hi, > > > Am 23.06.2016 um 06:21 schrieb Robert C. Helling > > <rob...@euve10195.vserver.de>: > > > > Thanks for those comments. Will send an updated patch. > > here is the updated patch. Everything looks right, thanks Robert. The only minor thing is the indentation mistake in the last section: - diveplan.when = startTime.toTime_t(); + diveplan.when = startTime.toTime_t(); -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Set -std=c++11 flag for g++
On quinta-feira, 23 de junho de 2016 12:42:36 PDT Dirk Hohndel wrote: > No, careful. I’m grudgingly accepting the fact that we need to compile with > the -std=c++11 flag in order to build against Qt5.7. I am NOT ok with > including C++11 features in the code. I’d prefer my code to be readable. > Or to be more explicit - I don’t understand how the new features work, I > can’t parse the syntax, and if there is one thing that I have learned over > the past year it’s that I’m on my own when it comes to maintaining this. > So code that I don’t understand is not welcome. Of course. Unreadable code is never welcome and "unreadable" is quite subjective. We're having similar discussions in Qt itself as to how much of C++11 is acceptable. For example, the "Almost Always Auto" (AAA) suggestions have been denied and we'll continue to name our variables with the correct type, with a few exceptions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Re: Time zones (again)
On quarta-feira, 22 de junho de 2016 22:47:33 PDT Robert Helling wrote: > here is a patch which implements (I hope) what I promised. I did some quick > checks in particular with the planner (there it indeed fixes a bug reported > in the user forum which got me started in the first place thinking about > time zones again) but maybe I did not cover everything. More testing might > be advised. But looking at the code leaves me quite confident about it. > + timestamp.setTimeSpec(Qt::UTC); > + timestamp = QDateTime::fromString(date + " " + > time, "-M-d > hh:m:s"); The assignment on that second line erases any settings from the previous line. If you want to parse *as* GMT, the only way to do it is using ISO format and appending a "Z" to the target date. Something like timestamp = QDateTime::fromString(date + ' ' + time + 'Z', Qt::ISODate); Note: you need to ensure that the month, day and hour have leading zeroes. Alternatively, parse date and time separately, then create the QDateTime from the QDate and QTime objects. In many places: > QDateTime dt; > + dt.setTimeSpec(Qt::UTC); >[other code] > - dt.setTime_t(gt.when - gettimezoneoffset(gt.when)); > + dt.setTime_t(gt.when); Correct, but inefficient. Better would be: QDateTime dt = QDateTime::fromTime_t(gt.when, Qt::UTC); I've just realised that my recent changes in Qt 5.8 pessimises the default- constructed QDateTime on 32-bit systems, compared to 5.7... gotta fix it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Set -std=c++11 flag for g++
On quarta-feira, 22 de junho de 2016 14:59:49 PDT Dirk Hohndel wrote:
> > On Jun 22, 2016, at 2:49 PM, Thiago Macieira <thi...@macieira.org> wrote:
> >
> > On quarta-feira, 22 de junho de 2016 22:47:23 PDT Anton Lundin wrote:
> >> @@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL
> >> "AppleClang")
> >>
> >>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
> >>
> >> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> >>
> >>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
> >>
> >> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
> >> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
> >
> > You want to set it for AppleClang and Intel branches too. Do we support
> > building with MSVC at all?
>
> No. MinGW, gcc and clang
Ok, so the "Intel" branch above must be on Mac and Linux, which means it takes
the same syntax as GCC and Clang.
If it were on Windows, the syntax would be different, as it tries to be
compatible with MS's compiler.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Set -std=c++11 flag for g++
On quarta-feira, 22 de junho de 2016 22:47:23 PDT Anton Lundin wrote:
> @@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
You want to set it for AppleClang and Intel branches too. Do we support
building with MSVC at all?
Also note that GCC 6 defaults to C++14, so effectively this change
"downgrades" the default support. But that might be a good idea, to make
people using the latest GCC not add features that older compilers can't grok.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 14:34:38 PDT Thiago Macieira wrote: > Anyway, Qt API updated for 5.8: > https://codereview.qt-project.org/163231 It has just passed CI testing and is confirmed now for 5.8. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 22:43:04 PDT Robert Helling wrote: > QDateTime is time zone aware and by default it lives in the default system > time zone. So what we do is compute the number of seconds between 1 Jan > 1970 0:00 UTC and some date 5pm system time zone and the subtract > gettimezoneoffset() which is the difference between some date 5pm UTC and > 5pm system time zone. QDateTime::offsetFromUtc should give you that information too. It was added in Qt 5.2, which is acceptable for use in Subsurface now (it wasn't when we started). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 13:20:25 PDT Linus Torvalds wrote: > The problems for the kernel are all the embedded timeval pointers in > user space structures that get accessed through ioctl's (or things > like poll/select timeouts), or all the filesystems that have odd > timestamp limits (that may not be exactly 32-bit). Right, good point. At least x32 fixed it, but the IAMCU ABI didn't (not that it's likely to be extensively used with Linux). Anyway, Qt API updated for 5.8: https://codereview.qt-project.org/163231 -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 12:03:41 PDT Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 11:22 AM, Thiago Macieira <thi...@macieira.org> wrote: > >>fromTime_t(qint64, const QTimeZone); > > > > I can add that, but I can't add a qint64 toTime_t(), as you can't overload > > on return value. So it would only be a half solution. > > Can you at least make sure that the return value of "toTime_t" is > actually a "time_t". Not before Qt 6.0 (binary compatibility issue on 64-bit systems). As I said, that API is deprecated, which is why it's left unchanged and unfixed for some time. > Because seriously, the fix for 32-bit architectures is to make > "time_t" be 64-bit even there in user space. We already have most of > the system calls, so it's going to be about libc issues just switching > over to a 64-bit time_t. And because of that, I'd much prefer using a 64-bit type than time_t in our front-end API. If glibc provides a gettimeofday64, we can switch to using that without breaking user code again. Using syscall(3) is not a good idea since it would bypass the vDSO implementation, but a weak reference might do the trick. I don't see such functions yet in the latest git://git.kernel.org/pub/scm/ linux/kernel/git/torvalds/linux.git. I could only find the regular gettimeofday in kernel/time/time.c and the compat version in kernel/compat.c. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 10:26:50 PDT Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 9:08 AM, Thiago Macieira <thi...@macieira.org> wrote: > > That function is totally busted, as you've noticed. Not fixing is a > > discouragement, forcing people to find better alternatives. > > Quite frankly, not fixing it is just stupid. It doesn't force people > to find better alternatives, it just *annoys* people. > > Please just add another signature for the function that does > >fromTime_t(qint64, const QTimeZone); I can add that, but I can't add a qint64 toTime_t(), as you can't overload on return value. So it would only be a half solution. I can add an __attribute__((deprecated)) with info on which function to use. > instead of the current clearly broken mess. > > Or add a new > > fromSecsSinceEpoch() That I can easily do. We have addSecs() anyway, so why not that? > helper or something. Because "msecs" isn't really a sane format. It's > not something you get from *anything* else. Even when you are 64-bit > clean (perhaps exactly because you know your target is 64-bit), > nothing sane returns msecs. poll(2) and many other API uses milliseconds, including a lot of Win32 API (notably, WaitForSingleObject) and all of the Qt timeout-related API. We need consistency with ourselves at least. (the only exception to the rule is QThread::wait(), which takes a ulong, instead of qint64) As a twist of irony, since Qt 5.7, provided that the Glib integration is not active, Qt uses ppoll(2) on Linux and similar API on the BSDs, which take a timespec parameter. > So forcing those idiotic multiplications by 1000 is not "finding a > better alternative". It's just crazy crap, and makes the Qt date > handling look incompetent. Which it is. Because "time_t" really is not > "unsigned int", and has never EVER been that. If you don't want to multiply and divide by 1000, use milliseconds, since that's what QTime and QDateTime store internally. If I add the fromSecsSinceEpoch() and toSecsSinceEpoch(), that's what they'll be doing. The upcoming trend I see outside of Qt is to store things as nanoseconds, even though 2^63 ns is only 292.2 years. I much prefer timespec, since it gives me 94 bits of precision (plus sign bit). PS: Cocoa (Apple) API uses double... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Time zones (again)
On terça-feira, 21 de junho de 2016 01:09:16 PDT Linus Torvalds wrote: > The "fromTime_t()" function was an example of such a case : ostensibly the > right thing to use (converts from a time_t, which was exactly what we > wanted) but doesn't take a timezone input. We didn't update it with a timezone argument because... > Of course, "fromTime_t()" was then also completely broken in that it > limited the input to an unsigned integer, which was just incredibly broken > and doesn't actually match time_t at all. So the whole function was just > shit. But there may be similar gotchas elsewhere. That function is totally busted, as you've noticed. Not fixing is a discouragement, forcing people to find better alternatives. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.7.0 iOS issue
On sexta-feira, 17 de junho de 2016 10:14:44 PDT Dirk Hohndel wrote: > So here's a fun interesting issue with the official Qt 5.7.0 installer for > Mac (this one: > http://download.qt.io/official_releases/qt/5.7/5.7.0/qt-opensource-mac-x64-> > android-ios-5.7.0.dmg) > > The iOS part of this doesn't include the iOS Styles for QtQuick/Controls and > so an application built against this fails to start with > > WARNING: Cannot find style "iOS" > can't create window object Oops. But you can confirm that QtQuick Controls 1.x is indeed present, right? It's not like the entire module was removed. Sounds like a packaging issue then. Jani, can you take a look? > I filed a bug about this: > > https://bugreports.qt.io/browse/QTBUG-54192 > <https://bugreports.qt.io/browse/QTBUG-54192> > > Thiago, any idea whom I should poke about this (beyond filing the bug)? > > /D -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: so apparently Qt 5.7 was released
On quinta-feira, 16 de junho de 2016 07:00:50 PDT Dirk Hohndel wrote: > Not sure if it fixes any of our bugs, but it will likely cause problems for > the desktop version that still uses WebKit which was deprecated in 5.6 and > which I believe is now gone. So someone will have to spend the time to make > sure that Subsurface can be built both with Qt 5.5 and with Qt 5.7 - which > likely means that we will need duplicate code for the rendering of the user > manual and for the FB connector (those are the two I can think of right > now). QtWebKit is available still in 5.7 and we've made sure it builds, but that's about it. It might not be available in pre-built packages, but you can download the source and build (note: you probably want 8 GB of RAM or more to build, but I do build it on two machines with 4, so I know it works). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Build problems (qtTranslator)
On domingo, 1 de maio de 2016 21:11:20 PDT Dirk Hohndel wrote: > > On May 1, 2016, at 8:24 PM, Thiago Macieira <thi...@macieira.org> wrote: > > > > On domingo, 1 de maio de 2016 15:54:55 PDT Robert Helling wrote: > >> "_qtTranslator", referenced from: > >> init_qt_late() in libsubsurface_corelib.a(qt-init.cpp.o) > > > > The symbol is defined in the main application: > > > > export-html.cpp:QTranslator *qtTranslator, *ssrfTranslator; > > subsurface-desktop-main.cpp:QTranslator *qtTranslator, *ssrfTranslator; > > subsurface-mobile-main.cpp:QTranslator *qtTranslator, *ssrfTranslator; > > > > That means the tests will not link. The error appears to be legitimate. > > Dirk, did you have tests enabled in your build? > > Good point - I had the tests disabled at some point (which defeats their > purpose, doesn't it?). Patch sent. But not tested. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Move the qtTranslator and ssrfTranslator pointers to qt-init.cpp
No point in having it defined in each main program's .cpp. Especially
since the unit tests don't define them.
Signed-off-by: Thiago Macieira <thi...@macieira.org>
---
core/qt-init.cpp| 1 +
export-html.cpp | 3 +--
subsurface-desktop-main.cpp | 2 --
subsurface-mobile-main.cpp | 2 --
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/core/qt-init.cpp b/core/qt-init.cpp
index 5dc25f9..3dffc6f 100644
--- a/core/qt-init.cpp
+++ b/core/qt-init.cpp
@@ -5,6 +5,7 @@
#include "helpers.h"
char *settings_suffix = NULL;
+QTranslator *qtTranslator, *ssrfTranslator;
void init_qt_late()
{
diff --git a/export-html.cpp b/export-html.cpp
index 0c270c6..e030cb6 100644
--- a/export-html.cpp
+++ b/export-html.cpp
@@ -5,6 +5,7 @@
#include
#include "qt-gui.h"
+#include "qthelper.h"
#include "dive.h"
#include "save-html.h"
#include "stdio.h"
@@ -14,8 +15,6 @@
#include "windowtitleupdate.h"
#include "statistics.h"
-QTranslator *qtTranslator, *ssrfTranslator;
-
int main(int argc, char **argv)
{
QApplication *application = new QApplication(argc, argv);
diff --git a/subsurface-desktop-main.cpp b/subsurface-desktop-main.cpp
index 0bdad42..165d1f7 100644
--- a/subsurface-desktop-main.cpp
+++ b/subsurface-desktop-main.cpp
@@ -21,8 +21,6 @@
#include
#include
-QTranslator *qtTranslator, *ssrfTranslator;
-
static bool filesOnCommandLine = false;
int main(int argc, char **argv)
diff --git a/subsurface-mobile-main.cpp b/subsurface-mobile-main.cpp
index b7259c4..f32f11e 100644
--- a/subsurface-mobile-main.cpp
+++ b/subsurface-mobile-main.cpp
@@ -17,8 +17,6 @@
#include
#include
-QTranslator *qtTranslator, *ssrfTranslator;
-
int main(int argc, char **argv)
{
int i;
--
2.8.1
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Build problems (qtTranslator)
On domingo, 1 de maio de 2016 15:54:55 PDT Robert Helling wrote: > "_qtTranslator", referenced from: > init_qt_late() in libsubsurface_corelib.a(qt-init.cpp.o) The symbol is defined in the main application: export-html.cpp:QTranslator *qtTranslator, *ssrfTranslator; subsurface-desktop-main.cpp:QTranslator *qtTranslator, *ssrfTranslator; subsurface-mobile-main.cpp:QTranslator *qtTranslator, *ssrfTranslator; That means the tests will not link. The error appears to be legitimate. Dirk, did you have tests enabled in your build? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Latest iOS release
On domingo, 1 de maio de 2016 07:33:32 PDT Dirk Hohndel wrote:
> Oh I'm so tired of this Qt bug. Thiago, we really need to get this addressed
> in Qt. It's ridiculous that we keep running into this, keep trying to work
> around it, and randomly trigger it again. And right now building the mobile
> version on the desktop doesn't appear to trigger it, at least not for me. I
> don't see it on Android, either. It's only on iOS :-(
>
[cut]
> etc until stack is overflowing. :-(
>
> As you can see it alternates in setImpicitSize between 319x387 and 329x405 -
> I can see ~1400 layers of stack with this same sequence, all for the same
> object. I'm ready to just hack my own Qt that prevents such
> flip-flopping...
That means the layout is unstable. When asked for what its preferred size is
on qquicklinearlayout.cpp:414
const QSizeF pref = sizeHint(Qt::PreferredSize);
the answer does not stabilise.
I have absolutely no idea how the layout engine works. The only hint I have is
to check whether the constraints (the anchors) in whatever page is causing
this issue make sense.
> Unfortunately I haven't figured out how to get to the innards of this "this"
> pointer:
>
> (QQmlPrivate::QQmlElement *) $0 = 0x000132122370
> (lldb) p *this
> (QQuickItem) $1 = {
> QObject = {
> d_ptr = {
> d = 0x0001329b8f80
> }
> }
> QQmlParserStatus = {
> d = 0x
> }
> }
Try this:
p *(QQuickItemPrivate *)d_ptr.d
> Any idea how to get more information here? Or should I just hardcode a loop
> detection?
>
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Extend time parsing to before 1970
On quinta-feira, 28 de abril de 2016 16:17:15 PDT Linus Torvalds wrote: > That's very odd. It's *especially* odd since I'm doing this on x86-64, > which natively has a 64-bit signed time_t, and all the normal date > handling functions should just work fine. But Qt seems to have explicitly > screwed up here. > > Thiago? Historical raisins... In order to support multiple operating systems with dubious definitions of time_t (signed, unsigned, 32-bit, 64-bit), the API was crystallised on unsigned some time in the past. I'd advise against using this function that you found: > Looking at > >http://doc.qt.io/qt-5/qdatetime.html#fromTime_t-1 > > it just looks like "QDateTime::fromTime_t()" is completely and utterly > broken. Yep. But we have to carry it for compatibility. > I guess we could replace all those with > >QDateTime::fromMSecsSinceEpoch(when*1000, Qt::UTC) > > or something. I have *not* tested whether that works. That's what I recommend. The range is ± ~292 million years . It's also 64-bit even on 32-bit systems with time_t definitions unsafe after 2038. Which means you've got +1 from me on your second patch. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: QML question
On quarta-feira, 27 de abril de 2016 17:40:53 PDT Joakim Bygdell wrote: > Thomas or Thiago can you explain what’s going on here? > > I have a combobox that gets populated from a QStringList. > > If I generate the QStringList on the C++ side like so, > list << “foo” << “bar << “baz" > my combobox contains 3 elements as expected. > > If I populate the QStringList with data from the dive struct, > list << dive.buddy << dive.divemaster > the combobox is empty. > > In the later example the QStringList contains the expected data as I can > join the QStringList into a QString that displays correctly on the QML > side. The source of the data is not the issue here. That's a red herring. The problem is something else. 1) are you sure dive.buddy and dive.divemasters are non-empty strings? 2) is there anything special about the content of those strings? 3) can you show the code after that? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Better "make clean"? Or easier configuration?
On quarta-feira, 20 de abril de 2016 16:31:13 PDT Linus Torvalds wrote: > There's no "distclean" or similar target, but I *can* basically just do > > ccmake . > > and just hit 'c' and 'g' to (re-)configure and generate, and that does > fix the problem. Also: make rebuild_cache -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Meeting at QtCon?
On segunda-feira, 4 de abril de 2016 16:27:37 PDT Dirk Hohndel wrote: > On Tue, Apr 05, 2016 at 01:23:27AM +0200, Thomas Pfeiffer wrote: > > Hi everyone, > > is anyone of you maybe somewhere around Germany in the first week of > > September? If so, it would be great if we could meet at QtCon [1] in > > Berlin, which is surely an interesting conference for Subsurface > > contributors, and we could talk about Subsurface-mobile and Kirigami (or > > Subsurface and KDE Frameworks in general) face to face! > > Even better would be if someone could give a talk about > > Subsurface(-mobile), of course [2], but even just meeting in a workshop, > > in the halls or for a beer in the evening would be great as well. > > Looking forward to maybe meeting some Subsurface contributors, > > I am trying to arange a sponsorship and maybe land a keynote on Subsurface > and Subsurface-mobile... :-) > > Which obviously means that I'm hoping to be there. Ditto here, I'd like to be there. I need to sit down and think about which sessions to submit. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: signed vs unsigned
On quarta-feira, 23 de março de 2016 09:53:04 PDT Robert Helling wrote: > Anyway, my conclusion from all this trouble in the past was to _always_ use > the signed version since this prevents the trouble. As far as I can see, > the potential cost is that the maximally representable number is only half > the size but this should not be a problem for us since we stay safely away > from those limits. That is the recommendation of the C++ committee too, the very one that uses size_t for a lot of things. They recommend to always use signed integers, except where you explicitly need well-behaved modulo-2 overflows. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: SV: stack trace for the crash
On segunda-feira, 25 de janeiro de 2016 09:33:58 PST Saether Jan-Arve wrote: > I will try to reproduce it here and create a issue for it. Hello Jan Arve Did you manage to reproduce it? It's easily reproducible with Subsurface in 5.6.0rc, but it's not dissected to a testcase. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: New Bug Reports/Feature Requests
On terça-feira, 23 de fevereiro de 2016 15:46:44 PST Linus Torvalds wrote: > I don't have any hard data for this, but I think that what the > true capacity test does is let the air out and measure it. Which, > thanks to bernoulli's law will actually measure colder air than is in > the cylinder (air cools down when it expands), which in turn by boyle > will shrink the air (colder air is denser). You can do an isothermal expansion of air, or let the captured air warm back up to ambient temperature. Not that I expect people do it. But if they did, that would be a 3000 psi / 1 atm = 204.13x expansion in volume 11.1 L * 204.13 = 2265,9 L = 80.02 ft³ This is including the 11.1L of air at 1 atm that was left inside the bottle. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Divelogs.de import: encode + character on password
On segunda-feira, 22 de fevereiro de 2016 20:11:22 PST Miika Turkia wrote:
> Upload seems to work as is...
>
> - body.addQueryItem("pass", ui.password->text());
> + body.addQueryItem("pass", ui.password->text().replace("+", "%2b"));
Correct, as the documentation says:
\note This method does not treat spaces (ASCII 0x20) and plus ("+") signs
as the same, like HTML forms do. If you need spaces to be represented as
plus signs, use actual plus signs.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: C++ cout within Subsurface
On terça-feira, 9 de fevereiro de 2016 13:04:24 PST Tomaz Canabrava wrote: > Willem, > > Also do not include iostream on c code. ;) > And do what sebas said, plenty of debug examples on the code. qDebug() also requires C++ :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Fwd: Now Accepting GSoC 2016 Mentor Organization Applications
-- Mensagem encaminhada -- Assunto: Now Accepting GSoC 2016 Mentor Organization Applications Data: segunda-feira, 8 de fevereiro de 2016, 11:57:12 PST De: sttaylor <sttay...@google.com> Para: Google Summer of Code Announce Hello everyone, We are now accepting applications from open source projects interested in participating as mentor organizations for Google Summer of Code 2016. Visit our new website <https://g.co/gsoc> to apply as an organization today. For helpful tips on what is expected as a mentor organization and as a mentor or org admin for GSoC 2016 read the Mentor Manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/>. One person from your Org must act as an Organization Administrator and submit the application for your organization. The organization application process consists of 3 parts: 1. Application -- answering straightforward questions about why your org would like to mentor students in GSoC 2. Organization Profile -- details about your organization that will be used to attract students to your organization (short and long descriptions of your org, contact methods, etc.) 3. There must be at least 2 Organization Administrators per org. The Org Admin who creates the application will need to invite another person to be the 2nd Org Admin and that person will need to accept the invitation in order for this requirement to be met. Once these 3 sections are completed your application is done (you can see your progression on the site with the % complete visual). You can continue to edit your application until the deadline. Deadline to submit your Organization Application: Friday, February 19 at 19:00 UTC. Be sure to look at the timeline <https://summerofcode.withgoogle.com/how-it-works/> for more important dates for the program. We will not accept late applications under any circumstances. Good luck to all org applicants! Best, Stephanie Taylor -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-announce+unsubscr...@googlegroups.com. To post to this group, send email to google-summer-of-code- annou...@googlegroups.com. Visit this group at https://groups.google.com/group/google-summer-of-code-announce. For more options, visit https://groups.google.com/d/optout. ----- -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for the crash
On Friday 22 January 2016 09:31:38 Dirk Hohndel wrote: > #11 0x7fffe40607f7 in QQuickGridLayoutBase::geometryChanged > (this=this@entry=0x429ca50, newGeometry=..., oldGeometry=...) at > qquicklinearlayout.cpp:500 > #12 0x7529a3a4 in QQuickItem::setImplicitSize > (this=this@entry=0x429ca50, w=, h=h@entry=476) at > items/qquickitem.cpp:6350 > #13 0x7fffe406050d in QQuickGridLayoutBase::invalidate (this=0x429ca50, > childItem=0x4071360) at qquicklinearlayout.cpp:431 > #14 0x7fffe405ff7c in QQuickGridLayoutBase::rearrange (this=0x429ca50, > size=...) at qquicklinearlayout.cpp:572 > #15 0x7fffe40607f7 in QQuickGridLayoutBase::geometryChanged > (this=this@entry=0x429ca50, newGeometry=..., oldGeometry=...) at > qquicklinearlayout.cpp:500 Indeed, this looks like a qtquickcontrols bug. Whether this is caused by the Plasma Components or not, I don't know, but given that the repeating frames are entirely in Qt code, I don't think it is. QQuickItem::setImplicitSize calls the geometryChanged virtual (overridden by QQuickGridLayoutBase), which calls rearrange(), which loops over a list of items to invalidate: foreach (QQuickItem *invalid, d->m_invalidateAfterRearrange) invalidate(invalid); When invalidate() invalidates a child item, it may call setImplicitSize again. The code in 5.6 has changed a little, but the principles are still the same. Jan-Arve, JP, any hint you could offer? How is this supposed to work? -- 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: mobile ui todo
On Thursday 03 December 2015 20:18:10 Sebastian Kügler wrote: > This one may end up tricky, we'll have to do some surgery to get Plasma's > functionality in. It's a problem with the Android style, so perhaps that's > been fixed in Qt 5.6 (out next week). The 5.6 beta will be out next week, fingers crossed. As usual, stuff is delayed. Don't expect the final 5.6 until January. -- 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: [PATH] fix broken mac build on old clangs.
On Monday 09 November 2015 12:11:30 Dirk Hohndel wrote:
> > > private:
> > > PluginManager();
> > >
> > > - PluginManager(const PluginManager&) = delete;
> > > - PluginManager& operator=(const PluginManager&) = delete;
> > > + PluginManager(const PluginManager&){};
> > > + PluginManager& operator=(const PluginManager&){};
> > >
> > > };
> >
> > To me, that improves readability, since the = delete is clear in what it
> > does.
> Actually, I have not the faintest idea what it does.
Yeah, if you don't know the syntax, it's quite clear that it would be less
readable.
The = delete suffix tells the compiler "this function is deleted" (doesn't
exist). You use it only on functions that would otherwise exist if you don't
write anything, like the C++ "rule of 5" members:
* copy constructor: PluginManager(const PluginManager &)
* move constructor: PluginManager(PluginManager &&)
* copy-assignment operator: operator=(const PluginManager &)
* move-assignment operator: operator=(PluginManager &&)
* destructor: ~PluginManager()
In C++98, the rule was "rule of 3" because the move variants didn't exist.
Anyway, my recommendation is to remove the {} part. Just leave the
declarations with no corresponding implementation:
PluginManager(const PluginManager &);
PluginManager =(const PluginManager &);
With no implementation, even if you accidentally try to copy from somewhere
that can access the privates, you'll get a linker error later.
> > Moreover, it improves the error message in case you do accidentally try to
> > copy the object. And there's a silly error in the patch, that adds ; that
> > shouldn't be there.
>
> Which one?
You don't add ; after function bodies:
int main()
{
};
> But I have an important question in that context. Will you be required to
> use C++11 nonsense to USE Qt or will you be required to use a compiler
> that supports this nonsense to BUILD Qt?
No, you don't have to use any C++11 feature in your source code. The language
is almost entirely backwards compatible, so your existing C++98 code that used
to work will continue to work. Source compatibility is also very important for
Qt.
I can't think of anything that would require you to write a specific C++11
syntax to access new features either.
But Qt will require a C++11 compiler to compile its code and for all code
#include'ing a Qt header. That is, you will need to pass -std=c++11,
-std=c++14 or -std=c++1z to the compiler if you want to use Qt.
This is what you will get from qglobal.h if you compile in C++98 mode:
qbasicatomic.h:54:4: error: #error "Qt requires C++11 support"
# error "Qt requires C++11 support"
^
qbasicatomic.h:83:13: error: ‘QAtomicOps’ does not name a type
typedef QAtomicOps Ops;
^
In file included from ./QtCore/qglobal.h:1:0,
from :0:
qbasicatomic.h:86:23: error: ‘QAtomicOpsSupport’ was not declared in this
scope
[another 100 lines of errors relating to atomics]
> But what this might mean is that Subsurface will try to stay on Qt 5.6 for
> quite a while. Given that it's the long term release that may not be
> entirely unreasonable either.
And that's the point of a long-term release. Since we're going to increase the
compiler requirements, there will be one last release that can be compiled
with old compilers.
And since Apple, Microsoft, and QNX tie compiler versions to OS versions, this
has implications for some OS support too.
--
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: [PATH] fix broken mac build on old clangs.
On Monday 09 November 2015 19:33:55 Tomaz Canabrava wrote: > http://lists.qt-project.org/pipermail/development/2015-July/022219.html > > thiago's > > > > > answers made me stick with Qt side. > > > > links? is it in that same thread? That's a link to an email from Simon. I can't find my own answer, but it's in the same thread. My argument was that there's a difference in philosophy. CopperSpice is trying to push the envelope of what can be done with C++11, at the cost of leaving a lot of compilers and users behind. In fact, their source code cannot be compiled even with Microsoft Visual Studio 2015, the latest version. And it's entirely source-incompatible with the existing codebase, so it's a pain for people to migrate. Qt is a lot more conservative. Even the C++11 change I've been talking about here isn't wholesale. We will require a subset of the C++11 core language features and almost none of the C++11 Standard Library features, corresponding to the intersection of the GCC 4.7, Clang 3.3 and Microsoft Visual Studio 2012 support. Which is equivalent to the VS2012 support. Thanks Microsoft. -- 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: [PATH] fix broken mac build on old clangs.
On Sunday 08 November 2015 22:57:03 Dirk Hohndel wrote:
> > On Nov 8, 2015, at 10:41 PM, Thiago Macieira <thi...@macieira.org> wrote:
> >
> > Can you try adding the -stdlib option in the AppleClang branch to see what
> > happens?
>
> I have an odd question.
>
> Why?
Well, for one thing, because it would use libc++, which is maintained for
later versions of OS X, whereas GNU's libstdc++ is old and not updated by
Apple (GPLv3 controversy).
Both libs are good in their *current* versions. But Apple stopped updating
libstdc++ 8 years ago.
> What we have in master works.
>
> I have no interest in seeing Subsurface code made unreadable by C++11
> features - literally every thing I have seen so far from C++11 I find a)
> annoying b) not an improvement.
I partially agree and partially disagree. But I can say I don't like
gratuitous use of certain features just because they are there, if they reduce
readability. I'd much rather see a for loop initialising something than a call
to std::fill_n.
> - for(ISocialNetworkIntegration *plugin :
> PluginManager::instance().socialNetworkIntegrationPlugins()){
> + Q_FOREACH(ISocialNetworkIntegration *plugin,
> PluginManager::instance().socialNetworkIntegrationPlugins()){
Kind of a no-op change. I'd even say that lowercase "for" is less a sore in
the eyes than "Q_FOREACH". Why isn't it the lowercase "foreach" anyway?
> private:
> PluginManager();
> - PluginManager(const PluginManager&) = delete;
> - PluginManager& operator=(const PluginManager&) = delete;
> + PluginManager(const PluginManager&){};
> + PluginManager& operator=(const PluginManager&){};
> };
To me, that improves readability, since the = delete is clear in what it does.
Moreover, it improves the error message in case you do accidentally try to
copy the object. And there's a silly error in the patch, that adds ; that
shouldn't be there.
Maybe a compromise is to use Q_DISABLE_COPY(PluginManager).
> What is removed there to go back regular C++ is plain syntactic nonsense...
> the code that it brings back is actually readable and makes sense. So why
> would I want to spend time to figure out how to allow C++11 code in
> Subsurface?
Right. Those two above, even if minor improvements, are not worth the hassle.
What I'm trying to figure out is why it's a hassle in the first place. The
compiler that comes with Xcode 4.6 should be powerful enough. More
importantly, this shows there's a problem somewhere, somehow causing problems
building Qt applications and I should investigate it.
Qt 5.6 (the Long Term Release) should work with Xcode 4.6.
> All that said? I think I'm happy with just rejecting C++11 code and keeping
> our compilers focused on gnu99
Fair enough, but you won't get away with that for long :-P
Qt 5.6 will be the last release to support building in C++98 mode. Starting
with Qt 5.7, a great deal of C++11 will be mandatory and the minimum version
of Xcode will be 5.1.
--
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: [PATH] fix broken mac build on old clangs.
On Tuesday 10 November 2015 00:10:15 Lubomir I. Ivanov wrote: > constexpr specifically seems to have landed in msvc 2015 RTM. > http://blogs.msdn.com/b/vcblog/archive/2015/06/02/constexpr-complete-for-vs-> > 2015-rtm-c-11-compiler-c-17-stl.aspx Yeah, but it doesn't work. If you try Qt's tst_compiler test for constexpr, it fails. -- 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: [PATH] fix broken mac build on old clangs.
On Monday 09 November 2015 19:22:23 Tomaz Canabrava wrote: > it deletes the Copy Constructor and the operator=, if you don't declare > them the compiler will declare one anyhow. the way one does that in pre > c++11 is to declare an empty copy constructor and equal operator on the > private area, but they are implemented by the constructor, only hard to > reach. The usual way is to declare them without bodies in the private area. If you declare them the way you proposed, you can still accidentally copy from the class itself and its friends and that usually produces hard-to-track errors at runtime. C++98 error from non-friend: :1:13: error: ‘Foo::Foo(const Foo&)’ is private :1:98: error: within this context C++98 from friend or inside the class: :(.text+0x2b): undefined reference to `Foo::operator=(Foo const&)' C++11 error: :1:135: error: use of deleted function ‘Foo& Foo::operator=(const Foo&)’ :1:44: note: declared here Another tiny but relevant difference is that GCC reports the first error on the function declared private, which is very confusing to people. Clang reports both on the point of use, like GCC did for the deleted function case. -- 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: [PATH] fix broken mac build on old clangs.
On Sunday 08 November 2015 22:12:19 Tomaz Canabrava wrote:
> if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
> - set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu11 ")
> - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
> - set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu11 ")
> - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
Why? Anyone using Clang has a recent enough version of it that it supports
C++11.
GCC 5.0 and Clang 3.7 switched C mode to C11 by default (your patch reverts
that to C99); GCC 6.0 is switching to C++14 by default.
--
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: [PATH] fix broken mac build on old clangs.
On Sunday 08 November 2015 21:57:54 Tomaz Canabrava wrote: > They don't like c++11 They who? What's the error? Is that a build with the old GCC 4.2 instead of Clang? -- 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: [PATH] fix broken mac build on old clangs.
On Sunday 08 November 2015 21:02:53 Dirk Hohndel wrote:
> /Users/hohndel/Qt/5.5/clang_64/lib/QtCore.framework/Headers/qstring.h:739:5
> 5: error: no type named 'u16string' in namespace 'std'
Option -stdlib=libc++ to clang should fix this.
> /Users/hohndel/Qt/5.5/clang_64/lib/QtCore.framework/Headers/qstring.h:1053:1
> 7: error: exception specification in declaration does not match previous
> declaration
> inline QString::~QString() { if (!d->ref.deref()) Data::deallocate(d); }
> ^
> /Users/hohndel/Qt/5.5/clang_64/lib/QtCore.framework/Headers/qstring.h:219:12
> : note: previous declaration is here inline
> ~QString();
>^
This is a compiler bug. The exception specification is the same in both
declarations: empty.
> /Users/hohndel/Qt/5.5/clang_64/lib/QtCore.framework/Headers/qstring.h:1081:2
> 8: error: calling a private constructor of class 'QCharRef' { Q_ASSERT(i >=
> 0); return QCharRef(*this, i); }
>^
Also a compiler bug, since QString has been a friend of QCharRef since at
least Qt 4.0. More likely, there was a parsing error earlier.
Can you try adding the -stdlib option in the AppleClang branch to see what
happens?
--
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: [PATH] fix broken mac build on old clangs.
On Sunday 08 November 2015 20:00:13 Dirk Hohndel wrote: > Nope. Xcode 4 uses clang and throws up with c++11 > > And I need XCode 4 to build working binaries. We've been down this rat hole > before. I'm not switching compilers. Xcode 4.6 comes with a Clang based on the 3.2 branch of LLVM and that should have enough C++11 support for us, according thttp://clang.llvm.org/cxx_status.html. What were the errors? -- 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: cloud storage on Android
On Saturday 07 November 2015 11:20:20 Dirk Hohndel wrote: > And we had that fail for us which is why we went back to DataLocation... > > what a mess https://bugreports.qt.io/browse/QTBUG-49101 Nothing is being done because neither of the developers of QStandardPaths (David and I) do Android development. -- 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: trying to stop calling into the MainWindow
On Friday 06 November 2015 15:34:21 Lubomir I. Ivanov wrote:
> > connect( sender, ::method, receiver, ::method);
>
> method referencing in Qt, yey!
connect(sender, ::signal, receiver, <:=]{});
--
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: trying to stop calling into the MainWindow
On Friday 06 November 2015 11:14:05 Tomaz Canabrava wrote: > KGammaRay No K in GammaRay. http://www.kdab.com/gammaray/ https://github.com/KDAB/GammaRay -- 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: [RFC PATCH]: honor LC_TIME variable (somewhat)
On Tuesday 27 October 2015 10:58:17 Dirk Hohndel wrote:
> I'm sure I'm overlooking unintended consequences of this approach - which
> is why this is an RFC and not something I just committed to master
I'm not sure... this may be you're making a workaround instead of fixing it
properly 10 lines above.
Your change works and it's not an accident. QLocale() returns the default
locale, which is either something you set with QLocale::setDefault() or the
system one (same as QLocale::system()). The system locale on Unix systems
respects the multiple LC_* variables (at least LC_NUMERIC, LC_TIME,
LC_MONETARY and LC_MESSAGES).
There are two problems, though. The beginning of the function you modified has
this:
if (!s.value("UseSystemLanguage", true).toBool()) {
loc = QLocale(s.value("UiLanguage",
QLocale().uiLanguages().first()).toString());
} else {
loc = QLocale(QLocale().uiLanguages().first());
}
If the config file has UseSystemLanguage=false, does it follow that the user
does not want the system time format either? Or just the language
(LC_MESSAGES)?
Also, please note that this problem happens because of the else branch there.
It gets the name of the system locale and then looks up the QLocale data for
that name. As a consequence, you do not get the different settings if the LC_*
variables were set to different values. This can be solved by simply removing
that second branch. or replacing it with loc = QLocale()...
... except it was introduced in 2a8f32b8 "Fix date and time l10n", so there
may be a reason why.
--
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: crash on planning a dive with LANG=fi
On Sunday 11 October 2015 10:41:12 Dirk Hohndel wrote: > I notice the %S vs. %s - the man page doesn't mention upper case '%S', just > lower case '%s' The info page does: `%S' This is an alias for `%ls' which is supported for compatibility with the Unix standard. And later: `l' Specifies that the argument is a `long int' or `unsigned long int', as appropriate. Two `l' characters is like the `L' modifier, below. If used with `%c' or `%s' the corresponding parameter is considered as a wide character or wide character string respectively. This use of `l' was introduced in Amendment 1 to ISO C90. So %S is looking for a null-terminated string of wchar_t. Since the input string isn't wchar_t, it crashes on wcslen(). -- 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: Retina screen support
On Friday 09 October 2015 11:24:48 Dirk Hohndel wrote: > On Fri, Oct 09, 2015 at 08:19:12PM +0200, Robert C. Helling wrote: > > Dirk, > > > > > On 09 Oct 2015, at 20:16, Dirk Hohndel <d...@hohndel.org> wrote: > > > > > > I'll come up with a way to set this in the plist so that the official > > > binaries show the correct behavior > > > > sed to the rescue? > > Oddly that was the solution I thought of, first, but then I figured there > might be an "official way" to do this. Sadly the Qt documentation hasn't > quite come to the rescue, yet. There was something when we used qmake, but wasn't completely necessary and we don't use qmake anymore. -- 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] Fix 32-bit overflow in Divesoft Freedom time handling
On Saturday 03 October 2015 09:38:10 Anton Lundin wrote: > The root bug was mine. Another one of C's wonderful things that i didn't > know about. Yeah... unsigned short us = 0x; unsigned u = 0x; us * us;// this is undefined behaviour u * u; // this is fine -- 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 2/2] qtserialbluetooth: use QIODevice::Unbuffered io
On Tuesday 29 September 2015 21:59:31 Anton Lundin wrote: > - rc = device->socket->write((char *) data + nbytes, size - > nbytes); > + rc = device->socket->write((char *) data + nbytes, > size - nbytes > 16 ? 16 : size - nbytes); Yeah, that really shows the bug is probably in the receiving firmware, that it can't deal with block sends of differing sizes. -- 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: ostc BT download failure
On Tuesday 29 September 2015 17:25:34 Miika Turkia wrote: > Or it could be too old qt (5.4.1). Is there any easy way to upgrade to > 5.5 with poor Internet connection? Hi Miika, Sorry, no easy way to do that. The libraries are big... -- 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 2/2] qtserialbluetooth: use QIODevice::Unbuffered io
On Tuesday 29 September 2015 21:12:55 Anton Lundin wrote: > This adds the QIODevice::Unbuffered flag to our rfcomm connections to > bypass the buffering layer in QIODevice. > > This fixes so firmware upgrades work against the OSTC Sport. Both patches look good. The unbuffered mode should not have made a difference. If it does, it's probably a bug somewhere (the firmware receiving the update or QtBluetooth). -- 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: Bluetooth issue on Mac
On Sunday 27 September 2015 15:01:40 Dirk Hohndel wrote: > When trying to download from a BT dive computer on Mac (I tried this with > an OSTC Sport and with a Shearwater Petrel 2) I get this strange error > message: > > QObject::connect: Cannot queue arguments of type 'QBluetoothServiceInfo' > (Make sure 'QBluetoothServiceInfo' is registered using qRegisterMetaType().) Hmm... This means we're doing a cross-thread signal delivery and a parameter contains QBluetoothServiceInfo. I can't find such a signal in our source code. Dirk, I need a backtrace of that warning being printed... > Now when I add an attempt to register the type (i.e., adding > Q_DECLARE_METATYPE(QBluetoothServiceInfo) in qtserialbluetooth.c) then the > compile fails with > > /Users/dhohndel/src/subsurface-build/subsurface/qtserialbluetooth.cpp:18:1: > error: redefinition of 'QMetaTypeId' > Q_DECLARE_METATYPE(QBluetoothServiceInfo) That means the declaration already exists. It's the registration that is missing. > So it doesn't work if I don't declare the type, but it doesn't work either > if I DO declare the type. > > Any ideas? Well, a simple solution is to do exactly what it says: add a qRegisterMetaType(); somewhere before the object is used for delivery. I don't think we should do that, though: there's no signal or slot with QBluetoothServiceInfo in our code, so this must be coming straight from QtBluetooth and it means we've violated threading requirements somewhere. The only signal I can find with a QBSI parameter in QtBluetooth's source code is QBluetoothServiceDiscoveryAgent::serviceDiscovered with a corresponding slot in QBluetoothSocket, a class we're using. QBluetoothSocket starts the discovery when we call QBluetoothSocket::connectToService. But I don't see anything evident that would explain how the signal gets emitted from a different thread that the QBluetoothSocket would be running on... -- 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: Location management
On Thursday 24 September 2015 21:14:55 Miika Turkia wrote: > Did not help. > > ==32235== Process terminating with default action of signal 11 (SIGSEGV) > ==32235== Access not within mapped region at address 0x30 > ==32235==at 0x6DB4C90: > QAbstractEventDispatcherPrivate::allocateTimerId() (in > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.4.1) > ==32235==by 0x6DB5328: Is this a crash on exit? I don't see how the timer ID freelist could be null at any other point in time. -- 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: Windows binary saga
On Tuesday 22 September 2015 20:52:09 you wrote: > I notice that even though this is using Qt5.5 it still identifies itself > as "Windows" not "Windows 10" on my brand new Windows 10 laptop. > Thiago, any idea? You're probably using Qt 5.5.0. This is fixed for 5.5.1: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=8046a574d27b71ac9540b6cd3c029c2a83dd731e. -- 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: Windows binary saga
On Tuesday 22 September 2015 21:16:17 Dirk Hohndel wrote: > > On Sep 22, 2015, at 20:56, Thiago Macieira <thi...@macieira.org> wrote: > >> On Tuesday 22 September 2015 20:52:09 you wrote: > >> I notice that even though this is using Qt5.5 it still identifies itself > >> as "Windows" not "Windows 10" on my brand new Windows 10 laptop. > >> Thiago, any idea? > > > > You're probably using Qt 5.5.0. This is fixed for 5.5.1: > > > > http://code.qt.io/cgit/qt/qtbase.git/commit/?id=8046a574d27b71ac9540b6cd3c > > 029c2a83dd731e. > Yes, 5.5.0 > > When is the 5.5.1 release? > Either way, easy to add the fix. Imminent. I was told this morning that the code is frozen for the release, but it's missing the changelog... -- 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: QtWebKit is deprecated [was: Re: detecting Windows 10 [was: Re: [PATCH] Fix Bluetooth address truncation]]
On Sunday 20 September 2015 23:08:46 Lubomir I. Ivanov wrote: > On 20 September 2015 at 23:03, Thiago Macieira <thi...@macieira.org> wrote: > > On Sunday 20 September 2015 12:57:28 Dirk Hohndel wrote: > >> A major pain for Linux. > >> > >> Ubuntu 14.04 is on Qt 5.2 > >> Fedora 21 is on Qt 5.3 > > > > Sorry to make the problems worse, but some distros have declared that they > > will not carry qtwebengine because its chromium dependency (and the fact > > that it bundles a lot of libraries). Qt developers have been working with > > Google developers to unbundle chromium/qtwebengine, but I don't know how > > far along that has gone. > > wow... :( > so what are they planning to base it upon if it's not chromium and webkit? They're not. Those distributions have said they will not include any applications that depend on Blink. -- 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: QtWebKit is deprecated [was: Re: detecting Windows 10 [was: Re: [PATCH] Fix Bluetooth address truncation]]
On Sunday 20 September 2015 12:57:28 Dirk Hohndel wrote: > So I've spent four hours trying to get QtWebKit from Qt5.5 to compile > with MXE. No joy. None at all. And googling around several of the MXE > developers have tried and given up. What are the issues? I've built Qt 5.6 (including WebKit) on OS X, Windows and Linux in the past week. Note that webkit requires Perl, Python and Ruby interpreters to build. -- 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: QtWebKit is deprecated [was: Re: detecting Windows 10 [was: Re: [PATCH] Fix Bluetooth address truncation]]
On Sunday 20 September 2015 12:57:28 Dirk Hohndel wrote: > A major pain for Linux. > > Ubuntu 14.04 is on Qt 5.2 > Fedora 21 is on Qt 5.3 Sorry to make the problems worse, but some distros have declared that they will not carry qtwebengine because its chromium dependency (and the fact that it bundles a lot of libraries). Qt developers have been working with Google developers to unbundle chromium/qtwebengine, but I don't know how far along that has gone. -- 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] Fix Bluetooth address truncation
Patches look good. On Saturday 19 September 2015 19:40:05 Claudiu Olteanu wrote: > Hi there, > > There was an issue reported by Steve regarding the Bluetooth address > on Windows 10 platforms. The first patch should fix the problem. > > Claudiu -- 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: Beta Testing
On Wednesday 09 September 2015 07:23:34 Dirk Hohndel wrote: > I'm in a bit of a rush this morning (strangely, being up half of the night > caused me to oversleep in the morning...). But I believe that QSettings > can write an ini style file on all platforms. > Maybe one of the Qt experts can give a quick answer to that. Yes, it can. http://doc.qt.io/qt-5/qsettings.html#QSettings-4 It's the second argument to that constructor. -- 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: smoke testing Beta 1
On Thursday 03 September 2015 21:47:05 Dirk Hohndel wrote: > Turns out I need to build on an old OS X in order to have things run > correctly on older OS X versions (I'm building on 10.7 so people can run on > 10.7 or newer), but I then need to sign the resulting dmg on 10.9.5 or > newer in order for newer OS X version to recognize the signature. Thanks, > Apple, that's a really convenient workflow. You should be able to install an older XCode (4.x, probably) on your modern OS X. I installed 5.0 on my office machine to determine whether its compiler was broken (it is). The trick will be to teach Qt and cmake to use that toolchain... Maybe if you somehow move/symlink/whatever /Applications/XCode.app/Resources/Developer/XCodeToolchain.Default (or a similar name, see the full path to clang in Makefiles that qmake generates). -- 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: smoke testing Beta 1
On Thursday 03 September 2015 10:52:54 Dirk Hohndel wrote: > And while looking at this and being confused, I noticed this... > > (this is grepping for libGrantlee_Templates.5.dylib in the dtruss output) > [cut] > > So it finds and opens the shared lib successfully - and then looks for it > all over the place in the filesystem without finding it anywhere else. > WHAT? That must mean it concluded the file it did find and open wasn't a suitable plugin. Please run qtplugininfo on it: qtplugininfo /Volumes/Subsurface-4.4.96/Subsurface.app/Contents/MacOS/../Frameworks/libGrantlee_Templates.5.dylib Something in that metadata told QtCore that this isn't a suitable plugin. It's probably the version number. > So my summary so far - it finds the shared library and the plugins, but it > doesn't feel like using them for some reason? Yep. -- 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: smoke testing Beta 1
On Thursday 03 September 2015 13:45:58 Thiago Macieira wrote: > On Thursday 03 September 2015 10:52:54 Dirk Hohndel wrote: > > And while looking at this and being confused, I noticed this... > > > > (this is grepping for libGrantlee_Templates.5.dylib in the dtruss output) > > [cut] > > > So it finds and opens the shared lib successfully - and then looks for it > > all over the place in the filesystem without finding it anywhere else. > > WHAT? > > That must mean it concluded the file it did find and open wasn't a suitable > plugin. Please run qtplugininfo on it: > > qtplugininfo > /Volumes/Subsurface-4.4.96/Subsurface.app/Contents/MacOS/../Frameworks/libGr > antlee_Templates.5.dylib > > Something in that metadata told QtCore that this isn't a suitable plugin. > It's probably the version number. Another trick is to run subsurface with QT_DEBUG_PLUGINS=1. It will print why it discarded the plugin. -- 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: smoke testing Beta 1
On Friday 04 September 2015 00:01:28 Robert C. Helling wrote:
> Found metadata in lib
> /Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee_default
> tags.so, metadata= {
>
> "IID": "org.grantlee.TagLibraryInterface",
> "MetaData": {
> },
> "className": "DefaultTagLibrary",
> "debug": false,
> "version": 328961
>
> }
This looks fine. That version there is 0x50501 and is the same as the other
plugins that did get loaded.
But then the actual dlopen failed:
> loaded library
> "/Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee_defaul
> ttags.so" QLibraryPrivate::loadPlugin failed on
> "/Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee_defaul
> ttags.so" : "Cannot load library
> /Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee_default
> tags.so:
> (dlopen(/Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee
> _defaulttags.so, 5): Library not loaded:
> /Users/hohndel/src/install-root/lib/libGrantlee_Templates.5.dylib\n
> Referenced from:
> /Applications/Subsurface.app/Contents/PlugIns/grantlee/5.0/grantlee_default
> tags.so\n Reason: image not found)"
Looks like grantlee_defaulttags.so could not be loaded because
/Users/hohndel/src/install-root/lib/libGrantlee_Templates.5.dylib was not
found. Note the file path.
It seems the plugins were not properly deployed and the paths to the libraries
properly rewritten to find the library inside the bundle.
--
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: Re. subsurface: FTBFS in experimental
On Wednesday 26 August 2015 06:50:20 Dirk Hohndel wrote: And then there is Linux. 1/5th of the number of users that Windows has (for Subsurface). Even though on Windows there are tons of alternatives and on Linux there's nothing else. And we have all the developers here mixed into those numbers. And the fact that Linus started this certainly has gotten quite a few people interested in Subsurface. And we currently create 4 packages for Ubuntu (we can no longer build on 12.04 - just three years old - and Ubuntu no longer allows packages for 14.10). We reuse the same for Debian and have been called names for doing so. We have four packages for Fedora (F20 no longer builds). Six packages for SuSE. Etc, etc. The solution for this was supposed to be LSB. We'd have created one package that would install in all modern distros. But that's not an option, for multiple reasons and shared responsibility: 1) LSB is unmaintained. The LSB5 effort never happened, so we're stuck at 4.2 which is 6 years old. Most of the software we'd like to use is not available in LSB (namely: Qt 5) 2) Qt 5 doesn't support LSB because we haven't maintained it. Linux is just too full of goodies that we always want to use (inotify, futexes, pipe2, dup3, accept4). Building for LSB 4.2 would mean dropping those improvements. For some of them, I'd be willing to write workarounds or to fall back to non-Linux alternatives. For others -- especially the pipe2/dup3/accept4 trio and any OpenSSL 1.x calls -- I draw the line. They're required for thread-safety and security, so LSB had better update. 3) Subsurface requires the latest and greatest of Qt, which would never work inside LSB anyway (would have to stick to an old version). The solution here would be to bundle the libraries we use, the same way that we do for Windows and OS X: divecomputer, marble, Qt, ICU. -- 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: at some point we need to release Subsurface 4.5
On Thursday 27 August 2015 09:29:27 Dirk Hohndel wrote: Hmm - my binary is linked against QtBluetooth but there doesn't even appear to BE a QtConnectivity in Qt on my Mac... I see you've already fixed it but... QtBluetooth is a Qt module, so you'll have libQt5Bluetooth.so, libQt5Bluetooth.dylib, Qt5Bluetooth.dll, QtBluetooth.framework, as well as do #include QtBluetooth/Xxxx qtconnectivity (always written in lowercase) is the name of the Git repository and tarball that contains QtBluetooth. It also contains QtNfc. -- 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: Re. subsurface: FTBFS in experimental
On Wednesday 26 August 2015 17:40:28 Tomaz Canabrava wrote: I don’t know anything about CentOS, but these days I happen to build subsurface on Macs which only have homebrew which should be much more basic than any Linux distribution package manager. But here, I just have to install a few libraries (namely, quoting from the INSTALL file asciidoc libzip sqlite cmake libusb pkg-config automake libtool), then, and I admit that is a bit painful, install Qt5 from sources and all the rest You don't need to install qt5 from sources anymore ( for quite a while actually, I'v fixed that around six months ago ) And why is that? Because Qt bundles a lot of libraries (statically built into Qt libs and plugins). Example: libxcb. -- 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] Add native Bluetooth support for Windows platforms
On Wednesday 19 August 2015 00:57:20 Claudiu Olteanu wrote:
Hi there,
As I promised, I created a new set of patches. You can find it
attached to this e-mail.
Here is a list with the changes I did after the feedback:
- initialized the internal variables (patch 06)
Thanks!
- moved the *WSACleanup* call from patch 06 to patch 12
Good, like I said that is now better than Qt itself.
- removed the implementation of my internal *getLastError* and started
using *qt_error_string* (patch 11)
- used *WSAAddressToStringW* instead of *WSAAddressToStringA* (patch 11)
- avoided some code duplication (patches 14, 15, 17)
I hope that I covered all of Thiago's suggestions.
Yes, it does.
Also I didn't remove the call of strdup method from
*qtserialbluetooth::qt_serial_open *because the
*WSAStringToAddressA* method is expecting to receive
LPSTR {aka char*} parameter while I have the address
represented as const char*.
The Win32 API documentation says it's an input parameter. It's probably a
mistake on MSFT's part to have forgotten the const there. But let's not
tempt fate and we'll leave it with the strdup.
I tried as well to replace the WSAStringToAddressA with
WSAStringToAddressW but I had to represent the
address as a wchar_t* and and when I wanted to use
mbstowcs_s for conversion (from const char* to wchar_t*)
the compiler couldn't find the declaration to the method
(even though I included the stdlib header). After some
failed attempts I gave up :).
Like I said, never, ever use wchar.h functions. Those are braindead in
design, at least compared to Qt's equivalents.
Before I go into this, let me say that the patches are fine and Dirk can apply
them as-is. There's no need to change further.
With that now said, here's how you can improve. Your code is:
+ char *address = strdup(devaddr);
[...]
+ if (WSAStringToAddressA(address,
+ AF_BTH,
+ NULL,
+ (LPSOCKADDR) socketBthAddress,
+ socketBthAddressBth
+ ) != 0) {
+
To use the W function:
QString address = QString::fromLatin1(devaddr);
if (WSAStringToAddressW(reinterpret_castwchar_t*(address.utf16()),
[...]
This also solves the strdup() and free() calls. And if the line didn't get too
long, you could do everything in one line.
--
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: [PATH] Add native Bluetooth support for Windows platforms
the information about the local device Note that you still call WSACleanup even if WSAStartup failed. That should hopefully never be a problem and I'm not holding you to fixing this because... well, I've just done the same in Qt itself and I realise that we've done that for 15 years -- probably since QSocket was introduced in Qt 2.1. Subject: [PATCH 14/17] Add implementation for add remote Bluetooth device handler #if defined(Q_OS_WIN) - // TODO add the remote device + QString deviceLabel = QString(%1 (%2)).arg(remoteDeviceInfo.name()).arg(remoteDeviceInfo.address().toString ()); + QListQListWidgetItem * itemsWithSameSignature = ui-discoveredDevicesList-findItems(remoteDeviceInfo.address().toString(), Qt::MatchContains); [...] #else QString deviceLabel = QString(%1 (%2)).arg(remoteDeviceInfo.name()).arg(remoteDeviceInfo.address(). toString()); QListQListWidgetItem * itemsWithSameSignature = ui-discoveredDevicesList-findItems(remoteDeviceInfo.address().toString(), Qt::MatchContains); Please merge as much of the code as you can. The first two (or more) lines of the two branches of the #if are identical, so it's a good idea to keep them together to avoid code duplication. Ditto on patch 15. -- 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] Add native Bluetooth support for Windows platforms
On Wednesday 19 August 2015 00:57:20 Claudiu Olteanu wrote: I tried as well to replace the WSAStringToAddressA with WSAStringToAddressW but I had to represent the address as a wchar_t* and and when I wanted to use mbstowcs_s for conversion (from const char* to wchar_t*) the compiler couldn't find the declaration to the method (even though I included the stdlib header). After some failed attempts I gave up :). Hi Claudiu I will review the patches again tonight. Please don't use anything from wchar.h like mbstowcs or whatever. Just use QString::fromUtf16 and toLocal8Bit or toLatin1, depending on context. I will take a look at the code when I review and suggest how to do 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: [PATH] Add native Bluetooth support for Windows platforms
On Tuesday 18 August 2015 12:31:53 Claudiu Olteanu wrote: Thank you for your detailed explanation! I didn't know about the difference between the W functions on Windows instead of the A ones. Since I will create a new set of patches I will try to add all the things you suggested. Hi Claudiu Please do this only if you can do it quickly. Your code is correct, just a little inefficient. If it isn't straightforward, please keep it as-is and provide a patch later to fix 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: Testing Native Bluetooth support on Windows platforms
On Tuesday 11 August 2015 23:36:05 Claudiu Olteanu wrote: I totally forgot about the existence of Windows Vista :) We wish we had that option too. -- 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: Grantlee problems
On Wednesday 29 July 2015 11:05:58 Robert Helling wrote: (Parent is Grantlee::Parser(0x7fff5fbfb8f8), parent's thread is QThread(0x104d2da60), current thread is QThread(0x11d4b9240) QObject::setParent: Cannot set parent, new parent is in a different thread I don’t know how threads enter here but maybe this is the progress bar? I had a similar error before when trying to show a modal dialog from a thread that was not the main thread. But this is how far my experience takes me. Then a bit later, in line 92 htmlContent = t-render(c); I get the error Don't know how to handle metatype The errors are related. Since there was a threading issue, the signal-slot connections changed from direct connection to queued, which in turn requires handling the copy of the types. Let's first fix the threading problem. Please run subsurface with QT_FATAL_WARNINGS=1 and give us a backtrace of that warning complaining threading issue. Since we're talking about threading issues, an all-thread backtrace would be adviseable (gdb command: t a a bt) -- 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: Grantlee problems
On Thursday 30 July 2015 22:41:20 Robert C. Helling wrote: is it possible to do this more specifically, since the thread warning is by far not the first, it starts with (independent of grantee and printing) No, sorry. It's a hammer only. qWarning was designed to indicate programming errors. Map theme file does not exist: This is not a warning. The code in question should be fixed to a qDebug instead. QFSFileEngine::open: No file name specified This is a programming error. The code should be fixed not to try to open a file without saying *which* file it wants to open. Set the current dive site: 756762654 This is also a debug statement, not warning. -- 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 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
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: [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
Re: Ctrl-+ and Qt5.5
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-shor tcuts.patch?h=packages/qt5 I'll ask our Qt maintainer. Testing it here. -- 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
On Sunday 19 July 2015 23:25:17 Claudiu Olteanu wrote: 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 That's what I call misleading information... That means it doesn't include OpenDarwin. Fix: https://codereview.qt-project.org/121841 -- 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 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. -- 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 Sunday 19 July 2015 06:47:32 Dirk Hohndel wrote: ArchLinux updated to Qt5.5 and it seems that with that the Add Dive shortcut Ctrl-+ went away. Am I making this up or could something in Qt5.5 have broken that? Is Ctrl-+ working for others? Which version of Qt are you using? That's an upstream bug. All Ctrl+Shift shortcuts stopped working in 5.5, such as Qt Creator's Ctrl+. I tried to debug this during the Qt Contributor Summit but didn't get anywhere. -- 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
On Saturday 18 July 2015 23:55:35 Claudiu Olteanu wrote:
Subject: [PATCH 3/8] Don't block the save button for Bluetooth device
selection
After commit #69a75fed05fc3 we don't need to block the save
Dirk, please remember to update the commit SHA-1 after you cherry-pick patch 1
:-)
Subject: [PATCH 4/8] Add combobox for Bluetooth local device selection
Add a combobox which can be used to list/select the available
local Bluetooth devices. In this way, if a user has more
than one local Bluetooth devices (integrated, dongles, etc.)
he can choose which one he wants to use.
Before this patch, only the default local Bluetooth device
could be used.
Claudiu, most people only have one local bluetooth device. We shouldn't
display a list to select an entry if there's only one entry to be selected.
Can you hide the list if the list contains only one?
Subject: [PATCH 4/8] Add combobox for Bluetooth local device selection
+void BtDeviceSelectionDialog::localDeviceChanged(int index)
+{
+ QBluetoothAddress localDeviceSelectedAddress =
ui-localSelectedDevice-itemData(index,
Qt::UserRole).valueQBluetoothAddress();
Where is this deleted? Does QBluetoothLocalDevice take ownership?
+
+ // Delete the old localDevice
+ if (localDevice)
+ delete localDevice;
Hint: no need to check for null before deleting. Delete does that for you.
+
+ // Create a new local device using the selected address
+ localDevice = new QBluetoothLocalDevice(localDeviceSelectedAddress);
+ case QBluetoothDeviceDiscoveryAgent::PoweredOffError:
+ errorDescription = QString(The Bluetooth adaptor is powered
off, power it on before doing discovery.); + break;
+ case QBluetoothDeviceDiscoveryAgent::InputOutputError:
+ errorDescription = QString(Writing or reading from the
device resulted in an error.); + break;
+ default:
+ errorDescription = QString(An unknown error has
occurred.);
+ break;
+ }
+
+ ui-dialogStatus-setText(QString(Device discovery error:
%1.).arg(errorDescription));
All of those QString() should be tr() so they cna be translated. I haven't
checked previous patches for this...
+#elif defined(Q_OS_ANDROID) || (QT_VERSION = 0x050500
(defined(Q_OS_IOS) || defined(Q_OS_OSX)))
Hint: Q_OS_DARWIN and Q_OS_MAC also mean Q_OS_IOS || Q_OS_OSX.
--
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
On Sunday 19 July 2015 22:23:46 Claudiu Olteanu wrote: Claudiu, most people only have one local bluetooth device. We shouldn't display a list to select an entry if there's only one entry to be selected. Can you hide the list if the list contains only one? Of course I can do. One of the attached patches (#0009) should do the trick. Thanks. The other patches look good too. Where is this deleted? Does QBluetoothLocalDevice take ownership? This information should remain until the widget is destroyed. I thought that it will be automatically deleted when I delete the *ui *instance. Should I manually clean his children? 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? All of those QString() should be tr() so they cna be translated. I haven't checked previous patches for this... None of the patches uses tr() . I will create a patch in the end which will do the translations. Ok. +#elif defined(Q_OS_ANDROID) || (QT_VERSION = 0x050500 (defined(Q_OS_IOS) || defined(Q_OS_OSX))) Hint: Q_OS_DARWIN and Q_OS_MAC also mean Q_OS_IOS || Q_OS_OSX. I saw that Q_OS_MAC doesn't include the open source version and I didn't know which is that :). Huh? #if defined(Q_OS_DARWIN) # define Q_OS_MAC [...] # if defined(TARGET_OS_IPHONE) TARGET_OS_IPHONE # define Q_OS_IOS # elif defined(TARGET_OS_MAC) TARGET_OS_MAC # define Q_OS_OSX # define Q_OS_MACX // compatibility synonym # endif #endif -- 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 support for Android
On Wednesday 15 July 2015 22:08:48 Claudiu Olteanu wrote: This method should work on every supported platforms but I cannot obtain the correct result using it on Linux. I mentioned before that I believe there is a bug on the QtBluetooth library because when I start a full SDP discovery agent I cannot find the SPP service from my HW OSTCs device. The same thing happened on Rick's environment with his Petrel2 device. I sent some e-mails on the qt-interest list but I didn't receive any response to the last one. It's July. Alex may be on his 4-week vacation. Ping him again next week to see if he's back. -- 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 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
Re: different segfault with lastest master
On Saturday 11 July 2015 19:28:42 Tomaz Canabrava wrote: On Sat, Jul 11, 2015 at 7:00 PM, Linus Torvalds torva...@linux-foundation.org wrote: #0 0x7fffefa67a98 in raise () at /lib64/libc.so.6 #1 0x7fffefa6972a in abort () at /lib64/libc.so.6 #2 0x7fffefaaaea2 in () at /lib64/libc.so.6 #3 0x7fffefab3ef8 in _int_malloc () at /lib64/libc.so.6 #4 0x7fffefab6b5e in malloc () at /lib64/libc.so.6 #5 0x7042d453 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlagsQArrayData::AllocationOption) () at /lib64/libQt5Core.so.5 #6 0x704b9b1f in QString::QString(int, QChar) () at /lib64/libQt5Core.so.5 #7 0x704978f7 in QLocalePrivate::dateTimeToString(QString const, QDateTime const, QDate const, QTime const, QLocale const*) const () at /lib64/libQt5Core.so.5 This crash is not related to subsurface but to Qt, I'm not sure what happened there but did you updated your Qt and didn`t compiled Subsurface after update? The #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () line tells me that this Qt fault, we are passing a stack variable to a QDateTime and it`s getting corrupted inside an internal impelmentation of QArrayData Thiago? It crashed inside malloc, so the problem is not in the stack trace. Something corrupted the malloc structures. Valgrind would have been the best, but didn't work... -- 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: Make marble compile with Qt 5.5 on OSX
On Thursday 09 July 2015 16:22:54 Tomaz Canabrava wrote: it seems that QDataStream was removed from some includes Sorry about that; that was my change. It was removed from qstringlist.h, which means that QIODevice is not present from qstringlist.h and that brought qobject.h. -- 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: [GSoC] Week 6 (Native Bluetooth support)
On Wednesday 08 July 2015 11:47:18 Claudiu Olteanu wrote: I am not sure how I can help you with this. I don't have a Mac device. I could try to install OSx on a virtual machine. The only way you're allowed to run OS X in a VM is if you have genuine Apple hardware, which usually implies you've already got access to OS X in real hardware anyway... -- 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: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 22:03:52 Dirk Hohndel wrote: I tried testing on Ubuntu, also in a VM on the same Mac. But I can't seem to figure out which package to install to get the QtBluetooth stuff. Any suggestion on the right package names? This needs to be added to the INSTALL file, too... It should be libqt5bluetooth5, according to packages.ubuntu.com. -- 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: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 23:00:08 Claudiu Olteanu wrote: Thiago, do you have a dive computer with Bluetooth support? Do you believe that you can help me with some tests? No, I don't have one. I could probably borrow one from Dirk, but please don't expect a lot of availability to do debugging... /me goes back to reviewing IPv6 support for the IoT software -- 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: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
On Monday 06 July 2015 23:19:58 Claudiu Olteanu wrote: + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); That's slightly weird :-) I know that this is weird but there is no HostPoweredOn enum :-). It can be either off, connectable, discoverable or discoverable limited inquiry. Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == QBluetoothLocalDevice::HostConnectable || ..) I meant doing bool on = !(x == y); instead of bool on = x != y; -- 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: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 21:41:37 Claudiu Olteanu wrote: libsubsurface_corelib.a(libdivecomputer.c.o): In function `do_libdivecomputer_import': /home/claudiu/gsoc/subsurface/libdivecomputer.c:930: undefined reference to `dc_serial_qt_open' The method is declared as external C and is implemented in qtserialbluetooth.cpp source. I don't know what changed from Qt 5.4.1 version to Qt 5.5.0 because it worked before the Qt update. nm -C qtserialbluetooth.o Does it appear? Does it appear with () at the end? -- 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: great progress on dive site handling
On Monday 29 June 2015 06:59:55 Dirk Hohndel wrote: (gdb) bt #0 Marble::StackedTile::pixel (this=0x0, x=36, y=30) at /home/mturkia/source/static/test/marble-source/src/lib/marble/StackedT ile.cpp:85 Hmm. this=0x0 - that would explain the crash when accessing a member of this object. But how the heck did you get there? #1 0x7654036c in Marble::ScanlineTextureMapperContext::pixelValueApprox (this=0x7fff748dbd50, lon=optimized out, lat=optimized out, scanLine=0x240b660, n=optimized out) at /home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineT extureMapperContext.cpp:316 Happens to me quite frequently. Once I have working Internet, I'll try to do full build.sh and see if that helps. If I take this stack trace at face value it really doesn't make much sense. It shouldn't be crashing where it claims to be crashing. It this in StackedTile::pixel really was NULL it should crash in the caller when trying to dereference the member function. Thiago, any brilliant insights? Line 315-316 is: *scanLine = m_tile-pixel( ( ( iPosXf 7 ) + m_vTileStartX ) m_deltaLevel, ( ( iPosYf 7 ) + m_vTileStartY ) m_deltaLevel ); And frame 0 is StackedTile::pixel, so I conclude that m_tile is NULL and StackedTile::pixel is not a virtual function. m_tile had not been used yet in this function, so it's possible it was really null. m_tile is initialised to NULL in the constructor and is only assigned to in ScanlineTextureMapperContext::nextTile (both overloads). I also note that there are a couple places where m_tile is checked for NULL, but not in others. Both cases where m_tile is accessed without checking for null is preceded by a call to isOutOfTileRange. That's all I can tell: I don't know if m_tile is correctly supposed to be NULL there and the code should be checking for validity before dereferencing; or if it wasn't supposed to be NULL and loading of the tile was required. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: great progress on dive site handling
On Monday 29 June 2015 11:07:08 Dirk Hohndel wrote:
Thanks Thiago for taking a look. It confused me that this would thrown a
SIGSEGV in the pixel() function and not when dereferencing m_title to get
to the pixel member function...
It wouldn't because pixel() is not a virtual function.
A non-virtual member function is just a regular function, called by name,
which takes an implicit first parameter that is the object in question.
For
struct Foo { void f(); };
Foo *foo;
The code
foo-f();
is equivalent to
_ZN3Foo1fEv(foo);
There's no pointer dereferencing before the actual call is placed, which is
why it only crashed inside the function, not before it.
To be clear, it's undefined behaviour to do the above on foo = NULL. But UB can
take many forms, including working as expected.
There's some on-going discussion in the C++ standards group to allow the code
f-foo();
to find a free function foo(Foo*) and call that. It's called Unified call
syntax [1] and I actually triggered that discussion about a year and a half
ago after seeing Linus rant here about some quirk of C++ :-)
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Warning. Danger. Dragons ahead
On Friday 19 June 2015 12:06:58 Dirk Hohndel wrote: And uses colons for time. hh:mm:ss and that breaks on Windows because a colon is illegal in a file or directory name. So in order for cloud storage to work on Windows I needed to change the encoding. I picked the equal sign as it is visually similar and seems to be legal on all the file systems. Why have separators at all? MMDDHHmmss should be enough until Dec 31st, . -- 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: Current git no compilee
On Tuesday 16 June 2015 20:31:01 Dirk Hohndel wrote: I suspect you compile without debugging, so that the Q_ASSERT_X() goes away. I compile with debugging. No idea why this didn't get me... You may be compiling with debugging but with QT_NO_DEBUG set. The default of QT_DEBUG / QT_NO_DEBUG is that of Qt itself. qmake would set QT_DEBUG if you compiled in debug mode, but CMake may not be doing that, so you inherited the Qt default (release mode). -- 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
Fwd: [Development] Bluetooth support for Windows (RT/10) in Qt 5.6
FYI -- Forwarded Message -- Subject: [Development] Bluetooth support for Windows (RT/10) in Qt 5.6 Date: Tuesday 16 June 2015, 12:42:21 From: Kalinowski Maurice maurice.kalinow...@theqtcompany.com To: developm...@qt-project.org developm...@qt-project.org Hi everyone, It might sound weird that while we're trying to get 5.5.0 out I am starting a discussion about Qt 5.6, but if you look at the release schedule there is not much time for the feature freeze https://wiki.qt.io/Qt-5.6-release One of the items the Windows / WinRT team would really like to see included to that release is support for Bluetooth and BTLE. The current idea is to use the WinRT API for that backend, as it provides the advantage that it can also be used on Windows Desktop starting Windows 8(.1). WinRT covers Windows 10 support (both classic and Unified Windows Platform) as well. This leaves out support for Windows Desktop older than Windows 8. But as we are aiming to implement new features, we should draw the line somewhere and the WinRT backend clearly has the biggest potential to be supported in many years' time, while the (or multiple) pure desktop solution would be deprecated sooner or later again. Also given the fact that we can target quite many platforms with one backend gives us a better coverage for maintenance and resourcing. The reason that I am mentioning this on the mailing list is that after talking to some folks here in The Qt Company, multiple people inside and outside already started or wanted to start efforts on this topic. Hence the aim of this email is to get everyone connected and work on it together to make it happen within the 5.6 feature freeze. So, if you have worked on Bluetooth (LE) on Windows or want to, please get in touch with me to align. BR, Maurice Maurice Kalinowski - Senior Manager, Qt Tools The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: maurice.kalinow...@theqtcompany.com | Mobile: + 49 175 187 19 52 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list developm...@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - -- 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
