Need network dialogue for proxy server

[wbrumley2000]

A simple dialog for a proxy server possibility is needed so download works as intended. Also when the user does his own download and implementation and has the program open, the program obviously does not know about the bookshelf; a refresh or a restart is needed.
Suggested code for handling the network business under "settings" using Qt after an appropriate dialog:
#include "QtNetwork"
QNetworkProxy proxy;
proxy.setType(QNetworkProxy::HttpProxy);
proxy.setHostName("192.168.1.11");
proxy.setPort(3128);
proxy.setUser("");
proxy.setPassword("");
QNetworkProxy::setApplicationProxy(proxy);

[jaakristioja]

If Qt provides such facilities, this should be rather easy to implement.

[mgruner]

@gholmlund maybe something to include with the new bookshelf manager? Not sure where though to not add visual complexity.

[wbrumley2000]

Dear Martin:
My recommendation would be to put a new "tab" or choice in the "Settings" "Configure BibleTime" after "Shortcuts" and called  "Network" and have a radio button maybe: "Use Proxy" and then text boxes for host, port (spinner), user, password? Very simple and does not increase bookshelf manager complexity at all. Most current programs such as browsers, security types or others that involve internet access query for the type of network access in order to connect properly. The Firefox dialog (Preferences Network Advanced Settings) is an example and is probably more complex than needed.  Also, the program could try to detect system proxy (openSUSE /etc/sysconfig/proxy) but that may fail in some cases. Admittedly, most users are directly connected or have a router as part of their home setup that creates no problem but the bookshelf manager fails for those of us who have a different setup such as a linux proxy server. Of course, manual download and setup still works but I assume that developers prefer to have users use the bookshelf manager to handle all of that. If you think that it is not worth the effort or all that necessary, then by all means move on to something more important. Since I have not downloaded the project from the repository, I cannot determine how difficult it might be to feed the information back into the main application framework. It might require including QtNetwork and alterations to the .pro as well as numerous other areas depending on how internet access and downloading is handled (probably in bookshelf manager).

Thank you for considering the enhancement.

Regards,Bill

  From: Martin Gruner <notifications@github.com>

To: bibletime/bibletime bibletime@noreply.github.com
Cc: wbrumley2000 wbrumley2000@yahoo.com
Sent: Monday, December 28, 2015 7:07 AM
Subject: Re: [bibletime] Need network dialogue for proxy server (#49)

@gholmlund maybe something to include with the new bookshelf manager? Not sure where though to not add visual complexity.—
Reply to this email directly or view it on GitHub.

[gholmlund]

The Qt Proxy (QNetworkProxy) will only work if the network connection is made with Qt network classes. The network access for our Bookshelf management is not done by Qt network classes. It is done in the sword library using non Qt functions. The proxy would have to be implemented in the sword library.

[mgruner]

Hello Gary,

AFAIR the transport is a pluggable layer. Do you think we could and should implement a Qt based transport to support this (not neccessarily now)?

Best regards, Martin

Am 25.01.2016 um 06:49 schrieb gholmlund notifications@github.com:

The Qt Proxy (QNetworkProxy) will only work if the network connection is made with Qt network classes. The network access for our Bookshelf management is not done by Qt network classes. It is done in the sword library using non Qt functions. The proxy would have to be implemented in the sword library.

—
Reply to this email directly or view it on GitHub.

[jaakristioja]

I think we should make it easier for people to use proxies. This is be important for people behind firewalls or in unsafe networks. Afaik most of the repositories are plain HTTP anyway. We also need to make sure to proxy everything, including DNS lookups.

We have to use Sword 😱!? The sword::RemoteTransport interface looks like a relic from the 90's and I'm sceptical about whether one wants to touch that. The passive field is only FTP specific. The constructor requires a host argument but there could be transports which have no hostname (e.g. DHT). Instead of being uninitialized to "not present" values, the default username is "ftp" and the default password is "installmgr@user.com" (I'm not sure how happy the domain holder of user.com is about this). The getURL method should actually have 2 variants: one for destBuf and one for destPath output instead of switching this at runtime based on the value of destBuf. The default implementation of getDirList looks to be FTP specific. Is the thread-unsafe bool term field meant for communication between threads? 😆 😭