[quote=394230:@Heinrich Siebmanns]The code hangs when the program tries to calculate the screen DPI - this is very related to the display server.
Does this ring any bell concerning Xojo?[/quote]
Yes - hosed is the correct word :).
That happens when running a Xojo app under Wayland. However, the IDE should be suffering from the same error.
this is not enough. Given that it should run without gnome and only gtk3 installed you need to install plasma with
pacman -S plasma. I you did not install plasma, I can perfectly understand why it runs for you
I did set up a complete new PC for testing purposes now. With the above software installed (without gnome, which I want to avoid) the KDE desktop is not able to run. I then installed plasma and 2018r1.1 to opt. If I then start the GasReport it bails out with a FunctionNotFoundExeption. Whoa, something different Looks something is missing here. The message from the IDE is: Could not load libgdk-x11-2.0.so. Hmm, this lib belongs to gtk2… So there still seem to be dependencies to gtk2. Hence I installed gtk2 and look here: it hangs again
Well I spent my sunday to find this out. It is enough for today. Maybe this lib is only a fallback and it first looks for a gtk3 equivalent, but this is subject for tomorrow. I’ll go and get me a beer. I need it now
You will need to install GNOME. It’s just part of the part and parcel of Xojo apps - again. Plus, aside from a bit of disk space, it affects nothing on your system unless it’s libraries are accessed. I’m not even sure how the IDE is running on your system without GNOME.
Also - one more tip to save your time and sanity - use VirtualBox and test this in a VM. You’ll get the same result without the need to deal with real hardware each time. If it fails, delete the VMDK and try again. Plus, you can have multiple VM’s in test at the same time. I ran 21 tests in 2 hours when I came up with that list.
Yeah, I know that and I do that a lot of times. But I decided to use real hardware here because it is the display / display driver that is in question and you never get this in a VB image.
That said: even installing the complete gnome packages is not solving my issue. The Xojo IDE still tries to load libgdk-x11-2.0.so.0 (part of gtk2) for calculating the (real) display and this fails, resulting in the DebugMyApplication hanging. Seems the Xojo folks have forgotten some gtk2-links in the IDE code… I can’t debug this any further, I think somebody has to look into the source code of the IDE…
Ok, I talked to a fellow deveoper who has his apps running on linux and it seems to be best pratice to compile linux 64 bit apps with 2017r1.1 as this doesn’t mess up the whole interface and introduce a lot of havoc. So I will stay there and hope the xojo folks will get this sorted out (or at least give me a Feedback app working on my desktop…). Maybe they should have a look at Qt
@Tim: Yes, this was meant merely as a joke with a bit of eye winking. I know this won’t happen, but it’s not due to the license costs as both gtk+ and qt are available under the same license - LGPL3
That LGPL2/LGPL3 license for QT is ONLY if you are creating open source projects. This means that Xojo would have to license it to include in the IDE and any of us who don’t give our source code away, would also need to license it.
I’ve been in the Linux game since 1993 and LessTif/OpenMotif and GTK are the only “free” options (unless you also consider the lowest levels of xlib/xt).
well as far as i have understood this YOU can use the LGPL Licensed QT Libs for Closed Source Apps if you “only link Dynamicaly” against the QT Libs (and not Staticaly) is this Case you could use the LGPL Versions for Closed Source Apps. I mean that’s one of the Reasons of the LGPL for Example. I also seem to recal that the new LibUSBDeviceMBS Class of the Monkeybread Plugins is based on the LGPL Version of LibUSB - and Christian Schmitz would not be able to use this Library if the LGPL didn’t allow this.
I also know that PureBasic in the new LTS Beta (it is still in Development) has created an qt based GUI Subsystem to use QT - only on Linux - because the GTK3 is not working like PureBasic want’s it to.
And so i also think that Xojo should at least look into if QT can be used on Linux as GUI Library.
While what you say is true in the letter, the long term processes of supporting an part open / part closed Qt dependent application is tenuous at best. Here are their “simplified” terms for using the LGPL’d license with a commercial app:
[quote]If you are using Qt under the LGPLv3, there are a couple of obligations you will need to fulfill :
Firstly, you have to note that some Qt open source modules are not available for LGPLv3 license, for example Qt Charts, Qt Data Visualization and Qt Virtual Keyboard. These modules are only available under GPLv3 for open source usage.
You will need to deliver the complete source code of Qt (including all modifications you did or applied) to your users/customers. Alternatively you need to provide a written offer with instructions on how to get the source code. Please also note that this has to be under your control, so a link to the source code provided by the Qt Project or Qt Company is not sufficient.
The LGPL allows you to keep the source code of your application private as long as it is work that uses the library. Dynamic linking is usually recommended here.
The user of your application has to be able to re-link your application against a different or modified version of the Qt library. With LGPLv3 it is also explicitly stated that the user needs to be able to run the re-linked binary on its intended target device. It is your obligation to provide the user with all necessary tools to enable this process. For embedded devices, this includes making the full toolchain used to compile the library available to users. For parts licensed under LGPLv3 you are obliged to provide full instructions on how to install the modified library on the target device (this is not clearly stated with LGPLv2.1, although running the application against the modified version of the library clearly is the stated intention of the license).
The user of an application or device using LGPL licensed software has to be notified of their rights by providing a copy of the LGPL license to the end user and displaying a prominent notice about your usage of LGPL licensed software.
[/quote]
Our IP lawyers took a look at this and then further examined the full LGPLv3 and in the case of a library that your application is fully dependent on for functionality, their strong recommendation is to stay away.
On the other hand, for something like ffmpeg where the library is a sub functional requirement that only inhibits extended functions from working, they agreed that it is a useful scenario - if the user doesn’t install ffmpeg, that part of the app doesn’t work, but everything else does. To have the entire application dependent on something that must remain fluid after delivery of your application is a very bad scenario. Therefore, they only agree to Qt use from a legal standpoint if we were to license using the commercial license option.
I’m not a lawyer, but my legal team has been at it for very many years. When they recommend steering clear, I listen :).
Apart from lawyers it would surely be nice to hear what the qt people are thinking about the case… But with all the work already put into GTK+ I conclude with Tim - this won’t happen anyway - at least not in the near future. And about something being fluent I lately learned my lesson with Xojo as well
My App is breaking at some crucial points even with 2017r1.1 and it all has to do with reports. If it was’nt for the work I already put into this app (in my free time - we are a non-profit company), I would not hesitate a moment to go away.
FWIW - evaluating Gambas at the moment…
