[Problem] Misleading conflict shortcuts error message #8708
Comments
|
Hi @Fat-Zer nice to see you active again :) |
|
I've dug a bit dipper into the issue, and it looks like the message is originating from KDE, namely the kxmlgui lib... This library when being loaded injects its own event filter which produces an error if a conflicting shortcut is triggered. This prevents FreeCAD from handling the conflict by it's own means... According to the backtrace (see bellow) it looks like that the loading chain of the kde library is The problem is that QUiLoader has no direct means of preventing external plugins from being loaded. The only solution I can think of is to reset The issue with inability to change shortcuts is probably a separate one. I probably should report both bugs separately from this issue...
hi, thanks... haven't respond earlier to not flood bug comments with flame... at least without bug update))... |
|
Cool, nice sleuthing! please feel free to link upstream bug reports to this ticket so we can track the progress |
As for this claim, it's a bit embracing, but I overlooked how it's supposed to work: You should enter a new shortcut into the field helpfully called |
Fat-Zer
changed the title
|
I filled in upstream bugs: Though I believe we still should implement the workaround, because those are relatively minor and a bit controversial issues (more design flaws than bugs)... So I don't expect they will get a lot of attention... And even after that the fixes won't propagate into a release anytime soon... |
Due to a flaw in the QUiLoader, UiLoader were loading all designer plugins it can find in QApplication::libraryPaths(). This in general a bad practice and leads to bugs due to some plugins may perform some unexpected actions upon load which may interfere with FreeCAD's functionality. To avoid such problems reset the libraryPaths before creation of a UiLoader object. Also move setLanguageChangeEnabled(true) into constructor due to it's called every time it's being instanced anyway. See: FreeCAD#8708
Due to a flaw in the QUiLoader, UiLoader were loading all designer plugins it can find in QApplication::libraryPaths(). This in general a bad practice and leads to bugs due to some plugins may perform some unexpected actions upon load which may interfere with FreeCAD's functionality. To avoid such problems reset the libraryPaths before creation of a UiLoader object. Also move setLanguageChangeEnabled(true) into constructor due to it's called every time it's being instanced anyway. See: FreeCAD#8708
Due to a flaw in the QUiLoader, UiLoader were loading all designer plugins it can find in QApplication::libraryPaths(). This in general a bad practice and leads to bugs due to some plugins may perform some unexpected actions upon load which may interfere with FreeCAD's functionality. To avoid such problems reset the libraryPaths before creation of a UiLoader object. Also move setLanguageChangeEnabled(true) into constructor due to it's called every time it's being instanced anyway. See: #8708
Due to a flaw in the QUiLoader, UiLoader were loading all designer plugins it can find in QApplication::libraryPaths(). This in general a bad practice and leads to bugs due to some plugins may perform some unexpected actions upon load which may interfere with FreeCAD's functionality. To avoid such problems reset the libraryPaths before creation of a UiLoader object. Also move setLanguageChangeEnabled(true) into constructor due to it's called every time it's being instanced anyway. See: FreeCAD#8708
Due to a flaw in the QUiLoader, UiLoader were loading all designer plugins it can find in QApplication::libraryPaths(). This in general a bad practice and leads to bugs due to some plugins may perform some unexpected actions upon load which may interfere with FreeCAD's functionality. To avoid such problems reset the libraryPaths before creation of a UiLoader object. Also move setLanguageChangeEnabled(true) into constructor due to it's called every time it's being instanced anyway. See: FreeCAD#8708
Is there an existing issue for this?
Version
0.20 (Release)
Full version info
Subproject(s) affected?
None
Problem description
When some workbench has conflicting shortcuts an error message is shown that says:
But there is neither a menu called 'Settings' nor a 'Configure Keyboard Shortcuts' entry. At least I couldn't found such. There is a tab in
Tools->Customize->Keyboard, but (1) it suggests that one shortcut should be prioritized over another in case of ambiguity and (2) the field 'Current shortcut' as well as 'Assign' button are appear to be disabled, so I see no way to change a shortcut.So to recap the issues are:
GUI doesn't provide an ability to modify a shortcutAnything else?
No response
Code of Conduct
Update
The bug is a bit more specific to surroundings when I thought initially, so I'll add some more concrete instructions to reproduce it.
How to reproduce
Install some kde libraries, namely
kxmlguiand its designer pluginplugins/designer/kxmlgui5widgets.so. In Debian they will be respectively inlibkf5xmlgui5andlibkf5xmlgui5-devpackages.apt-get install libkf5xmlgui5 libkf5xmlgui5-devSwitch to non-KDE DE (e.g. gnome shell or lxqt) and run FreeCAD
In
Tools->Customize->Keyboardassign several actions the same shortcut combination (FreeCAD should handle it correctly because different workbenches may have overlapping hotkeys)e.g.
O, Pfor bothFile->OpenandWeb->Open websiteSwitch to some python-driven workbench i.e.
DraftorArchSwitch to the workbech where conflict should appear (and be resolved by FreeCAD)
e.g. with combination above to
StartPress the shortcut combination
The error message shown above should appear.
The text was updated successfully, but these errors were encountered: