Version: 2.0.0 (using KDE 4.0.5) Installed from: Ubuntu Packages I am a KNetWalk expert. I don't fumble about guessing at the correct solution, when I move a piece I do it because I am 100 percent certain. I am sure that there are many people like me who ''always'' solve the puzzle in the least amount of moves. Every time after I move a piece I lock it. There should be an option (not turned on by default, of course) to lock a piece after it is moved.
You can lock a piece with no penalty using the central mouse button or using the space bar when in keyboard mode. However I agree that the two ways shouldn't be mutually exclusive (which they currently are), It wasn't me who implemented keyboard support, I want to improve it for 4.2, and maybe even some changes will go into 4.1.1.
I actually quickly hacked this "feature" together on my local copy a while back, as I too thought it might be a time saver. (I hadn't seen this bug.) I ended up reverting the change after trying it for a few games, due to an unforeseen complication. The problem is that 25% of the pieces never get moved and therefore never get autolocked. This means that you're either left with "holes" in your solid blocks of locked pieces or you have to manually lock the unmoved pieces. In the end I found that I was faster without the autolocking, because locking every cell on reflex actually took less time than deciding which cells required manual locking and which didn't. I agree with Fela that being able to play two-handed (with the keyboard and mouse) would be the ideal solution. Unfortunately, that's almost impossible to implement with the current KNetwalk design as the keyboard controls are totally separate from the mouse controls.
Created attachment 32602 [details] the patch :)
Here is a patch I propose, which changes multiple things (which all can be activated individually in the settings): 1. auto-locking of pieces after they are rotated 2. auto-locking of adjacent pieces if you lock a piece 3. changing of cable animation time (fixes #186483) 4. advanced input mode, using Mouse and Keyboard together The changes in detail: - added a page to the settings dialog where you can check if you want all these things (they are all configurable independently of each other), and removed the "Use Keyboard" entry in the menu - changed the animation algorithm of the cells so as to be compatible with the implementation of feature #2 (no visual difference, and a reduction in code size) - added a lock() method which checks for feature #2 and helps in implementation of feature #1 - feature #1: after you have rotated a cell (i.e. when you change the next cell) it will be locked automatically. This counts as a normal lock (i.e. as if you had clicked with the mouse or used the keyboard), and so is 100% compatible with feature #2 - feature #2: if a cell is locked, the adjacent cells will be checked if they can be surely locked, i.e. there is no other position where they can fit with the already locked cells (p.ex. a vertical bar next to another which is already locked). This helps with the problem of Parker Coates where cells are not locked because they are never rotated. This is also useful as a feature of its own, it's my favourite style of play now :) - feature #3: added an option to the settings dialog to change the animation time (from 0 to 1000 ms). For this I had to change some details of the cell implementation. Did I mention it closes #186483 ? - feature #4: The settings page has an option to play with mouse or keyboard alone (as it has been until now), or to use a combined mode in which a cell is selected as the mouse hovers over it, and you can use the mouse and the keyboard to rotate or lock it I have so far not found errors in testing, please test also!
I'm on holidays for two weeks now, when I'll be back there'll be an updated patch. So don't hurry in fixing this.
I'm back again with an updated patch. This one corrects a small error in the previous patch and adds feature #5: In expert mode (or in principle any mode where you can connect cables at the frontier) you can shift the board to make it easier to see the connections. By default this is with PageUp/Down, Home and End, but of course changeable in the options. I can provide small patches for each of the features if that's necessary, but I think the changes are not too big. Just drop a line if you have any questions.
Created attachment 36580 [details] the updated patch, should patch cleanly against 4.3.0
I'm a bit busy right now, I will look at it in a month or so. But I'll just make a quick note: we should think about what the purpose of the game is. For an advanced player autoblocking obviously correct (for him) cells makes sense. But for a novice player just starting to play the easy level, the computer would be doing much of the job he should be doing. Of course one can choose not to enable the feature, but then those who enable it would have an unfair advantage in the high score list. And I'm convinced that a fair high score that isn't too easy to cheat is important to make a game more fun. I'm not really sure animation time is worth a configuration option, even very simple options like this always have a cost in additional code complexity (not so much), in configuration panel complexity (still not much, but a little more), so I ask myself, does animation speed really matter? You don't have to wait for the animation to finish, after all. Being able to shift the board in expert mode seems like a nice idea. I was thinking about something related: to repeat the border rows and columns but make the copies fade away, so if I had the following row: 1233333345 1 would be a copy of 4 and 5 of 2, but not drawn in full: instead the copies would fade away. I hope made myself clear... I'll think about it and have a closer look at your patch as soon as I've got time.
Markus, I would definitely recommend splitting it up into separate patches. As Fela mentions, some of these changes are controversial. Splitting them up would allow us to handle them one at a time. I would recommend putting them up at reviewboard.kde.org as that increases visibility and eases discussion. I haven't tested your patch yet, but reading through it I have some concerns. For example, I don't see any reason to offer "keyboard only" or "mouse only" modes. If "keyboard and mouse" works, then the other two, along with all the mode logic can be removed. (On a side note, the three modes should have been implemented in the .kcfg file as a single Enum property, not as three generically named Bools.) Anyway, these kind of things are easier to handle on reviewboard.
I agree with the fact that a "mouse and keyboard" mode that works in all cases is the best solution. It's actually been on my mental todo list for some time :) /me wants git =)
I didn't know how to implement an Enum in the .kcfg file, so I used three bools instead :) And I couldn't find a good documentation anywhere, maybe you can point me to one. Of course, if you know how to correct this, I'd be more than happy to hear it. Animation speed matters for me, and Configurability has always been the reason I preferred KDE over Gnome (well of course there's more - HotNewStuff is just plainly wonderful, just as the playlist configuration in Amarok). And the configuration interface with a category list on the left side is way less complexity and more Intuitivity than the Tabs before, so I think it's manageable. I'd default to let all the options set to "off". It is still a fair highscore even with this option enabled. Clicking speed is more important than auto-locking, and auto-locking helps with (for the power-player) unimportant issues. That's my opinion, at least. If you can beat 30 seconds with auto-locking on in expert mode and you cannot beat 40 seconds with auto-locking off, I'm ready to change it. The issue with having mouse and keyboard and both as separate options is that in pure-keyboard mode, the cell to be rotated is chosen by keyboard and doesn't change when the mouse moves; while in combined mode the cell below the mouse is the selected one. I agree though that mouse-only mode is superfluous :) I think having tiles of the other side as a shadow copy is a nice idea, but then in expert mode the tiles will be too small on a small screen (like on a netbook), as they are already now quite small. Probably I'll have time next week-end to split the patch, maybe try getting shadow copies and post them on reviewboard. Thanks for the feedback!
For an example of an Enum, see kdegames/killbots/killbots.kfcg. It's kind of a moot point now that we've determined we don't actually need three modes, though.
There is a review now at http://reviewboard.kde.org/r/1597/.
Git commit 41c95b4fab19f0ed6906fa7157a16b4ccef49cb0 by Ashwin Rajeev. Committed on 06/09/2013 at 08:48. Pushed by rajeev into branch 'master'. Auto lock and custom rotate duration Related: bug 186483 M +1 -1 src/CMakeLists.txt M +6 -0 src/customgame.ui M +11 -0 src/gameview.cpp M +2 -0 src/gameview.h C +25 -18 src/general.ui [from: src/customgame.ui - 060% similarity] M +12 -2 src/knetwalk.kcfg M +1 -4 src/knetwalkui.rc M +16 -11 src/mainwindow.cpp M +0 -1 src/mainwindow.h M +1 -1 src/qml/Cable.qml M +5 -0 src/qml/main.qml http://commits.kde.org/knetwalk/41c95b4fab19f0ed6906fa7157a16b4ccef49cb0