Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

network binding should be conditional to relevant preferences #125

Open
wxl opened this issue Feb 10, 2021 · 0 comments
Open

network binding should be conditional to relevant preferences #125

wxl opened this issue Feb 10, 2021 · 0 comments

Comments

@wxl
Copy link
Contributor

wxl commented Feb 10, 2021

So, we've had network support since version 2.0.2 thanks to 8982c03. It's documented as experimental and off by default in CMakeLists.txt:

option(ENABLE_NETWORK_CLIPBOARD_SHARING "Enables experimental network support for clipboard sharing" OFF)

Similarly, even if you compile support in, the related preferences are off by default:

bool QlipperPreferences::networkSend() const
{
return value("networkSend", false).toBool();
}
bool QlipperPreferences::networkReceive() const
{
return value("networkReceive", false).toBool();
}

However, QlipperModel immediately calls QlipperNetwork:

QlipperModel::QlipperModel(QObject *parent) :
QAbstractListModel(parent)
{
m_network = new QlipperNetwork(this);

This isn't a problem in and of itself, especially considering that the compile-time option renders all of QlipperNetwork's functions essentially no-ops, but what seems a little weird is that a port is immediately bound:

m_socket = new QUdpSocket(this);
bool r = m_socket->bind(QlipperPreferences::Instance()->networkPort(), QUdpSocket::ShareAddress);
connect(m_socket, SIGNAL(readyRead()), this, SLOT(readData()));

It seems to me that keeping networking ports closed unless needed is a generally good philosophy overall, but especially with "experimental" networking support. Making that binding conditional to one of the two preferences seems a lot more sensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant