I am about to create an application. I would like to keep it in modular architecture and to work on Linux, Mac and Windows. I want to use Qt library in general.
The most of the functionality of this application will be stored in plugins, which for some reasons is the best approach here. I am used to create plugins on C++. However I am considering to use Qt plugin management system.
My questions are:
Can this system be used to manage any kind of plugins? What I mean is that most (all I've run into) examples cover plugins regarding Qt styles and Qt elements, etc. No general plugin managemet like "Foo" plugin doing "hello world".
Are there any advantages of "manually created" pure C++ plugin system over Qt plugin system? Should I rather consider using pure C++ approach?
Qt offers a generic plugin system, and you can leverage it for whatever use you desire. The documentation has it covered.
Qt's low-level plugin api works on interface classes - classes with abstract virtual methods. A plugin implements such interface. The plugin loader gives you an instance of an interface-derived class that implements the interface.
Related
This question already has answers here:
How do I build a graphical user interface in C++? [closed]
(8 answers)
Closed 6 years ago.
is there a way of creating a classic GUI with cpp like for the case of JavaFX? I want to create elements like floating buttons, tables, graphs, etc. I know of tools like qt but I'm not ok with it. I tried win32 API but it's only for Windows.
GUI libraries are generally called "widget toolkits", and there are a variety of cross-platform GUI widget toolkits available, however they are rarely a good idea for a great UX because different operating-system environments have different UI paradigms (e.g. how macOS and Ubuntu has a single always-on menu-bar at the top, whereas Windows and other Linux desktops do not).
So you have two fundamental choices to make:
Use a single cross-platform GUI toolkit - which means creating a single GUI project, but restricting you to that toolkit's selection of controls and functionality, and generally subjecting your users to a (relatively) poorer user-experience, either because your toolkit does not use native widgets (e.g. Java, WPF, Qt) or because you cannot use a platform's native paradigms.
Write a new native GUI for each platform. This means more work, but a better user-experience.
For cross-platform GUI toolkits, the main options are:
Qt
GTK+
WxWidgets
For a comparison between the three, see this QA: Which, if any, achieves Windows native look: GTK+, wxWidgets, Qt, FLTK?
(TL;DR: WxWidgets uses native controls but is difficult to develop with; Qt offers the best developer experience but has many other bullet-points which you need to be aware of)
For a native UI for each platform you need to target, you'll need to familiarize yourself with each API:
Win32:
MFC (the API is ugly by modern standards, but does encapsulate the main Win32 UI paradigms and APIs, such as Common Controls. However, be prepared for an uphill fight to support latter-day UI features, such as High-DPI, bi-directional text and high-quality 2D rendering. GDI/GDI+ is on the way out, which means using Direct2D - which is fun because MFC assumes GDI)
UWP/XAML: If your application can be sandboxed (and run only on Windows 10) then you should take a good look at UWP/XAML (it's all native, so the CLR is not involved).
WPF: Using WPF makes it easier to create a high-quality user-interface, if you're comfortable with your application taking a dependency on the .NET Framework and writing UI code in C# - however the visual aesthetic of un-skinned WPF apps took a nosedive with Windows 10 (i.e. they're ugly) and WPF's default control set is very aneamic - but if you have the means (i.e. time, money, people) then you can get great results - and as a bonus the XAML for WPF is generally portable to UWP.
macOS: Cocoa - you will have a hard time doing this in C++. If you're targeting macOS I strongly suggest writing your UI layer in Swift (or Objective-C if you have to) and then linking-in to the rest of your application code using C++ bridges.
Linux: As Linux is just a kernel the set of "native" widgets depends on the desktop environment of the user - but most desktop programs seem to use GTK. And if you're going to use GTK then you might as well use GTK's cross-platform features to support Windows and macOS.
In conclusion: it's difficult and a lot of work. :) - and explains why many software titles today (mid-2017) often built as web-applications either on the web directly (e.g. Facebook, StackOverflow, SalesForce) or hosted webviews using Electron (e.g. Slack, VS Code, Atom) or some other hosted-webiew (PhoneGap apps, Spotify, etc).
I'm planning to write a cross-platform project in C++, which will run a Lua engine. I'd like to write the main program for that project including the GUI in Lua. And to make it even easier, I want to write the GUI in HTML and therefore I need an additional library, hopefully QtLua which is based on Qt.
From what I heard, implementing QtLua into the Lua engine shouldn't be too hard and Qt has a nice class called QWebView that should allow me to write HTML GUIs. But I'm wondering about 2 things:
Is it cross-platform capable?
Is QWebView even part of QtLua?
Answers to both questions i think you should find here http://www.nongnu.org/libqtlua/
There's this part that says
QtLua is not designed to develop an application in pure Lua but rather to extend a Qt C++ application using Lua as scripting language.
Therefore, if your application is built/based on Qt and only extended using Lua, it should be cross-platform capable.
And for your second question; QWebView is used to view and edit web content, QtLua or QtScript is used to provide support for application scripting. QWebView is not part of QtLua plus i don't see any member of the QWebView class that has any connection with scripting
I'm a little new to Qt. I have been programming in C++ for quite a while.
I want to create an application in Qt/C++ just because it's very easy to create the GUIs. I wanted to know that is it possible that I can write a C++ class in native C++ and use it in my Qt application.
I want to write the GUI in Qt and do all processing using my native C++ code rather than Qt/C++. Is it possible to compile a DLL in native C++ and then load and use it in QtC++ application?
I really want to write a GUI application using C++.
There is no such thing as "native C++" as opposed to "Qt/C++", so the question makes little sense. All of core Qt code is compiled native C++, just as any C++ application that uses Qt is.
As JBentley has duly noted:
[You may be] confused because of the code generating tools Qt uses, like moc [or uic]. Those don't mean that C++ compiles natively while Qt doesn't. All those tools do is provide a convenient way to produce a lot of boiler code that the framework relies on, so that the programmer can pretend they don't exist and use things like Qt's slots and signals. The final code which you compile and link is ordinary C++, with calls into the Qt library (also C++) which you've used.
If what you're asking is "am I forced to use Qt classes in all parts of my application", then no - nobody's forcing you to do that. If you already have parts of your application written using boost, or standard C++ library classes, it's fine.
You have to understand that Qt has modular design and provides a lot of non-GUI functionality. You can use the non-gui modules in the non-gui part of your code. It's a fairly clean and general purpose application development framework. It's perfectly fine to use it for various internet server applications, for example.
The following Qt modules are of note for non-gui development:
Core: Core non-graphical classes: containers, event loop, timers, threads, state machines, internationalization, XML, json, file I/O - all of it portable.
Network: Classes to make network programming easier and more portable. Includes secure sockets, HTTP requests, etc.
SQL: Classes for database integration using SQL.
You are able to use any C++ code you would like. I have have actually had questions with the same thought process in my day to day work. First you need to grok the idea that Qt uses normal C++ and special tools to create a robust set of libraries.
Later on come back and you will want to learn more about the items below:
Signals and Slots
This is how events are wired together.
One objects sends a signal and all connected slots get called with the given parameters.
Signals and slots are an example of the Observer Pattern.
Designer Forms
The form designer lets you lay out controls using simple drag and drop operations.
The .ui file gets transformed into C++ code as part of the build process.
Layouts
You can do a lot of things with just the horizontal, vertical and grid layouts
Spacers
You can push things up, down, left, or right using different types of spacers
They look like a spring on the form designer.
Resource Files
Lets you embed graphics and other content directly into the application.
Models, Views and Delegates
Hard to avoid if your have a non trivial UI
There are other things too, but knowledge in these areas will let you make some decent desktop applications. My favorite reference is older, but still a goodie: "C++ GUI Programming with Qt4" http://www.amazon.com/Programming-Edition-Prentice-Software-Development/dp/0132354160
Yes QT4 is "old" and QT5 has been out for some time... but the book provides a solid foundation that you will be able to add information to.
I need to write an application that will be visually indistinguishable from something written natively for Windows XP/Vista/7 using whatever comes by default with the most modern Visual Studio. But I'm developing using MinGW and Vim (in C++).
In particular, I want the following controls to be native on the above three versions of Windows: form chrome, buttons, check boxes, menus, combo boxes, progress bars, scrollbars, rich text boxes. This will be enough for me.
I know that if you load GdiPlus and other things like riched32.dll as needed, and use Windows API to instantiate controls, then the OS will substitute its version of GdiPlus or other library, so it will look like XP style controls on XP, Vista on Vista, etc.
But I don't want to use plain Windows API, because even retrieving the default font takes half a page of code, and similar stories whatever I want to do. So I'd like to use a toolkit.
wxWidgets, Qt, GTK+, FLTK seem like the most widely used. But they are all cross-platform. I've used cross-platform applications, and many of them have foreign GUI controls (I call them widgets). So my question is: which of these toolkits can be made to produce true native-looking UI controls listed above, appearing correctly on the three versions of MSWin listed above?
I've typed each of them +" windows" into Google Images, but it's hard to tell, except that FLTK probably can't do it. Many of you must know the answer off the top of your head...
I won't talk about FLTK as I don't know it.
wxWidgets uses the native toolkit of the platform, (GTK on Linux, Win32 GUI API
on Windows, Cocoa on MacOS X).
GTK uses a theming API to fake the look and feel of the platform (custom theming engine on GTK2, CSS-based engine on GTK3).
Qt uses styles to fake the look and feel of the platform.
wxWidgets API is quite ugly from my own experience, because it had too many method just available on one or the other platform making stuff non-portable unless you'd workaround it. Unlike GTK+ and Qt, it also adds its own layer of bugs above the toolkit it uses as a backend. However, it tries hard to have the platform's native look as it uses the native toolkit.
GTK+ 3 still has some rough edges on Windows, which it officially supports since GTK+ 3.6. The GTK+ project delegates to the MSYS2 project the distribution of Windows binaries. As you're already using MinGW, that's pretty much the same kind of environment. They have good C++ bindings with GTKmm. However, you may have some work to get the theming right for your version of Windows.
Qt is a good choice for cross-platform C++ development with the main target being Windows, tries to mimic the native look and feel of the platform but has its own theming limitations too.
To sum up, there are only 2 approches:
toolkits that provide their own widgets and try to look like the native platform by providing theming (GTK+ and Qt)
toolkits that use the native widgets but hide their API behind a layer of abstraction (wxWidgets)
Both have their pros and cons.
Implementation details aside, wxWidgets philosophy is, and has always been, to look as natively as possible. We, wxWidgets developers, don't always achieve the goal of looking indistinguishably from the native applications but we always strive to do it and. AFAIK this is not such an important goal for Qt and definitely not for GTK+, so in my (obviously biased) opinion, wxWidgets is your best choice if you are serious about providing the best experience for your users, especially under OS X.
To answer your question more precisely, everything you list above is implemented using native controls in wxWidgets for Windows (rich text control is not available natively under the other platforms though).
IUP - Portable User Interface library uses native widgets, C API and Lua bindings.
i used java for native cross-platform without changing the code, used c/c++ wxwidgets for exclusively cross-platform if you want go to little up performance and standalone executable, used c/c++ winapi for windows and x11 for gnu linux native platform and terminal console, used python for scripting console and platform if you want your software up to date fast, and used assembly for a little simple purely console. And sometimes i combined them all with shared library .dll on windows and .so on gnu linux. And i liked doing for do comparative performance on programming studies with small hardware requirements.
I am using persevere for an application I am writing that controls remote hardwere.
Persevere is written in Java and doesn't supply an alternative API.
I am using a web-based GUI as the control panel. So far, so good.
I can get and set data using REST channels like dojo does but the problem is that I don't really know how to use REST channels. Which library should I use to do so?
If you use gcc as your toolchain you can embed a JVM with GCJ to run persevere inside your application. GCJ makes it easy to call C++ from Java with it's CNI interface (much easier than JNI). I used that method to use Java scripting inside our C++ application. You can even compile the persevere jar into a native library and link it to your app with GCJ.
The best reference is the GCJ Documentation.
There is also a Linux Journal contains the article Embedded Java with GCJ that you can read.
You can also study applications that use gcj.