Summary: | Drag to move windows causes problems in same games | ||
---|---|---|---|
Product: | [Plasma] Oxygen | Reporter: | Todd <toddrme2178> |
Component: | style | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | coates, hugo.pereira.da.costa |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Todd
2011-01-21 18:34:04 UTC
> 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 |