Is it possible to make a GtkMessageDialog set as a modal movable/draggable? I'm using Rust with Gtk-rs (GTK 4) but this does not need to be language specific.
More details:
I'm using Linux (Fedora 36) with GNOME. Here is a link to the code: https://github.com/lakoliu/Furtherance/blob/f19023ce3917efde04ff37fb77c00f6bd56b2c13/src/ui/window.rs#L319
Related
Good evening,
I inherited a project made using QT creator (C++ and Qt Quick).
The target is a DaVinci DM8168 board with **Linux kernel 2.6.37 **on it.
In particular I'm using Qt Creator 4.2.0 (4.2.0)
Based on Qt 5.7.1 (GCC 4.9.1 20140922 (Red Hat 4.9.1-10), 64 bit)
I can build & run the application for the target and I can see it running.
I need to launch the profiler. But it does not work. When i run the application (on the target) using the parameter:
qmljsdebugger=port:xxxx
then the application does not start anymore!
I tried to add these options to the project's .pro file:
DEFINES '' += QMLJSDEBUGGER
DEFINES '' += QT_DECLARATIVE_DEBUG
PACKAGECONFIG_append = " qml-debug"
I, obviously, build in debug mode.
When I try to run the applicative on the target i get this message:
QML debugging is enabled. Only use this in a safe environment. Process
killed by signal
I repeat: if the option "qmljsdebugger=port:xxxx" is removed then the application starts and works properly.. but of course the profiler wouldn't connect in this case.
As I said, I've inherited the project and I'm complete new to this environment.
Any help or suggestion?
update
these are now the lines I've added to the .pro file
DEFINES '' += QMLJSDEBUGGER
DEFINES '' += QT_QML_DEBUG
CONFIG += qml_debug
I checked the various path for QT and exported PATH and LD_LIBRARY_PATH.
Unfortunately nothing changes:
If I launch my program using:
/opt/MyPrefix/MyProgram -platform eglfs
then it works.
if I use:
/opt/MyPrefix/MyProgram -qmljsdebugger=port:3456 -platform eglfs
then it crashes
QML debugging is enabled. Only use this in a safe environment.
Segmentation fault
the program seems to start in Debug Mode and this is ok. The problem is the profiler :(
ps: As far as I know there are no firewalls running on the target. I'll check better for sure.
update 2
I tryed the same solutions as above but on a simple program as suggested(an "hello world" basically) and it does not crash when the "-qmljsdebugger=port:3456" option is specified... I really don't know what the problem is in my original application.
First there are a few prerequisites to make qml debug run like being sure that Qt was built with the exact same toolchain as the binary. You should take a look at Qt Wiki: https://wiki.qt.io/How_To_Profile_QML_App_on_Embedded_Device
An important note is that how you make qml debugging works has changed between Qt Quick 1 and Qt Quick 2. As you are using Qt 5, I believe you should be using Qt Quick 2. So that means that you should not use QT_DECLARATIVE_DEBUG, but QT_QML_DEBUG.
More details: https://doc.qt.io/qt-5/qtquick-debugging.html#qml-debugging-infrastructure
If you still have issue after using the proper DEFINES and making sure that evry prerequisite was met, then you should try with a basic Qt program that does nothing, but display a simple QML item (like a Rectangle or a Button) ans see if you still have the issue.
I gather there is no universal standard for putting version numbers into executables on Linux, in contrast to Windows which requires a certain structure for those details.
FreePascal has made its own standard and Delphi lets you define Version information for a Linux executable.
If we can put Version information in, we must be able to get it back out? How? Specifically on Linux64?
I have searched *.pas and *.inc in Studio\19.0\source\rtl\posix and I have not found anything on 'version' nor 'fileinfo' that could help.
Back with Kylix, I used to use argp_program_version from libc.
On a clean new DUnitX project, after adding {$ *.res} to the DPR so that the version information will stick, I can look at Project Options for Linux64 and I can see that they have a CFBundleVersion number defaulting to 1.0.0 for the project. How can I get the CFBundleVersion at runtime in my Linux64 executable?
Or, if that is not possible, could/should Delphi match the FreePascal standard and put the fileinfo into something which both Lazarus and Delphi could view at runtime??
This excerpt (metioned at both Windows and MacOS/iOS sections) from https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Version_Info may help:
Go to Tools > Options > IDE > Environment Variables and add a new User variable called SAVEVRC with Value=TRUE. This variable enables the generation of a .vrc file with an auto generated build number and other information.
another excerpt from there (not sure if related to the aforementioned SAVEVRC or not) is:
Note: If you define the VersionInfo resource and add it to the project via a $R directive in the project file, the compiler will ignore settings of Version Info at Project Options dialog box and use the custom resource data instead, given an application can have only one VersionInfo resource on Windows.
In the C++ code (C# solution is OK: I can translate it to pure C++ or C++/CX) I need to check whether the code is working under Windows Phone 10 or not.
Rely on assumes which editions/SKU support which functions is a terrible bad design.
Call the D3D11CreateDevice call with D3D11_CREATE_DEVICE_DEBUG in Flags and if it returns DXGI_ERROR_SDK_COMPONENT_MISSING the debug layer is not avaible and call it again without this debug flag so that it works on Phone/Mobile, too.
Searching for D3D11_CREATE_DEVICE_DEBUG here on stackoverflow shows this topic on steps how to install the required data on mobile.
I am trying to use Julia with the Gtk package outside the REPL.
Using this code:
Using Gtk.ShortNames
win = #Window("My Window")
in the REPL works, but the same code put in a test.jl file and using:
julia test.jl
in the command line does not work.
I have tried the method written here: https://github.com/JuliaLang/Gtk.jl
Using Gtk.ShortNames
win = #Window("gtkwait")
# Put your GUI code here
if !isinteractive()
c = Condition()
signal_connect(win, :destroy) do widget
notify(c)
end
wait(c)
end
The code runs but no window appears.
If it's any help, I'm on Manjaro Linux with 4.1 Linux Kernel and have both GTK2 and GTK3 librairies installed.
Your code, which is literally what the documentation says to do, doesn't work for me either (Julia 0.4.0, Gtk.jl 0.9.2). Maybe the documentation is outdated.
What works is to use Gtk.gtk_main and Gtk.gtk_quit:
using Gtk.ShortNames
win = #Window("Hello")
signal_connect(win, :destroy) do widget
Gtk.gtk_quit()
end
Gtk.gtk_main()
I don't know if this is the "right" way, but it does work and is closer to how things work in GTK+'s C API (with gtk_main and gtk_main_quit).
I developed an application using a recent Glade, so I need it to load the UI from XML at runtime, using the GtkBuilder. If I try to run this on a distro which has too old a Gtk (e.g. RHEL 5), it will fail like this
undefined symbol: gtk_builder_new
which is normal and expected. But I wonder if there is a way to catch that error and instead display a GUI error dialog saying something like "your version of Gtk is not new enough"? This is an error that happens before my main() starts, so really the question is, is there a way to handle runtime linking errors? While googling, I found a mention of the concept of a linker plugin but I didn't find details about that yet. It sounds like something which would have to exist outside my application anyway, so maybe that's going a bit far.
I could use dlopen() to load Gtk, but that's ridiculous because I'd have to give the full path to it, and then I'd have to call dlsym() a lot to link every function that I need. ld-linux.so does the search for me. Is there a way I can use ld-linux.so to tell me the path to libgtk without actually loading it, then I check whether the version is new enough (or just whether gtk_builder_new exists), then finish the runtime linking if it's OK?
Well, it doesn't work that way on a Linux distro. What you're basically doing is bypassing the package manager.
The good way is to build your software on the target distro. At configuration time (call to ./configure) you will see that the requirements to use your software are not met. Or if you have no configure script, the compiler will yell at link time.
Then, it's the packager's job to fill in the requirement of the package. If in the .spec file of your RPM package you require gtk >= 2.16, then at installation time, the user will be shown the dialog telling him that some dependencies are missing, and he will see that his GTK version is too old.
You seem to be talking about the situation where you have compiled against headers with a recent enough version, but are running on a system where your library is not recent enough.
GTK provides a facility for checking that you have linked against a new enough version of the library. For example, if you need at least GTK 2.12 (which is the version in which GtkBuilder was introduced) you can use this code which will even display a nice GUI error dialog:
if (gtk_major_version < 2 || gtk_minor_version < 12) {
GtkWidget *dialog = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL,
GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE,
"Your version of GTK is too old to run this program.");
gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(dialog),
"You need at least version 2.12.0; your version is %d.%d.%d.",
gtk_major_version, gtk_minor_version, gtk_micro_version);
gtk_dialog_run(GTK_DIALOG(dialog));
gtk_widget_destroy(dialog);
exit(-1);
}
Here is a workaround which might help: Rename your exe and create a bash script which calls it.
Now you can do this:
EXE=...name-of-your-real-executable...
LOG=logfile
$EXE > "$LOG" 2>&1 || {
if grep "undefined symbol: gtk_builder_new" "$LOG" ; then
... show error message ...
fi
}
[EDIT] Alternatively, you can create a really small test program which just contains a call to gtk_builder_new and run that during installation or in the test script.
That way, you don't need to check for a specific error message (which might get translated on non-English systems). If this small test program fails, you can be sure it's because of this missing symbol and nothing else.