Version: unspecified (using KDE 4.5.95) OS: Linux With new versions of kwin, you can click and drag in certain parts of windows to move the window. This is normally useful, since it doesn't effect parts of windows you normally would do click and drag operations in. However, with a number of KDE games, this causes problems. The "game board", part of the game that players interact with, can be clicked and dragged. This normally does not apply to the actual game pieces, but slight miss-click will lead to moving the window accidentally. This is not the case with all games. I have checked all the games installed on my system, and this is the result: Games that have this problem: bomber, kpatience, kblocks, ksnakeduel, kspaceduel, kpeg, kblackbox, kfourinline, kigo, kiriki, kreversi, ksquares, ktic-tac-toe, lskat, ksimili, blinken, kanagram, khangman, katomic, kbounce, klickety, kmines, knetwalk, kolor lines, konquest, Games that do not have this problem: palapeli, granatier, kapman, kbreakout, kgoldrunner, kollision, bovo, kbackgammon, kmahjongg, knights, mancala, naval battle, shisen-sho, potato guy, kpicross, krossword, ksudoku, kubrick, nonogram, kolf, killbots, kjumpingcube, ksirk, ksamegame I know some of these games are in early stages, unmaintained, or both, but I thought I would include all the ones installed on my system in case this provides additional information that could be used to fix the problem. Games where you have to click and drag to move small objects, like the card games, are a particular problem since it is easy to miss the card by a small amount and move the window, even unmaximize it. But any game where you have to click could cause a problem, since a slight accidental jerk of the wrist could move the window around. Reproducible: Always
> With new versions of kwin, you can click and drag in certain parts of windows to move the window it's the widget style not the window manager. The window manager has no idea what the window looks like.
Thanks for the detailed report. I can have a look at some of these games, to see if oxygen's dragging feature can be improved, or if intervention in the game code itself is required. Will keep you posted. In the meanwhile you can disable the feature by typing "oxygen-settings" (in konsole or krunner) and change the corresponding option (in front page).
I've been through "some" of the games. Namely kpat, and knetwalk. As far as I can tell there is no "bug" here. In the sense that nowhere there is a conflict between the window grab and the actual playing of the game. Are there games in the list where there is an actual conflict (which then should be fixed) ? When there is no conflict, what you report is a usability issue with respect to the feature. (namely, if you miss your click you get a different behavior). The same is then true for any application (where you can miss a button, and start dragging the window instead), and the only cure is to simply disable the feature. This is possible via oxygen's settings (oxygen-settings) and I don't think the case for games is "strong enough" to disable the feature by default. For knetwalk for instance, it is actually pretty hard to find an area from which you can actually drag the window. Do you agree ? I'm open for discussions on the matter. Now maybe, disabling the feature should be made easier to users (I agree that oxygen-settings is a somewhat hidden application). So to summarize - please tell me if there are games for which there actually is a bug (a conflict) - for the usability case, I would say its not a bug, its a feature to disable on a per-user basis (and maybe this should be made easier to users). Side note: the "unmaximize by moving" feature is a side effect of kwin's "quick maximize" feature. If you disable it, you cannot move windows (neither from title bar nor contents) when maximized, nor unmaximize them.
I am not aware of any direct conflicts. However, there are three issues: 1. You don't normally dragging buttons, but you do often drag items in games. Further, there are few, if any cases, where drags happen as often as in games. Sure, you might drag dividers occasionally, but it is not the standard way you interact with a window, while it is in some games. 2. It is inconsistent, some games boards can be dragged while some cannot, in fact in games some parts of game boards can be dragged while other identical-looking parts of the same board cannot. There is no visual hint or visual consistency in what can and cannot be dragged between games and in some cases within the same game. 3. The game boards do not look like the parts of windows you normally drag. In other applications the gray parts (in the default color scheme) can be dragged while the "work" area, which is often white, cannot. The visual design of the game boards bear more resemblance to the work area of other applications, so for consistency with the rest of KDE they should probably not be draggable. In same games, I think knights is an example, even some gray areas cannot be dragged, even though they look visually identical to other gray areas that can be.
I agree with all your concerns about inconsistencies. However there is not much that can be done about it at the oxygen style level. They are the consequences of inconsistent handling of Qt (or X) events inside the game themselves. We have tried to fix all possible actual conflicts in a generic way at the style level, resorting to special blacklisting of misbehaving widgets when nothing else would work, and I believe we have achieved a rather good level of stability with that respect. Other issues have been fixed on a per-app level. (notably kpat, with the help, and agreement, of Parker Coates). My opinion, is that we can either: - go fix the remaining inconsistencies on a per-application (here, per-game) basis - live with the current situation, possibly making it easier for users to disable the window dragging feature if he/she really finds it annoying - disable the feature fully, which I would find a pity (and would disagree with in the first place) notably because of the positive feedback we received about it for all other non-game applications. (I personally use the feature all the time without even noticing it, and feel quite incapacitated when switching to another OS for which it is not available). What would be, in your opinion, the best course of actions, among the above ?
I think someone should fix the problem in the remaining games. However, I also think it needs to be much easier to turn off this feature. It is impossible that anyone who hasn't already been told about oxygen-settings could figure out how to turn this off. I don't think turning it off by default is a good option.
some heads up: about comment #6 https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/0df99d8b8562aed8d46b3fff86dec5b45e38fed3 "moved "windows' drag mode" option back to basic settings" about original report: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/38295c4e12a794fa248280d5f8d554db1b381a84 "Disable window dragging from QGraphicsView (at least temporarily), because they 'usually' do not fully qualify as "empty areas"" The second actually 'fixes' many of the games above (kpat, kreversi, etc.) I'm still going through the full list.
yes. That was the original suggestion. And it should be a "wish" not a bug, unless an actual bug is pointed to.
oops, ignore comment #8, wrong bug number.
So going through the games above: Following are fixed with commit #7: kpatience, kblocks, kfourinline, kspaceduel, kiriki, kreversi, ksquares, kmines, knetwalk, kblackbox, kigo, katomic, klickety, kbounce, lskat, konquest <- almost, except for the front page. Bomber is not fixed. This is because it triggers its bombs on "mouse-release", and do not catch the "mouse-press". Not an application bug, but it justs makes it harder to fix (on oxygen's style). I can either: - explicitly blacklist kgamecanvaswidget in oxygen (might fix a couple more games) - or explicitly force-disable window dragging for this widget in kgamecanvaswidget source code (by adding the relevant property) - or eplicitly make "bomberwidget" catch (and not propagate to parent) mouse press events, even if it effectively does nothing with it. Whatever you prefer. As for other games (I count 8 of them) I did not test, cause they are not (yet) installed on my system. Looking at the
Blinken: not fixed either. Reason is that everything is done on QMainWindow (in fact KMainWindow) directly. I'll investigate a way to fix in oxygen directly, by requiring that mainwindows are qualified as empty areas if the "normal" background is painted on them. Will keep you posted.
Great! If the games with the major problems are fixed, maybe it would be better to wait and fix things permanently in tagaro, since the current KDE game system is deprecated anyway.
closing this one, based on comment#12 (and "main" games being fixed). Please reopen (or better: open a new one), when new kde game system is out and new issues show up. Thanks for reporting and helping, Hugo