d1vanov / qevercloud Goto Github PK

Hello,

According to Debian Policy (and REJECT faq), the generated files must be provided together with its original form (and must be guaranteed to be able to be regenerated from the original form), otherwise it needs to be wiped completely from the source code.

Your package contains generated files (such as compressed .js libraries) without corresponding
original form. They're not considered as the preferred form of modification, so you will either have to
provide corresponding original form, or remove them from your tarball, eventually depending on an
already available packages to provide missing features.

Could those files generated from Evernote Thrift API be regenerated in some ways? If possible, could you please provide with an example (e.g., the original source needed and some example shell commands)? That will help make QEverCloud suitable for entering Debian.

Thanks!

Hello,

I noticed that the SONAMEs for this library are libqt5qevercloud.so.3 and libqt4qevercloud.so.3, while all other Qt libs capitalise the 'q', e.g. libQt5PrintSupport.so.5.

Is this deliberate?

Thanks.

qrand has been deprecated since Qt 5.10, QRandomGenerator should be used instead. Need to change the source code in OAuth.cpp accordingly and update README which currently says that client applications need to call qsrand before using the library. It seems it would not be needed after the migration to QRandomGenerator.

Some distributions (yes, I mean debian) does not ship qt5webengine. It would be great if we have a configure-time switch to force the selection of qtwebkit / qtwebengine rather than doing wild-guess using Qt version.

This means some rewrite of QEvercloud/cmake/modules/QEverCloudSetupQt.cmake.

The advantage of doing so would be to enable introspection - it would be easy to e.g. loop over the struct's properties in order to do anything with them - print them, compare them for equality etc.

Since types are autogenerated, the code change to implement this idea would belong to QEverCloudGenerator project.

