General and Desktop

This problem is a specific Linux problem when the local graphics drivers are NVIDIA, but the linked libGL.so is not the NVIDIA version. This is the Ubuntu bug that explains the issue, it is 4 years old! People on the PyQt mailing list provided this info, and suggested a simple work-around. Add the following code early in the setup of the app: if sys.platform.startswith( 'linux' ) : from OpenGL import GL The GL module will import the correct (openGL.so.1) dll. Another suggested approach was to use ctypes, import ctypes ctypes.cdll.LoadLibrary("libGL.so.1") I did not try this. A third approach would be to find the system libGL.so and symlink it to libGL.so.1 however when I poked around the innards of Ubuntu 16 (64-bit) the number and links-between of the various libGL* files were more complicated than this simple idea would suggest so I did not try it.

Nevermind, I got it working by manually deleting the generated bundle and following it with a qmake and rebuild.

my bad I didn't know that in gnome shell 3.14 the bar of notifications ( with tray ) could be access by pressing Super + M it appears bottom[image: e1534ee9-1d3b-43fb-a099-ad7fe8a91021.png]

@amezei : If you are trying to set window Icon can use app.setWindowIcon(QIcon("./Icon"));

The most similar solution of what I think I need found it here: https://stackoverflow.com/questions/31836199/how-to-store-qt-signal-slot-names-to-a-data-structure

@Tofu_panda , You should use, emit sendData(data1);

@raven-worx said in How To Close QMenu: QAction* action = myMenu->exec(ui->tableWidget->mapToGlobal(pos)); if( action == editUserAction0 ) this->EditSLOT() else if ( action == editUserAction1 ) this->RemoveSLOT() } Oh its good. Thank you for this.

@Qt-Enthusiast On Unix, NativeFormat and IniFormat mean the same thing, except that the file extension is different (.conf for NativeFormat, .ini for IniFormat).

@kuntoro Hi and welcome to devnet @kuntoro said in LNK1104: cannot open file 'qtmaind.lib': Microsoft Visual C++ 2015 and 2017 installed You mean you have installed both MSVC versions? @kuntoro said in LNK1104: cannot open file 'qtmaind.lib': Qt version 5.9.1 This is the Qt version, but you have to tell us also for what compiler those binaries are pre-compiled. What is the IDE you are using? You want to use Qt directly from MSVC IDE? Or do you want to use Qt's native IDE Qt creator?

Did you try to just disable that warning when you're on twitter.

Hi, Glad you found out but that design is pretty bad. You are creating a tight coupling where none is needed. If you want that dialog to trigger something in your other widget, then just give that dialog a signal and connect it before calling exec.

With: query.addBindValue(ui->eNaziv->text()); query.addBindValue(ui->eStanje->value()); query.addBindValue(ui->eDatum->dateTime().toString()); result is the same: QIBaseResult::exec: Parameter mismatch, expected 0, got 3 parameters

Ah, I hadn't spotted this library - this is a slightly nicer way to read the header of a wav file than the way I did it. I may switch to this library at some point.

Great ! Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)

Sounds strange... But glad you could get it to work :)

The issue is with using a menu that is not native to OS X. The shortcuts from the non-native menu actions don't seem to trigger anything. In the UI designer view, you need to to check the native menu box in the top level menu properties, and you need to make the shortcuts application level shortcuts. There is a checkbox on the QAction properties for this. You can also do it programmatically like so: QAction *myAction = new QAction("My action"); myAction->setShortcut(QKeySequence("CTRL+M")); myAction->setShortcutContext(Qt::ApplicationShortcut); QMenu *myMenu = new QMenu("My Menu"); myMenu->addAction(myAction); ui->menuBar->addMenu(myMenu); ui->menuBar->setNativeMenuBar(true);

@J.Hilk This would of course be the normal way to go – in this case, the program is quite a niche solution, and for that reason I didn't write the default messages in English (as usual), but directly in German, as this program will not only be only used in Germany, but only in a very small part of it – and will definitely never have an international userbase. Well, probably, I'll change that nevertheless for the sake of professionality. I only really wonder why I get the correctly localized default texts on Linux, but not on Windows, although the correct locale is set on both systems (and e. g. a file dialog does appear localized with the Windows build).