I'm trying hard to get a list of style properties for a GtkWidget (GtkButton). This is my code so far:
#include <gtk/gtk.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (int argc, char *argv[])
{
// Declare variables.
GtkWidget *btn = gtk_button_new();
guint *count = {0};
GParamSpec **list = NULL;
// Initialize gtk.
gtk_init(&argc, &argv);
// Get style properties.
list = gtk_widget_class_list_style_properties(GTK_WIDGET_CLASS(btn), count);
// Exit cleanly.
exit(EXIT_SUCCESS);
}
I get a clean compile with:
gcc -o gtk_test gtk_test.c `pkg-config --cflags --libs gtk+-3.0`
But I get the following errors when run:
(process:72182): Gtk-CRITICAL **: 10:42:23.167: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
(process:72182): Gtk-CRITICAL **: 10:42:23.167: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
(process:72182): Gtk-CRITICAL **: 10:42:23.167: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Segmentation fault
I don't think I'm doing it right, but I can't find any examples that use gtk_widget_class_list_style_properties that I understand. They ones I do find use klass and the first argument. But I can never find where klass is declared or even what it is.
Can someone please help point me in the right direction? I went to the gtk website and did a search on GTK_WIDGET_CLASS and it came back with nothing! Very frustrating to say the least.
What am I supposed to use for the GTK_WIDGET_CLASS argument that will return the style properties for a GtkButton?
I tried out your sample code. Actually, it looks like you just have the incorrect macro. Instead of:
GTK_WIDGET_CLASS(btn)
try:
GTK_WIDGET_GET_CLASS(btn)
I tried that and then received no critical messages.
Regards.
Related
I am currently learning C and am trying to understand the possibilities of dynamic libraries.
My current question is, if I have a simple "Hello World" application in C called "ProgA", and this program dynamically loads a shared library with some example code called "LibB", can LibB access a global variable in ProgA, which was declared as external?
Given is the following example code for demonstration of the problem:
file header.h
#ifndef TEST_H
#define TEST_H
typedef struct test_import_s {
int some_field;
} test_import_t;
extern test_import_t newtestimport;
#endif
file prog_a.c
#include <stdio.h>
#include <windows.h>
#include "header.h"
test_import_t newtestimport = {
.some_field = 42
};
int main()
{
HINSTANCE hinstLib;
typedef void (*FunctionPointer)();
newtestimport.some_field = 42;
hinstLib = LoadLibrary("lib_b.dll");
if (hinstLib != NULL)
{
FunctionPointer initialize_lib_b;
initialize_lib_b = (FunctionPointer)GetProcAddress(hinstLib, "initialize_lib_b");
if (initialize_lib_b != NULL)
{
initialize_lib_b();
}
FreeLibrary(hinstLib);
}
return 0;
}
file lib_b.c
#include <stdio.h>
#include "header.h"
test_import_t *timp;
void initialize_lib_b() {
timp = &newtestimport;
int some_field = timp->some_field;
printf("Result from function: %d\n", some_field);
}
file CMakeLists.txt
cmake_minimum_required(VERSION 3.24)
project(dynamic-library-2 C)
set(CMAKE_C_STANDARD 23)
add_library(lib_b SHARED lib_b.c)
set_target_properties(lib_b PROPERTIES PREFIX "" OUTPUT_NAME "lib_b")
add_executable(prog_a prog_a.c)
target_link_libraries(prog_a lib_b)
In the above example, the headerfile header.h defines the struct test_import_t and an external variable newtestimport using this struct. In the C file of the main program prog_a.c one property of this struct is assigned the value 42. It then dynamically loads the library lib_b.c using the Windows API and executes a function in it. The function then should access the variable newtestimport of the main program and print out the value of the variable (42).
This example does not work. The compiler throws the following error:
====================[ Build | prog_a | Debug ]==================================
C:\Users\user1\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\223.8617.54\bin\cmake\win\x64\bin\cmake.exe --build C:\Users\user1\projects\learning-c\cmake-build-debug --target prog_a -j 9
[1/2] Linking C shared library dynamic-library-2\lib_b.dll
FAILED: dynamic-library-2/lib_b.dll dynamic-library-2/liblib_b.dll.a
cmd.exe /C "cd . && C:\Users\user1\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\223.8617.54\bin\mingw\bin\gcc.exe -fPIC -g -Wl,--export-all-symbols -shared -o dynamic-library-2\lib_b.dll -Wl,--out-implib,dynamic-library-2\liblib_b.dll.a -Wl,--major-image-version,0,--minor-image-version,0 dynamic-library-2/CMakeFiles/lib_b.dir/lib_b.c.obj -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:\Users\user1\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\223.8617.54\bin\mingw\bin/ld.exe: dynamic-library-2/CMakeFiles/lib_b.dir/lib_b.c.obj:lib_b.c:(.rdata$.refptr.newtestimport[.refptr.newtestimport]+0x0): undefined reference to `newtestimport'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
How can the example be fixed to accomplish the described goal?
Windows DLLs are self-contained, and can not have undefined references similar to newtestimport, unless these references are satisfied by another DLL.
How can the example be fixed to accomplish the described goal?
The best fix is to pass the address of newtestimport into the function that needs it (initialize_lib_b() here).
If for some reason you can't do that, your next best option is to define the newtestimport as a dllexport variable in another DLL, e.g. lib_c.dll.
Then both the main executable and lib_b.dll would be linked against lib_c.lib, and would both use that variable from lib_c.dll.
P.S. Global variables are a "code smell" and a significant source of bugs. You should avoid them whenever possible, and in your example there doesn't seem to be any good reason to use them.
#include <iostream>
#include <windows.h>
#include <psapi.h>
#include <tlhelp32.h>
HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, 7632);
wchar_t lpFilename[1024];
GetModuleFileNameExW(hProcess, NULL, lpFilename, sizeof(lpFilename));
qDebug() << QString::fromWCharArray(lpFilename);
CloseHandle(hProcess);
The above code runs normally in vs2019, but when I use it wrong in qt, this error occurs:
error: undefined reference to `GetModuleFileNameExA'
error: ld returned 1 exit status
Need to load Psapi.lib
Add in the <project name>.pro file
...
LIBS += \
-lPsapi
...
One of the programs that I work with has two modes that it can run in: GUI (Graphical User Interface) mode or CLI (Command-Line Interface) mode. We determine which mode to use via a command line argument (i.e., if "--cli" is passed, it will use CLI mode).
The type of QApplication that is instantiated depends on which mode is used: QApplication should be used for GUI mode, and QCoreApplication should be used for CLI mode, because the GUI parts of Qt should not be instantiated for CLI mode (since CLI mode does not use or need them).
I can do that via code similar to the following:
std::unique_ptr<QCoreApplication> app =
(cliMode) ? std::make_unique<QCoreApplication>(argc, argv)
: std::make_unique<QApplication>(argc, argv);
// Do some other stuff...
return app->exec();
Since I am already using Qt, it makes sense to use QCommandLineParser to parse my arguments. After parsing the arguments, I want to analyze them to determine whether we should run in GUI mode or CLI mode. However, it has been becoming increasingly difficult to do so.
The first problem I noticed was the following on Linux (this did not happen in older versions of Qt5, but it does happen in the newer versions):
$ ./myQtApplication --help
QCoreApplication::arguments: Please instantiate the QApplication object first
Segmentation fault (core dumped)
Okay: so I can no longer run the --help command without already having a QApplication object instantiated. I temporarily fixed this by manually parsing the arguments to see whether or not --help is an argument. If it is, go ahead and instantiated the QCoreApplication, parse the arguments, and then exit.
But then I started getting a cryptic error on Mac OS X. When I would run the executable on OS X directly, it would run without any issues. But if I tried to double-click on the .app file or type in the terminal $ open myQtApplication.app, I would get this cryptic error:
LSOpenURLsWithRole() failed with error -10810 for the file ./myQtApplication.app
Since it is a rather cryptic error, it took me a long time to figure out that this error was being caused by the QCommandLineParser being used before having a QApplication object instantiated.
To fix this, I am now doing the following:
Manually parse the arguments at the beginning of the main() function to determine whether or not --cli was passed.
Instantiate a QApplication object based on the results of #1.
Run QCommandLineParser to process the rest of the arguments.
This is not a very clean way to do this because I now have two argument parsers: one to determine if --cli was passed, and the rest for the other arguments.
Is there a much better, or "proper", way to do this?
I guess the main question is: can I use QCommandLineParser to determine whether to instantiate a QCoreApplication object or a QApplication object?
Of course you can use the parser - as long as QCoreApplication already present. If the --cli option is absent, you will switch to a QApplication. Recall that you have full control over the lifetime of the application object.
This works under Qt 4.8 and 5.11 on both Windows and OS X:
// https://github.com/KubaO/stackoverflown/tree/master/questions/app-cli-gui-switch-52649458
#include <QtGui>
#if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
#include <QtWidgets>
#endif
struct Options {
bool cli;
};
static Options parseOptionsQt4() {
Options opts = {};
for (auto arg : QCoreApplication::arguments().mid(1)) {
if (arg == "--cli")
opts.cli = true;
else
qFatal("Unknown option %s", arg.toLocal8Bit().constData());
}
return opts;
}
static Options parseOptions() {
if (QT_VERSION < QT_VERSION_CHECK(5, 0, 0)) return parseOptionsQt4();
#if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
Options opts = {};
QCommandLineParser parser;
QCommandLineOption cliOption("cli", "Start in command line mode.");
parser.addOption(cliOption);
parser.process(*qApp);
opts.cli = parser.isSet(cliOption);
return opts;
#endif
}
int main(int argc, char *argv[]) {
QScopedPointer<QCoreApplication> app(new QCoreApplication(argc, argv));
auto options = parseOptions();
if (options.cli) {
qDebug() << "cli";
} else {
qDebug() << "gui";
app.reset();
app.reset(new QApplication(argc, argv));
}
if (qobject_cast<QApplication *>(qApp))
QMessageBox::information(nullptr, "Hello", "Hello, World!");
QMetaObject::invokeMethod(qApp, "quit", Qt::QueuedConnection);
return app->exec();
}
I am trying to use only aes in my program. I have copied the files
config.h
aes.h
havege.h
to the folder polarssl. But when I run the program
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "polarssl/aes.h"
#include "polarssl/havege.h"
int main()
{
char buff[2][64] = {"ABCDEFGHIJKLMN", ""};
havege_state hs;
int retval;
unsigned char IV[16];
unsigned char IV2[16];
unsigned char key[32];
aes_context enc_ctx;
aes_context dec_ctx;
havege_init(&hs);
havege_random(&hs, IV, 16);
havege_random(&hs, key, 32);
strncpy(IV, IV2, 16); //copy IV
aes_setkey_enc(&enc_ctx, key, 256);
aes_setkey_dec(&dec_ctx, key, 256);
//encrypt
aes_crypt_cbc(&enc_ctx, AES_ENCRYPT, 64, IV, buff[0], buff[1]);
printf("Before encrypt:%s\n", buff[0]);
//decrypt
aes_crypt_cbc(&dec_ctx, AES_DECRYPT, 64, IV2, buff[1],buff[0]);
printf("After decrypt:%s\n", buff[0]);
return 0;
}
I am getting the error
In function `main':
ex.c:(.text+0x68): undefined reference to `havege_init'
ex.c:(.text+0x86): undefined reference to `havege_random'
ex.c:(.text+0xa4): undefined reference to `havege_random'
ex.c:(.text+0xe0): undefined reference to `aes_setkey_enc'
ex.c:(.text+0xfe): undefined reference to `aes_setkey_dec'
ex.c:(.text+0x133): undefined reference to `aes_crypt_cbc'
ex.c:(.text+0x17e): undefined reference to `aes_crypt_cbc'
collect2: error: ld returned 1 exit status
Next to the header files, you will also need the .c files! (aes.c, havege.c) and compile those in your code.
On the implementation side:
* Are you sure you want to use HAVEGE? There are lots of doubts on its effectiveness (depending on the system you run on), the standardized CTR-DRBG seems to be a much better choice..
I think your error has something to do with linking to the Aes and Havege files. Your compiler is not recognizing them!
Are they in the same folder as your main? If they are in the same folder, then remove the "polarssl/" from the headerfile name at the top.
Or maybe, when compiling be sure to include aes.c and aes.h too. I found that I was getting the same error due to this. I was only including aes.h in compiling.
Example
$terminal: gcc main.c aes.h aes.c -o encrypt
Just wondering?
If you want to use only aes, why are you trying to use havege.h?
I've tried to embed emacs in a Qt Application using QX11EmbedContainer, and works but with two important exception. First of all, here is the code:
#include <QX11EmbedWidget>
#include <QtGui>
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QX11EmbedContainer container;
container.show();
container.resize(500, 500);
QProcess* process = new QProcess(&container);
QString executable("emacsclient");
QStringList arguments;
arguments << "--parent-id" << QString::number(container.winId());
process->start(executable, arguments);
int status = app.exec();
process->close();
return status;
}
And the compilation and execution line (and the previous thrown of the emacs server):
$ emacs -q --daemon &
// filtered output
$ g++ test.cpp -lQtGui -lQtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4
$ ./a.out
And finally, the result:
But, when or if I try to write something in the minibuffer, the size of the widget is collapsed, and the focus is also lost:
If I make click in the (now shorter) widget, I can continue working with emacs without problems, but I should resize the window in order to emacs is expanded other time as originally.
Where is the problem?
Try using a layout.
Here is the Qt5 documentation on layout management.