I need to find available network connections like eth,wlan,bluetooth. Does Qt emit any signals on detection of these access-points automatically? And also if more than 1 connection is available how would I know that which access point is used by system? And also if only 1 connection[apart form eth0] is present, for ex:WLAN Do we need to apply any additional settings for using ftp/htttp protocols?
Thanx
I think what you are looking for is QNetworkConfigurationManager which was added in Qt 4.7.
QNetworkConfigurationManager provides access to the network configurations known to the system and enables applications to detect the system capabilities (with regards to network sessions) at runtime.
It has signals for configurations being added and removed.
It can also trigger a scan with the updateConfigurations() slot (a signal will be emitted when complete):
Initiates an update of all configurations. This may be used to initiate WLAN scans or other time consuming updates which may be required to obtain the correct state for configurations.
You can set the connection a QNetworkAccessManager uses by calling QNetworkAccessManager::setConfiguration.
Related
QtConcurrent is extremely convenient as a high-level interface for multithreaded processing in my data-heavy/CPU-heavy application. The Qt6 upgrades vaguely referenced "Revamped Concurrency APIs" but I didn't see much change, except a reference to being able to pass a custom QThreadPool.
That got me wondering... is it possible to extend QThreadPool into a class that manages threads/tasks on other machines, not just the host machine? Or is that too far from its original design? Or is there another Qt class that can manage distributed processing?
Don't bother linking me to non-Qt solutions. That's not the point of this question.
QtConcurrent doesn't deal with any of it, unfortunately.
In a most general approach, you only need some worker machines on the network, and a way to connect to them via ssh (if they are Unix), or via Windows credentials (on a Windows network). At that point you can send a binary to the worker and execute it. Doing this in Qt is of course possible, but you'd need to wrap some other libraries (e.g. Samba for RPC calls, or openssh) to do that.
No matter whether the software can "distribute itself" or is otherwise installed on the workers, you got it running on multiple machines. Now they have to communicate, with one being a master, and the other being slaves. Master selection could be done via command line arguments, or even by having two binaries: workers that include only the back-end functionality, and a front end that includes both (and has some sort of UI).
At that point you can leverage Qt Remote Objects, the idea being what you'd "distribute" is QObjects that do work in the slots, and return results either via return value of the slot, by sending a signal. It's not as convenient as using QtConcurrent directly, but in general there's no way to distribute work transparently without some introspection that C++ doesn't quite provide yet.
I know that OpenMPI is not a Qt-based solution, it certainly works and makes life easy, and for sure it can interoperate with Qt code - you can even distribute methods and lambdas that way (with some tricks).
If you manage worker objects encapsulated as QObjects, it's not too hard to distribute the work in e.g. round-robin fashion. You could then have a front-end QObject that acts as a proxy: you submit all the work to it, and it signals all the results, but internally it invokes the slots on the remote QObjects.
Would you be interested in a demo? I could write one up if there was enough demand :)
I have two Qt apps sharing a memory segment.
I would like to be able to emit a signal from App2 and trigger a slot from App1.
First off, I need to use QObject::connect() to link the App2 signal to the App1 slot.
Is there a good way to connect two different Qt processes signals/slots mechanisms? I've stumbled upon the qt-remote-signals library to send remote signals, which is using QDataStream to serialize the object. QSharedMemory uses the same class.
Or should I forget about connecting anything and just simulate a signal/slot behaviour?
Write in the memory segment from App2
Read the segment whenever it changes from App1 (how to know when it is updated?)
Emit a custom signal from App1
Trigger a slot from App1
Does that sound realistic ? I'm new to shared memory.
As far as I know, you can't connect Signal/Slot between processes. Also you cannot know 'naturaly' if another process have changed a QSharedMemory.
So I think you'll have to simulate it as you said.
Write in the memory segment from App2
App 1 could be checking periodically the segment, to being aware of changes from App 2. Once a change is done, you directly trigger the slot (you don't really need the signal)
If you need an instantly response (without making the App 1 checking time too small) from App1 you could make them comunicate using QLocalSocket/Server or D-Bus, butin that case you could go all in with them and manage all the comunication, making the QSharedMemory unnecesary.
How to get the system network status in Qt like we get event hits in .NET so that each and every time when we connect network get a signal of a status of the network connection?
Is there any function that have same functionality as I mentioned above?
Using ping and other methods of network configuration takes a small amount of time.
But I need to display it as fast as I could other than using a specific port to listen to the socket and display its error.
Can any one help me out of it?
I found a good example of getting network information using QT:
http://developer.nokia.com/community/wiki/Get_Network_information_using_Qt
For instance, you can get the signal strength from the public member, networkSignalStrength, of QSystemNetworkInfo. And, if you take a look at QSystemNetworkInfo class reference, you can find signals such as networkSignalStrengthChanged so that you can handle something when network signal strength gets changed.
Hope this helps!
How many signals at maximum you can connect to a single slot? If more than one how you can do that? How many slots can you connect to a signal? If more than one how those slots will be executed? How a Qt Program/Application written for one platform (Symbian) can be ported/executed in another
You can easily connect more than one slot to a single signal using the usual way (QObject::connect), which are then called in order of connection when the signal is emitted.
Likewise can a single slot be connected to multiple signals, which is then called whenever one of those signals is emitted. You can even chain signals by connecting signals to signals, which are then emitted automatically whenever the source signal is emitted.
Such information can easily be gained by Qt's excellent documentation.
There may be a theoretical limit on the number of slots that can be connected to a signal, but this limit is surely beyond any practical relevance.
Although porting an application from an embedded system, like Symbian, to a desktop system, like Windows, may involve some additional issues, in general the porting of a Qt application to another platform just requires recompilation on/for that platform, assuming you didn't use any platform-dependent code in the rest of your application, which is usually not neccessary when using Qt.
you can connect as many slots to a signal as you wish. They will be executed in order in which they were connected.
Generally if you use only qt and no other platform dependent API, then recompiling it on target platform should be enough. Have no idea about Symbian though - sometimes Symbian seems to have a bit different rules.
I'm building a Qt application that needs to use libssh, a SSH client library. libssh (understandably) performs its own network connections, however Qt has its own infrastructure for network connections (QTcpSocket etc).
Should I worry about these differences? Should I be trying to make libssh make network connections via QTcpSocket... Or if it works fine on the platforms I'm targeting, is that good enough?
The only downside is that you have another library that your code depends on.
The primary rule though is if it works, go with it.
I think it depends on how the abstraction you get from libssh looks like. If it is a socket-like API, you could create an QAbstractSocket implementation for it. If it is just some structure or handle to read from and write to, you could create a QIODevice subclass. Most I/O can be implemented generically operating on QIODevices (instead of explicitely operating on QFile, sockets, etc.).