Finally QEverCloud 3.x library entered Debian official repository (https://tracker.debian.org/pkg/qevercloud). This library will be available in Debian Stretch (Debian 9), Ubuntu 17.04 and later derivatives.

Bugs may be reported to either upstream here or Debian Bug Tracking System (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qevercloud) by users.

Hi,
I think there is a problem in http.c simpleDownload() (or ReplyFetcher/ReplyFetcherLauncher) where it waits indefinitely after network error.
To reproduce (e.g. using quentier):

1. start sync with working network .. all is expected to work
2. disconnect network
3. repeat sync - it get stuck

Unfortunately I'm quite bad with Qt... but I could debug until the point that the line "loop.exec(QEventLoop::ExcludeUserInputEvents);" in simpleDownload() gets executed, but the event loop never gets terminated. So the line "fetcherLauncher->deleteLater();" never gets reached. Also "setError()" in ReplyFetcher never gets called.. then signal "replyFetched" is not emitted therefore loop doesn't get terminated.

The timeout works if the connection isn't available from the application start. But doesn't if the connection is available, but then drops (or if its unstable - e.g. bad wifi).

The expected behavior is, that on network error (e.g. after timeout) error is set and then exception thrown.

Doxygen is set to build latex documentations by default. However, this would only output latex files + Makefile.

Building refman.pdf with make would FTBFS. Unfortunately the error log is lost, but the problem is due to pdflatex+ non-ASCII characters (e.g., U+421).

Hello,

I made the test-build packages for qevercloud and tested it with nixnote2 (with modifications of source code to use system qevercloud library and header files).

• modified nixnote2: https://github.com/hosiet/nixnote2 , in debian branch with patches in debian/patches directory.
• modified qevercloud: https://github.com/hosiet/qevercloud, in debian branch with git submodule and patches, etc.
• pre-built qevercloud deb packages: http://debomatic-amd64.debian.net/distribution#unstable/qevercloud/3.0.2+ds-1/ , scroll to the bottom of the page and you will find various download links.

Chdir into nixnote2 and the build can be triggered by debuild -us -uc -i -b.

The result buildlog is attached. Error info starts at line 2848, both about the source code of nixnote2 and the qevercloud headers. For example:

release/nixnote.o: In function `NixNote::synchronize()':
./nixnote.cpp:1380: undefined reference to `qevercloud::EvernoteOAuthDialog::EvernoteOAuthDialog(QString, QString, QString, QWidget*)'
/usr/include/qt5qevercloud/EverCloudException.h:110: undefined reference to `vtable for qevercloud::EvernoteException'
/usr/include/qt5qevercloud/exceptions.h:27: undefined reference to `vtable for qevercloud::ThriftException'

So there must be something wrong :-( Do you have any idea?

The original build log:
nixnote2_testbuild.txt

It's not really an issue but rather the description of features which are already being prepared for some new future release. It's unspecified yet when this release would come out but nevertheless some features are already ready in branch feature/copy-on-write-types. Here are some highlights:

1. I got rid of custom Optional template class in favour of std::optional from C++17 standard library. It's 2023 now and all major compilers out there support C++17 so there's no reason not to use good things from the updated standard library.
2. Types from Evernote's data model now implement Qt style copy on write. Previously such types were structs containing only fields but not methods. Now these are classes which provide const and non-const (mutable) getters to the data inside the class as well as setters. The use of non-const getters and setters may cause deep copy of the instance which is otherwise shallow copied around. Most behaviour-less classes in Qt implement the same kind of copy on write so it should feel quite convenient and natural in Qt applications.
3. I've implemented serialization and deserialization to/from JSON format for types within QEverCloud library. Qt's facilities for JSON handling are used so this feature doesn't involve any additional dependencies. While it might feel like an unnecessary feature in a library such as QEverCloud, it was quite convenient to implement this feature within QEverCloud due to the fact that a large portion of QEverCloud source code is automatically generated via QEverCloudGenerator. JSON serialization/deserialization and unit tests for it are generated automatically as well.
4. Each type from Evernote's data model in QEverCloud now has a corresponding builder class which is convenient especially for testing purposes if you want to quickly initialize the instance of a type containing particular values of some fields e.g.

auto myValue = MyValueBuilder{}.setField1(value1).setField2(value2).build();

The code supporting these builders was also generated automatically.

The corresponding branch in QEverCloudGenerator repo is also called feature/copy-on-write-types.

That way the library could also be used on mobile devices. Should look at o2 project to see how they do things.

I noticed that QEverCloud's recently added tests for NoteStore and UserStore started to fail somewhere in after test cleanup code with Qt 5.14.1. It turned out that Qt has never really supported the use of global QObjects and the code doing so only worked by occasion: https://bugreports.qt.io/browse/QTBUG-82984. Well, it doesn't work anymore and hence I have to change QEverCloud to handle this scenario.

Currently QEverCloud has a global QNetworkAccessManager object created via Q_GLOBAL_STATIC internally. The pointer to this object is returned from evernoteNetworkAccessManager function. It has been intended as a means for client code to set up proxy settings. It seems I should separate the actual proxy settings and have only them around as some kind of static object but use local instances of QNetworkAccessManager throughout the codebase.

Fixing this would inevitably be a change in API so I would perhaps need to bump the project's major version again.

Thrift definitions for Evernote cloud API got updated to v1.29 about an hour ago. It looks like all the changes are incremental i.e. there should be no API breaks with v1.28 API. Need to support the new API eventually.

It doesn't seem to really work after all, not with multiple files sharing the same namespace, see this Qt bug report: https://bugreports.qt.io/browse/QTBUG-68611.

I see build failures with recent Qt versions (>= 5.14) where moc fails to generate code unless I disable the use of Q_NAMESPACE and Q_ENUM_NS. It seems the design of Q_NAMESPACE is actually quite flawed.

FYI, check the following patch:

From: Boyuan Yang <[email protected]>
Date: Fri, 07 Oct 2016 12:12:22 +0800
Subject: QeverCloud/CMakeLists.txt: patch library symlink chain.
Forwarded: https://github.com/d1vanov/QEverCloud/issues/7

Upstream build instructions made lib?qevercloud.so.3 a real
library, not a symlink to foobar.so.3.0.0.

Patching the build system to let the system conform to debian
policy ch8.

---
--- a/QEverCloud/CMakeLists.txt
+++ b/QEverCloud/CMakeLists.txt
@@ -89,6 +89,8 @@
 endif()

 set_target_properties(${LIBNAME} PROPERTIES
+  VERSION "${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}")
+set_target_properties(${LIBNAME} PROPERTIES
   SOVERSION "${PROJECT_VERSION_MAJOR}")

 target_link_libraries(${LIBNAME} ${QT_LIBRARIES})