I want to make an app using Qt that communicates with serial port.
The problem is that I cant find a library that works and does this thing.
I need a non General Public License library I think.
Actually I am not sure cause I don't know if I can use a General Public License library for a closed source program.
I found qextserialport but I am unable to build it using Qt 4.7.3. I added all the needed headers but it fails on some functions.
Can anyone help me here?
If you want to go closed source and distribute your application, you can't use GPL. You can use LGPL when linking either dynamically or statically. For the latter, you need to provide object files for all of your code, so that they can be statically re-linked with Qt.
Conercerning your base issue, Qt 5 includes a serial port module. On Qt 4, you'll need a platform-specific solution. Reducing the scope might help to point you to something. I suggest that if you don't target portability, you should add relevant tags and comments. Otherwise, saying that you need a portable solution is a good thing too.
As far as I know, on most paltforms, accessing to serial port requires higher privileges, so be ready for that in your deployment.
Concerning qtextserialport, license is BSD so it would work for your clsoed source application. If you post a compilation issue on where it fails, maybe people will be able to help you
I tried to compile it using VC2010 and Qt 4.7.2 and head of project (I just cloned it) compiles flawlessly: I got a nice qextserialport1.dll (that I admit I didn't try using).
There is a QtSerialPort add-on nowadays that can be used for such tasks. I am one of the maintainers behind it. That is the "official" Qt add-on nowadays, so I would suggest switching to it. It will also support Qt 4.
It is properly useful for commercial code (closed source) as I have also been doing that. If we do not yet have an exception for static linking, I would even accept that if legally possible.
My opinion about licenses is somewhere in-between LGPLv2 and MIT, i.e. LGPLv2 + static linking.
Here you can find my blog post about it. It also works fine with Qt 4 as we have had put some effort into that support, too.
http://lpapp.blogspot.co.uk/2013/02/qtserialport-in-qt-51.html
Related
I am trying to write a GDB frontend. I use GDB for debugging embedded targets, especially with ARM processors. I have used Eclipse before, but I didn't like it very much. At work, we use Lauterbach Trace32, which is one of the most comfortable debuggers I have ever used. That's why I started a project where I try to implement a very similar application as a GDB frontend, which is specialised to embedded debugging.
However, I already have implemented some very basic commands, like viewing the source code, viewing registers of the target etc., which works well. Currently, I am implementing breakpoints. But for this I need some help.
I use Qt (with Qtcreator) on Linux for my project, so I have set up a QProcess for the gdb running in the background. I use the GDB Mi2 interface to communicate with gdb. Then, using write() I can send commands and with a SIGNAL, I can receive the responses from GDB. This works well, but the answers from GDB in this MI format are very ugly to parse. Could anyone give me a hint how this can be done in a elegant way? I tried BOOST to build a parser, which worked, but this is a much too complicated way in my opinion. Is there some better way to parse the GDB responses?
There's no truly great way to parse MI. MI is quite old and so predates the widespread adoption of XML and JSON. Also, even more unfortunately for you, there are a few known MI emission bugs in gdb (search bugzilla and the list archives) -- spots where gdb's MI output doesn't conform to the MI grammar. These have gone unfixed because it was judged that changing the output (without bumping the MI version number, something nobody seems to want to drive) would break existing parsers without much corresponding benefit.
The good news is that there are a few reusable parsers already in existence. So I would suggest using one of those. The parser in nemiver is written in C++ and is a reusable library. However as you're already using Qt you might check out the parsers in Qt Creator or KDevelop.
It might also be possible to roll your own gdb interface by programming gdb in Python. However, there are likely to be some holes in gdb's Python API, so I would only recommend it if you also want to get into hacking on the gdb Python layer as well.
There is the pygdbmi python library for exactly this purpose (it did not exist when you originally asked your question) https://github.com/cs01/pygdbmi
gdbgui is a frontend that utilizes pygdbmi: https://github.com/cs01/gdbgui
Have fun!
Disclaimer: I am the developer.
Qt Creator itself has a parser for (some superset of) the MI protocol, see plugins/debugger/debuggerprotocol.{h,cpp} in its sources. This (superset) protocol also used to capture data from Qt Creator's "pretty printing" produces and also serves as the debugger->frontend channel for the LLDB integration.
The protocol implementation is fairly well separated from the rest of Qt Creator's debugger plugin. It should be re-usable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm developing an application with the Qt open source edition. As I don't want to deliver the Microsoft Visual Visual C(++) redistributables, I'd like to use a static-linked version of Qt.
The Qt licensing information says that I "should" develop with a commercial Qt license if I want to use static linking in my application, although when I use the configure -static command for building a static Qt library the command prompt asks me if I use the commercial or open source version of Qt.
So it is possible to build Qt with the open source version? Do I need the commercial edition to use static linking? I won't sell the application.
EDIT April 2016
Actually, I have recently been reading in depth about LGPL, and asking some experts on the subject. Turns out that the inability to use static linking for Qt in closed source applications is more of a cultivated legend and has nothing to do with reality.
What LGPL requires is the possibility for the end user to relink the application against a different version of the library. Using dynamic linking is one way to achieve that, but you can just as easily provide your object files, this way you don't have to open your source and the LGPL requirement is still satisfied.
On the Qt website there are 2 legal FAQs and in neither of them is it directly stated that you can't do it. Just as it is not stated that you can. However, there are at least several instances of implying a vague legal threat in case that you do. I think there is a good explanation for all of those - they can't say that you can't do it without publishing a practical lie which may as well have negative legal repercussions for them, and they are willing to discourage doing that rather than encourage it, as it has the potential to force more people into purchasing a commercial license.
So in short, yes you can, and you most definitely should as lately Qt has become a living deployment hell, plus as of Qt 5.7 in a static build, QML files are tucked neatly in the executable rather than being out on the file system, for anyone to tamper with. Just make sure that:
your Qt build only contains modules, licensed under LGPL, and nothing GPL
the about section of your app mentions that it is using Qt and contains a link to where you can download the application's object files
include all the respective license files with your application
Lastly, your application actually has to be "relinkable", that is, it must be able to work with a compatible library version that provides the necessary functionality. Which means that if you have made modifications to Qt before building it, you must provide those in the form of source code as well, but only the modifications to Qt, not your application's source code.
Update:
Here is an excerpt directly from the GNU FAQ:
For the purpose of complying with the LGPL (any extant version: v2,
v2.1 or v3):
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source)
format, so that a user has the opportunity to modify the library and
relink the application.
That states it pretty clear.
The old, original answer:
It is possible to build Qt statically as long as your application is open-source and you provide the source. If you want to keep your source closed, you either need an expensive commercial license, or you need to use dynamic linking.
BTW using a static build of Qt is pretty nice, for Qt5 I get about 7-8 MB executable with no external dependencies, which is much better than the 20+ MB of additional dll's you have to ship with a dynamically linked app.
For more information, you can take a look at this video: Making the correct license choice when developing with Qt
All in all, can it be done? 100% yes. Should it be done? It depends, for personal/testing/learning purposes it is 100% OK, however if you plan to distribute production grade software, be that commercially or not, open source or not, you'd better first consult with a lawyer. The whole subject is unnecessarily complicated, subject to interpretation, so that the consultation with a lawyer becomes more expensive than a pricey commercial license.
The answer is Yes, if you are willing to open source your application.
According to the Qt-Project's own interpretation of the licenses they use, if you dynamically link to the Qt libraries your application can be either closed source or open. If you statically link, however, your application is subject to the terms of the LGPL.
The exact language the Qt Project uses is this:
In case of dynamic linking, it is possible, but not mandatory, to keep
application source code proprietary as long as it is “work that uses
the library” - typically achieved via dynamic linking of the library.
In case of static linking of the library, the application itself may
no longer be “work that uses the library” and thus become subject to
LGPL. It is recommended to either link dynamically, or provide the
application source code to the user under LGPL.
(http://qt-project.org/legal.html)
The suggestion in some of the other answers that the situation is "not at all clear" is simply untrue - The Qt Project has tried to be abundantly clear about in what circumstances usage of the LGPL license is permissible, and static linking is one of those as long as the app is also LGPL.
Since the original question specifies non-commercial (not necessarily open source), the asker will need to decide whether they can allow distribution under the LGPL (or GPL by extension, as the above page also says "LGPL can be converted to GNU General Public License").
We've developed a commercial Qt application with Qt under LGPL. We link dynamically. We also made a few changes to a couple of files in Qt to better suit our needs. I realize that according to LGPL, I must make those changes publicly available.
My question is how is that done?
Do I set a webpage on my domain with the modified source codes available for download?
Do I distribute the modified source code in a folder on the client target machine after installation?
Another
way?
You simply have to make them available on request.
It can be a file on your web server, it could just be emailing them to anyone that asks, you can even supply them on floppy disk and make a charge for it.
Ideally you would also contribute the changes back to Qt if it's a bug fix or feature that could be useful to other people, then it may be incorporated in future editions and youcould then just use the standard build.
ps. The letter of the GPL says that you have to provide everything that is needed to create your modified build - so the full Qt sources and the build files. However for a large complex project like Qt, if you have only modified a couple of files it would be useful to offer a download of just these (or even a diff against the specific Qt version)
According to the licence you need to provide your changes back to the community, not just to your customer.
The easiest way is forking the main Qt repository on http://qt.gitorious.org/qt and commit your changes there.
I believe Qt uses GDI(+) and you start with a QObject. Does it call ActiveX components, COM etc?
For example, putting WebKit in a form is there anything happening there that uses the Windows bits and pieces for painting?
I'm just a beginner trying to work out how much of WINAPI, COM, and ActiveX is used/wrapped by Qt.
In general Qt only implements a feature if there is a sensible(/compatible) metaphor for that feature on all* supported platforms. It makes use of a lot of different Microsoft and non-Microsoft components on Windows, not just the one's you have mentioned.
I've not found a document which summarises what you're asking before because it's not something I've ever needed or found useful as the document would be immense. The way I tend to work with Qt is read the excellent documentation and believe it until I find something which does what I didn't expect it to. Then delve into what it does under the bonnet(/hood) for that specific platform. Remember, the source code is freely available.
* Note: there are some features which are platform specific in the framework but these are usually clearly identified as such.
The article Porting Qt for Embedded Linux to Another Operating System lists five things you have to do to port Qt for Embedded Linux to another OS. From the article:
There are several issues to be aware of if you plan to do your own port to another operating system. In particular you must resolve Qt for Embedded Linux's shared memory and semaphores (used to share window regions), and you must provide something similar to Unix-domain sockets for inter-application communication. You must also provide a screen driver, and if you want to implement sound you must provide your own sound server. Finally you must modify the event dispatcher used by Qt for Embedded Linux.
Is it really this easy to port Qt to another OS, or have i missed some information?
Another important component to port would be QAtomic, to ensure that you can have atomic operations and implicit sharing working well. See also
http://labs.trolltech.com/blogs/2007/08/28/say-hello-to-qatomicint-and-qatomicpointer/
Since Qt has been ported a large number of times it seems logical that it would be inherently simple. However the issue really is on the platform you are porting to and how many features it currently supports.
Assuming you find all those things easy, then the port is easy.
After investigating this in more detail I have come to the conclusion that the article "Porting Qt for Embedded Linux to Another Operating System" assumes that you are porting Qt to a very "linux-like" OS.
I have attempted this and currently making progress.
Some difficulties:
IDE - I have to manually add all Qt files and fight the compiler with #ifdefs until it builds with all dependencies in place.
Linux(ness) - I've had to disable all Linux/Windows things that are not supported in my target OS: threads, sockets, processes. Even the timers are slightly different.
Tips:
Start small : I compiled QtCore as a standard lib within my IDE, next up is QtGui which is a behemoth compared to QtCore.
I plan to run only a single QThread, so I have to artificially made a Thread object to avoid null pointers. You cannot compile out Thread information as it is key to all QObjects.
So far I have an qeventloop running within a qcoreapplication.
I wrote some inline assembly but had serious difficulties with my IDE and compilation. I left it in C++ and let the assembler handle it for me. Because I am single-threaded, I am not too concerned with shared data/ exclusive access as required by the atomic operations.