pressing print screen deactivates gnomine, making it pause, preventing me from taking a screenshot

Bug #27956 reported by Vincent Povirk
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GNOME Games
Fix Released
Low
gnome-games (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

That was pretty much the whole description in the summary. To reproduce: start a
game of minesweeper (actually click on a square) in gnome with metacity, and try
to take a screenshot of it by pressing print screen or alt+print screen. In the
screenshot, gnomine will say "Press to Resume" and not show the minefield
because it was deactivated before the screenshot was taken.

Note that running a shell command like "sleep 5; gnome-screenshot --window"
works fine. I can't imagine why metacity starting gnome-screenshot would fail if
this works.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. That's a feature of the gnome-mine game so you don't switch
to somewhere else to investigate on the grid while the clock is not running

Revision history for this message
Sebastien Bacher (seb128) wrote :

closing as NOTABUG, that's a feature

Revision history for this message
Vincent Povirk (madewokherd) wrote :

But why does gnome-screenshot deactivate the window when it's called by metacity
(but not when it's called using another method)?

Revision history for this message
Daniel Holbach (dholbach) wrote :

The normal use-case is that a user plays gnomine, changes to another window and
the game gets paused. Your use case is unfortunate, but rare, I daresay.

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

Not so rare, I think... I use it, too, many people would. And don't say that it's a feature preventing people from cheating - as You see, if one wants to cheat, he'll do it. We shouldn't restrict people because of our feeling what is right - it's not the Linux way. :)

Isn't it an issue of gnome-screensaver? I'd expect this tool to prevent applications from discovering it working, otherwise app can hide what it wants.

Changed in gnome-games:
assignee: dholbach → nobody
Revision history for this message
Ic3-T (mazilu59) wrote :

Same problem here in 8.10 too... Maybe gnome-screenshot should work as a daemon (or the code should be inserted in a system process like nautilus let's say) so pressing PrintScreen does not make the active window to lose focus... and then, the GUI could start... i think it's a bug, because it doesn't do what he has to... there are many more application who behave like this too, so don't blame Mines.

Changed in gnome-games (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Victor Zamanian (victorz) wrote :

This bug is definitely not invalid. It may be a feature, but it's a bully feature.

"Thanks for your bug. That's a feature of the gnome-mine game so you don't switch
to somewhere else to investigate on the grid while the clock is not running"

Gnomines doesn't want me to cheat? How about gnomines letting me decide whether I want to "cheat" or not. Maybe I don't want to play timed! Maybe I want to print the board and show someone but unable to bring the computer!

Anyways, those are just some of the problems with this. I think it's a brilliant feature, but it lacks a _SETTING_. That's the problem. My use case is that I want to take a screen shot of every case where it is impossible to determine which of the two or more remaining squares has a bomb and which doesn't. (About every other game I play has a case like that.)

This might not be a bug per se but the "feature" needs a setting. Just as the timing of the game does. Typical gnome to remove settings from users. :-| I apologize if I've come off as negative or disrespectful!

Changed in gnome-games (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Victor Zamanian (victorz) wrote :

Wow.

Revision history for this message
Victor Zamanian (victorz) wrote :

An even bigger "wow" considering this week's bug target is GNOME GAMES. :P Sebastien, what's up, man?

Revision history for this message
Sebastien Bacher (seb128) wrote :

wow what? you reopen a bug closed for 1.5 year without comment so I closed it again as we do usually in such cases. I received your comment after closing the bug, you should write your comment directly when changing the status next time to avoid that. In any case the Ubuntu team has limited manpower and no interested in spending those adding options to small games, there are thousand of really annoying desktop bugs opened and we focus on trying to fix some of those which crash in softwares users rely on to use their computer. If you want to argue with upstream feel free but the Ubuntu team is not going to work on this one so letting the bug closed there

Revision history for this message
Victor Zamanian (victorz) wrote :

Well, Mr. Bacher, now that you /do/ see my comment, why are you still keeping this bug closed when this weekend is /dedicated/ to closing bugs in "small games". http://fridge.ubuntu.com/node/2060

If there is no interest in fixing bugs in small games, then why dedicate an entire week to fixing bugs in small games?

Revision history for this message
Sebastien Bacher (seb128) wrote :

not sure if you really read the previous comment on the url you mention, the bug day is only one day and is a day to triage issues not to work on the software, ie it's about cleaning the bug tracker so open ticket are useful to do work. why the bug has been closed is explained before, Ubuntu doesn't write that software and has no interest to add options to games

Revision history for this message
Victor Zamanian (victorz) wrote :

It's a bit difficult to read run-on sentences, but I still don't think you directly addressed the URL I mentioned. Especially since I didn't mention the URL until after you made /your/ comment. (Naturally I'm confused.)

Well, fine. That's disappointing, but acceptable. Maybe that should be stated somewhere officially, so that us bug filers don't waste time filing bugs on silly little games that no-one cares about and which won't be fixed. Maybe there should in fact be an extensive documentation stating what packages are worth filing bugs on.

That at least sounds fair, does it not? You sound like you speak for all of the Ubuntu development team (which I actually don't doubt that you do; don't get me wrong), so maybe you can give your opinion on that. What do you think? Maybe we can get launchpad developers to code support for "un-bug-file-able" packages? That would probably reduce the amount of worthless bug reports considerably.

The bug is nevertheless not invalid. It's a Won't-Fix if anything.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Ok, fine, I don't care enough to argue there for hours, reopen the bug as a wishlist if you want, we have hundred of bugs about computers not starting or video drivers not working or firefox not rendering webpages and we work on those rather than on adding options to game.

The game is not written by Ubuntu but by GNOME, see https://wiki.ubuntu.com/Bugs/Upstream/GNOME if you want to submit the bug to the software writters it's on http://bugzilla.gnome.org

Still note that upstream coded the game this way and you should argue with them if you disagree, it seems such a silly detail that's it's not worth arguing over for hours, I will stop commenting there, such bugs are fine to be filed in launchpad they will just stay there for years without changes and clutter the buglists, reopening bugs closed for years is not so fine though since it makes emails being sent to whoever opened the bug by then and might not be interested by you arguing over an year old change. The bug has been marked invalid but it's not a bug, it's an upstream choice, you reopened the bug now with a wishlist request to add the choice as a setting which is not what the bug was about and another reason why should open new bugs rather reopen closed ones which seems similar

Revision history for this message
Victor Zamanian (victorz) wrote :

No, no, Sebastien... -_- You're not getting me. I accepted that Ubuntu doesn't care about certain packages. I'm not arguing anymore. I'm not reopening the bug. I'm simply stating that it's not invalid. I shall repeat myself. It-is-not-invalid. It's a won't-fix.

It's a silly little detail for you. Ubuntu works flawlessly for me, I don't have hardware problems. I have software problems. So these things are 'important' to me. For others like me, it might be desirable to fix these on our own with patches, in which case the bug should have a proper status, and not "invalid".

This IS a bug, stop saying it's not a bug and it's an upstream choice. It's a bug for me, because it's counter to how I want it to work. It's not giving me the results I want, etc. That's how bug tickets work. Invalid is something that's not true. But this, this is actually happening. $ sleep 5; gnome-screenshot --window works fine! The problem is most likely that the GUI screenshot window when pressing PRINT SCREEN gains focus before it takes the screenshot and appears. It might be a bug in another package, it might be a bug you don't care about, but mark it as won't-fix and don't say it's invalid.

Sorry to be wasting so many hours of your time, but I thank you for the time you've given this thus far.

PS.
If people don't like getting e-mails from bugs past that they don't care about anymore, they can unsubscribe, can they not?

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

It's actually very easy to cheat - it's enough to run a simple script sleeping for a few seconds and then making a screenshot - the game doesn't detect this way of making screenshots.

Revision history for this message
Vincent Povirk (madewokherd) wrote :

The pausing when losing focus isn't necessarily to prevent anyone from cheating. No one knows the rationale for it because no one has filed a bug upstream.

Revision history for this message
Vincent Povirk (madewokherd) wrote :

As much as I don't like to see reopened bugs with long arguments about them, I really feel that Sebastien has dropped the ball here.

As I understand it, part of launchpad's purpose for ubuntu is to be a central place for ubuntu users to file bugs they see in ubuntu, without worrying about whether the bug report really belongs in ubuntu or whether it should be reported to another project. In general, finding the appropriate project can require some investigation. In this case, it does not, but bug reports in general are valuable enough (even for a games package imo) that they should be worth forwarding, rather than expecting normal users to do it. I thought this was the policy.

It's fine to say that upstream doesn't care, but you should provide some evidence of that, such as a link to an upstream bug that has been marked invalid or wontfix. Near as I can determine, the gnomine developers don't know about this scenario because no one has filed a bug in the gnome bugzilla.

Unfortunately, it seems whining about this probably won't get that bug filed, so I will go do that.

Revision history for this message
Vincent Povirk (madewokherd) wrote :
Changed in gnome-games:
status: Unknown → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

I didn't drop any ball, we just encourage users to open new bugs rather than reopening closing ones, that to avoid spamming the original submitter which might not be interested to received emails years later, especially when the request is different, ie a change of behaviour against adding an option.
Thanks for sending the bug to GNOME anyway, let's see what they say, adding an option for that wouldn't make sense, it should be doing what is right by default. The upstream behaviour is to pause counter and lock the game when switching screen, it allows you to context switch without having the counter running and let you play fairly rather than using the pause to trick the score

Revision history for this message
Victor Zamanian (victorz) wrote :

...

As already stated, people who don't want to be spammed can unsubscribe, can they not?

Adding an option for that would certainly make sense indeed, because different people want to play games in different ways. Some like competitiveness, some don't. Other's like to play by the rules, some don't. Is that comprehensible to you, Sebastien? You couldn't possibly -- doing work for Ubuntu -- believe that all people share your opinion and perspective on all things. Give people the option to change it to what they want. If the default setting is sensible, most people won't touch it. The people that /do/, well... they will! And they /can/, with an option! "Doing what is right" is not always unanimously defined, sir. If I want to cheat (at MINES, mind you; these aren't my taxes you know...), I should be able to.

Props to you Vincent. What a trooper. Thank you for standing up for the little games "no-one cares about". lol :) It's actions like yours that help make software better --- in the details.

Revision history for this message
Sebastien Bacher (seb128) wrote :

> stated, people who don't want to be spammed can unsubscribe, can they not?

not sure the bug submitter can unsubscribe from the bug he,she opened no

Revision history for this message
Sebastien Bacher (seb128) wrote :

> Sebastien? You couldn't possibly -- doing work for Ubuntu -- believe that all people share your opinion and perspective on all things.

I don't believe that but I also don't believe that we should add one option for every users request, you could get a full control dialog with 65 option for each game, that's not the GNOME or Ubuntu vision, users want things to just be working

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

@Sebastien Bacher
> not sure the bug submitter can unsubscribe from the bug he,she opened
Yes, they can.

Revision history for this message
Victor Zamanian (victorz) wrote :

"users want things to just be working"

Right. Hence this bug report.

Changed in gnome-games:
importance: Unknown → Low
Changed in gnome-games:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.