Is there any way to control where pygame creates the game screen? It seems to always create it in the same general area but not in a consistent location.
import os
os.environ['SDL_VIDEO_WINDOW_POS'] = str(position[0]) + "," + str(position[1])
as per http://pygame.org/wiki/FrequentlyAskedQuestions
You can also just center the screen with
import pygame, os
os.environ['SDL_VIDEO_CENTERED'] = '1'
Note that these should be done before you initialize pygame in the main loop. I do it right after I import os for example. And since they are not actually part of pygame, you can probably use it elsewhere, though things like gtk and wxpython provide their own mechanisms.
Positioning of windows is not handled by the client application. It's handled by the Window manager (metacity etc.).
The SDL library on which PyGame is based does have a few environment variables which can be used to give hints to the Window manager. These are hints which the WM may ignore but it's the best you can do.
The comments over here have an example.
Related
I am working with pygamezero using an editor called MU (this has the pgzero module built in). When the code is executed the top left of the game window spawns from the centre of the screen and, depending on the dimensions provided by the user for height and width and their screen resolution, portions of the window often appears "off screen". I have found a method - using pygame - that evokes full screen, but am wondering if there is a method to set starting x/y coords of the game screen, so that it is not full-screen, but the window spawn position can be controlled.
To control the window position in Pygame Zero (pgzrun) make use of os.environ['SDL_VIDEO_WINDOW_POS'] as shown below. It must happen before the import pgzrun call, otherwise it won't work.
FYI If you're using Thonny--a teaching & learning IDE--you need to disable Pygame Zero mode from the Run menu to control where the window appears. If you don't disable the mode, Thonny will override your choice by implicitly importing (& thus executing) pgzrun.
The following code snippet will place your window at the top-left corner of the screen. You can also make the window go fullscreen in a different way but that doesn't require os.environ.
x = 0
y = 0
import os
os.environ['SDL_VIDEO_WINDOW_POS'] = f'{x},{y}'
import pgzrun
pgzrun.go()
Note: This question has also been (pretty much) answered elsewhere. Because this question and answer specifically relate to Pygame Zero I'm adding this here so anyone looking specifically for a pygame zero solution can find it.
Is there any way to control where pygame creates the game screen? It seems to always create it in the same general area but not in a consistent location.
import os
os.environ['SDL_VIDEO_WINDOW_POS'] = str(position[0]) + "," + str(position[1])
as per http://pygame.org/wiki/FrequentlyAskedQuestions
You can also just center the screen with
import pygame, os
os.environ['SDL_VIDEO_CENTERED'] = '1'
Note that these should be done before you initialize pygame in the main loop. I do it right after I import os for example. And since they are not actually part of pygame, you can probably use it elsewhere, though things like gtk and wxpython provide their own mechanisms.
Positioning of windows is not handled by the client application. It's handled by the Window manager (metacity etc.).
The SDL library on which PyGame is based does have a few environment variables which can be used to give hints to the Window manager. These are hints which the WM may ignore but it's the best you can do.
The comments over here have an example.
I am trying to create an application for multiple screens however I so far cannot find a way to locate the secondary screens position (relative to the primary screen by x and y coordinates).
I prefer to use python or bash (via libraries/frameworks are fine). I also checked with xorg.conf and it doesn't reflect my current screen setup.
I am using Ubuntu 11.10 (default Gnome 2 I believe), using compiz as the window manager. So to repeat, my question is how to get the screen layout (coordinates relative to primary screen) of all the monitors preferably by python or bash.
Nevermind, I used Pyqt instead. Here is some code...
from PyQt4.QtGui import QApplication, QPixmap
desktop = QApplication.desktop()
screenRect = desktop.screenGeometry(1) #2nd monitor
print screenRect.x(), screenRect.y() #returns the x and y of that screen
Python binding solution
So, from here you can download the xrandr bindings for python: https://launchpad.net/python-xrandr
# Import the module
from xrandr import xrandr
# Get a screen object to work with
screen = xrandr.get_current_screen()
# Get the active output objects as a list
active_outputs = [o for o in screen.get_outputs() if o.is_active()]
This was as far as I got playing around a little. I hope it will get you started :-) I only have one screen connected right now...
Parsing data solution
The other solution, as I mentioned in my comment above is to parse the output of the command xrandr it looks like it should be pretty simple from just taking a glance at it...
using Ruby or Python, does someone know how to draw on the screen, covering up any other window? Kind of like, press a key, and the program will show current weather or stock quote on the screen (using the whole screen as the canvas), and then press the key again, and everything restores to the same as before? (like Mac OS X's dash board).
You could use the systems dashboard (desktop widgets, or whatever it's called) API. In order to do that you need bindings to it for Python or Ruby.
Alternatively you could use some generic gui toolkit or application framework and just create a frameless window with transparent background. Then you need to be sure that the chosen toolkit supports 'always-on-top' options on your desired platform(s).
If you are on windows you can directly draw to desktop dc(device context) using win32api
e.g. just for fun try this :)
>>> import win32ui
>>> import win32gui
>>> hdc = win32ui.CreateDCFromHandle( win32gui.GetDC( 0 ) )
>>> hdc.DrawText("Wow it works", (100, 100, 200, 200))
>>> hdc.LineTo(500,500)
but that won't be very useful ,as not erasable
best bet would be to use a transparent window or window with a cutout region (atleast on windows that is possible)
or even if you can't draw transparent on some system you can grab the current screen and display it as background of you window that would give a transparent effect
I would recommend PyGame.
What is the best way to use PyGame (SDL) within a PyGTK application?
I'm searching for a method that allows me to have a drawing area in the GTK window and at the same time being able to manage both GTK and SDL events.
I've never attempted it myself, but hearing plenty about other people who've tried, it's not a road you want to go down.
There is the alternative of putting the gui in pygame itself. There are plenty of gui toolkits built specifically for pygame that you could use. Most of them are rather unfinished, but there are 2 big, actively maintained ones: PGU and OcempGUI. The full list on the pygame site is here.
You may be interested in this message thread. Looks like they recommend against it.
PyGame works much better when it can manage its own window, or even better, use the whole screen. GTK has flexible enough widgets to allow creation of a drawing area.
This page may help, though, if you want to try it.
There's a simple solution that might work for you.
Write the PyGTK stuff and PyGame stuff as separate applications. Then from the PyGTK application call the PyGame application, using os.system to call the PyGame application. If you need to share data between the two then either use a database, pipes or IPC.
http://faq.pygtk.org/index.py?file=faq23.042.htp&req=show mentions it all:
You need to create a drawing area and set the environment variable SDL_WINDOWID after it's realized:
import os
import gobject
import gtk
import pygame
WINX = 400
WINY = 200
window = gtk.Window()
window.connect('delete-event', gtk.main_quit)
window.set_resizable(False)
area = gtk.DrawingArea()
area.set_app_paintable(True)
area.set_size_request(WINX, WINY)
window.add(area)
area.realize()
# Force SDL to write on our drawing area
os.putenv('SDL_WINDOWID', str(area.window.xid))
# We need to flush the XLib event loop otherwise we can't
# access the XWindow which set_mode() requires
gtk.gdk.flush()
pygame.init()
pygame.display.set_mode((WINX, WINY), 0, 0)
screen = pygame.display.get_surface()
image_surface = pygame.image.load('foo.png')
screen.blit(image_surface, (0, 0))
gobject.idle_add(pygame.display.update)
window.show_all()
while gtk.event_pending():
# pygame/SDL event processing goes here
gtk.main_iteration(False)
I tried doing this myself a while ago, and I never got it to work perfectly. Actually I never got it to work at all under Windows, as it kept crashing the entire OS and I ran out of patience. I continued to use it though as it was only important it ran on Linux, and was only a small project. I'd strongly recommend you investigate alternatives. It always felt like a nasty hack, and made me feel dirty.
The Sugar project has several Activities built with PyGTK and PyGame.
They wrote a support lib to achieve this, called Sugargame. You should be able to modify it for regular PyGTK apps instead of Sugar.
Here's a chapter in Sugar's development book about how to use it.
The lib allows for communicating events between GTK and PyGame.
Enjoy!