pypt / fervor Goto Github PK

So I get the general idea as to how fervor works and I really like it. But even with the sample application I'm still now quite sure how it works? Do I just create an entirely new binary and fervor will take care of the installing and diffing and everything for me? Could you provide some more details in the form of more documentation? Maybe write a wiki article walking through how to take an existing qt application and start using fervor with it.

tl;dr I love this idea! Can you tell me more?

always gives me the message popup about enclosure error with the download link even when running the sample project too.

I am not able to make this because of a missing header file. It appears ui_fvupdatedownloadprogress.h is not in the project anywhere.

The library uses its own variable for settings storage, at least in fvignoredversions.cpp (autoupdate branch). When an application uses the library, it might end up storing settings in two different places: one for application settings (if it stores them, for example, in IniFormat), one for Fervor.
I believe this is harder to understand, to maintain and to configure after deploy, than in case where application provides Fervor library with settings variable. The application author would then be free to decide how he wants to store settings, he wouldn't have to comply with library requirements.
I propose to roll back the commit c76d4bc ("reinstate access to QSettings to store ignored version").

Line 31 in fvupdater.cpp:
I get a compile error: "unresolved external" - "extern QSettings* settings;".

This is no wonder. I couldn't find any place in the code where "settings" is actually defined.

Using Qt 5.1, VC 2012 x64.

Loosely translated compile message:
fvupdater.obj : error LNK2019: Link to unresolved external Symbol ""class QSettings * settings" (?settings@@3PEAVQSettings@@ea)" in function ""private: void __cdecl FvUpdater::decideWhatToDoWithCurrentUpdateProposal(void)" (?decideWhatToDoWithCurrentUpdateProposal@FvUpdater@@AEAAXXZ)".

So we use Sparkle right now on Mac and Win Sparkle on PC. We have a cross-platform QT application.

I was wondering if your service would work better. I am looking for an auto-updater that will always ensure the user is using the newest version. I'm fine with a running background service, but I need it working properly. I just need to make sure the user is always running the newest version even if the program is still open.

Would your service do that for me? Thank you.

Everyone else seems to be doing that now.

Also I got a few crashes on quitting of the update dialog box, so I think that it could be safer to move call:

FvUpdater::sharedUpdater()->updaterWindowWasClosed();

to

FvUpdateWindow::~FvUpdateWindow()

Just to be on a safe side.

Hi, I tried to use your updater with a redirected XML file hosted by Sourceforge (cf: http://sourceforge.net/projects/serizer/files/Serizer.xml/download).

EDIT : The error is "Connection closed"

I'm using Qt5.1 on OSX Mavericks (the last) with clang64.
I resolve it by settings a UserAgent in request header, I really don't know why but it work like a charm now !

I guess the same fix must be apply to executable downloader function.

I suggest a fix for this problem, set the content-type mime type header is not mandatory but I think it's a better way to using protocol:

diff --git a/fvupdater.cpp b/fvupdater.cpp
index 2e5a429..a958204 100644
--- a/fvupdater.cpp
+++ b/fvupdater.cpp
@@ -289,7 +289,12 @@ void FvUpdater::startDownloadFeed(QUrl url)
{
    m_xml.clear();

-       m_reply = m_qnam.get(QNetworkRequest(url));
+    QNetworkRequest request;
+    request.setHeader(QNetworkRequest::ContentTypeHeader, "application/xml");
+    request.setHeader(QNetworkRequest::UserAgentHeader, QApplication::applicationName());
+    request.setUrl(url);
+
+    m_reply = m_qnam.get(request);

        connect(m_reply, SIGNAL(readyRead()), this, SLOT(httpFeedReadyRead()));
        connect(m_reply, SIGNAL(downloadProgress(qint64, qint64)), this, SLOT(httpFeedUpdateDataReadProgress(qint64, qint64)));

If update window is called from the dialog box (Preferences in my case), it will appear "below" it.

This call helps:

setWindowModality(Qt::ApplicationModal);

(same in FvUpdateConfirmDialog)

Have them to be app-modal, is a good idea anyway.

Has this been merged in? Maybe updating README is in order if it has.

Is there any technical reason why this is still not done?

I'm using qt 4.8.1 (mingw, winxp). After integrated Fervor in my application, the release version was working,but the debug version doesn't because of an error during the application startup.

Whe the runtime trying to load QtNetwokd4.dll, it doesnt found this export: _ZN10QSslSocket22connectToHostEncryptedERK7QStringt6QFlagsIN9QIODevice12OpenModeFlagEE

I don't understand if it's a Qt distribution bug or a strange mismatch of configuration in my computer.
Are there any other guys with this issue?

Hey Pypt! Thanks for your awesome work! I love this library! It was exactly what I was looking for!

I think I may have found an issue (although it may be my fault). I have my latest version as "2.0.2 Beta" and even when that is the version in my Appcast.xml file and my application, Fervor still offers me an update link. Am I doing something incorrectly?

Thanks for your awesome work!

Chris K

Edit: Nevermind. I just had to run the application again without recompiling it (it had to be the same binary run twice).

I'm just getting into submodules and this confused me for a bit.

Thanks for fervor! I hope to be using it for our cross-platform app soon.