1. Launch knetwalk, a game starts immediately * Notice slightly bigger host and world symbols. * In very rare cases a cable is on top of instead of under a host. 2. Do not do anything, but start a new game with ctrl+N * Notice that symbols have shrunk. * It is not a new game, but exactly the same as the first one. See attached screen capture for a demonstration. This is KNetWalk 3.3.0: > Using: > KDE Frameworks 5.13.0 > Qt 5.5.0 (built against 5.4.2) > The xcb windowing system
I forgot: the program prints out these messages when starting up: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-neo' Module 'org.kde.games.core' does not contain a module identifier directive - it cannot be protected from external registrations. games.ui: KStandardGameAction::create( 1 = game_new , KActionCollection(0x24f19c0, name = "KXMLGUIClient-KActionCollection") ) games.ui: KStandardGameAction::create( 7 = game_pause , KActionCollection(0x24f19c0, name = "KXMLGUIClient-KActionCollection") ) games.ui: KStandardGameAction::create( 25 = move_solve , KActionCollection(0x24f19c0, name = "KXMLGUIClient-KActionCollection") ) games.ui: KStandardGameAction::create( 8 = game_highscores , KActionCollection(0x24f19c0, name = "KXMLGUIClient-KActionCollection") ) games.ui: KStandardGameAction::create( 11 = game_quit , KActionCollection(0x24f19c0, name = "KXMLGUIClient-KActionCollection") ) And nine times this message whenever running a new game afterwards: file:///usr/share/knetwalk/qml/Cable.qml:22: TypeError: Cannot read property of null (btw: The second game is not always the same as the first one. Only maybe in 50% of the cases.)
Created attachment 94318 [details] Screen capture of bug demonstration Sorry, seems I forgot the attachment.
Created attachment 94902 [details] And sometimes happens this.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Still reproducible with 3.3.22043.
Bug is still present in 3.3.23085