We have introduced this subsystem because there are a number of problems with the Gtk3 subsystem which are rooted in deep differences between the PB and Gtk philosophy and therefore cannot be fixed easily. Qt is much more "PB friendly" as it turns out. Since Qt is also available under the LGPL since some time, there is also no license issue in the way anymore. We are hoping that this new subsystem becomes stable enough to be the new default on Linux at some point in the future. Don't worry if you still want to use Gtk: We do not plan to remove support for it, it just might stop being the default sometime.
License:
The license is LGPL and we are not statically linking (the binaries provided with the Linux distribution are used). So the license situation is the same as with Gtk. Commercial use should be no problem.
Dependencies:
The minimum Qt version is 5.5.
The following should install everything you need to compile (Ubuntu). The runtime dependencies should be available on any recent Linux distribution already:
Code: Select all
apt-get install qtbase5-dev qttools5-dev qtmultimedia5-dev qtdeclarative5-dev libqt5svg5-dev libqt5webkit5-dev libqt5multimedia5-pluginsJust set "qt" as the used subsystem and all related libraries will switch to Qt (there should be no Gtk dependency anymore then). Of course this also means you cannot use any Gtk functions anymore to manipulate the GUI.
Scripting:
Since Qt is a C++ framework we cannot provide simple library imports to allow manipulating PB objects directly via API like it is possible with Gtk (or the Windows API). To allow at least some measure of API access, there is a new QtScript() command available which allows executing JavaScript code in the Qt QML engine and allows access to the PB GUI objects that inherit from QObject. It also allows interaction with the PB runtime library.
The command is simple:
Code: Select all
Result$ = QtScript(Script$)The following functions are available inside the script:
Code: Select all
PB object access. Returns the JS object representing the given PB object id.
gadget(id)
menu(id)
statusbar(id)
systray(id)
toolbar(id)
window(id)
Misc functions:
debug(message) - send a message to the PB debugger. Does nothing if debugger is off
dump(object) - dump a Qt object to a string. Useful for debugging or to discover what members are available in an object
PB Runtime integration:
runtime.get(key) - read a PB runtime value (variable, constant)
runtime.set(key, value) - set a PB runtime variable
runtime.call(key) - call a PB runtime procedure. The procedure must have 0 arguments! If you want to pass a value, use runtime.set() on a global variableAn example:
Code: Select all
Runtime Procedure QtSignalHandler()
MessageRequester("", "Signal received!")
EndProcedure
If OpenWindow(0, 0, 0, 320, 250, "FrameGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
ButtonGadget(0, 10, 10, 300, 50, "Original Text")
; show the ButtonGadget object's content
Debug QtScript("dump(gadget(0))")
; modify the gadget text
QtScript(~"gadget(0).text = \"Modified Text\"")
; Connect a function to the "clicked" signal and call back into PB code
; Now if you click the gadget, the procedure is called
QtScript(~"gadget(0).clicked.connect(function() { runtime.call(\"QtSignalHandler()\"); })")
Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIfI know some of you are hoping for Qt on all OS, but I don't think this will be happening for various reasons:
- Even though Qt is cross-platform, there are still a number of OS-specifics that are visible, especially in the details. So we would have to support and bugfix a "different" Qt subsystem for each OS. This is more work than you probably think, even if most of the code is shared.
- On the other OS we already have a quite good integration with the native API, so we want to focus on that and not spend work on an "alternative" GUI subsystem that most people will not have any use for.
- To me, having the same underlying framework on all OS only brings a benefit if you have full access to the framework in a cross-platform way as well. If you are limited to only what PB offers through its libraries, then what does it matter if it is Qt or Windows API below? (except that Qt would bring a ton of Dll dependencies on Windows)
- As I said above, we developed this subsystem to solve a specific problem on Linux. The benefit of having it available on all OS simply do not justify the cost in my opinion.
One of the main advantages of PureBasic is that it creates standalone exes without the need for DLLs and/or runtime files on Windows.
