We Keep Coding

Window moving behind other open windows when button pressed (Python with Tkinter)

Apologies if this is a completely easy fix and I've just missed it. I am learning Python and I am trying to develop a GUI alongside my backend code using Tkinter. This is completely foreign to me and I have recently come across the problem that when I press my buttons there is a very small chance that it will make my window move behind all other open programs.
I am not entirely sure what is causing this but my guess is it stems somehow from one of two functions I have; one meant to minimise the main root window and the second to reveal it. However, these functions are not called in any place in my program that I would not expect them and the windows being minimised are not the root window (which my two functions act on).
I have both functions added below (hopefully, I am pretty new to SO) but if any additional code is needed I will supply it. I have quite a bit of code and everything else functions perfectly so I didn't want to post all my code is all.
There is no particular combination of button presses or buttons in particular which cause it, it appears to be any of them seemingly at random. It sends whatever window I have up to the taskbar.
def revealMenu():
root.update()
root.deiconify()
def hideMenu():
root.withdraw()

Is it possible to see if the file is being dragged over the window in Kivy, Python?

What I want to achieve:
I want to detect the situation when the user is dragging a file over the Kivy app window.
What I already know:
I know how to detect hovering mouse coursor over widgets (with on_mouse_pos), I also know how to detect if a file is dropped onto the window (with on_file_drop).
So, is it possible to see whether the cursor is hovering over the window and "holding" a file? Because then I want to display some prompt (eg. 'Drop HERE'). I hope you get the idea :)

I'm not really sure, because there's this thing with SDL2 (and probably even with old pygame) when the Window just pauses (try some animation or something) when you e.g. drag it with the window decoration (the thing where title and _ O X are). That is the behavior if you do something with the Window directly.
Although, the Window looks like it behaves normally (doesn't pause itself), when you drag file on top of it (I tried with examples/animation/animate.py), to do such thing you'd need to do either the hovering behavior + handling the collisions or bind to mouse_pos.
However, when binding to mouse_pos, it seems like the Window still isn't capable of handling the input from outside and at the same time get mouse properties correctly (I think it's similar to the behavior when you click & drag outside of the Window and Button remains pressed, but this is kind of inversed).
edited animate.py:
class TestApp(App):
def on_mouse_pos(self, win, args):
print args
...
def build(self):
...
from kivy.core.window import Window
Window.bind(mouse_pos=self.on_mouse_pos)
return button
Therefore if you can't get even mouse position when a mouse button is being held, I don't think such an action is possible. You can however make the areas where you want to drop the file already different (e.g. change background) when you'll expect a user to drop the file - a very dirty workaround from UI side for such a problem.
Side note: Kivy should be able to get most (if not all) SDL2 window events via Cython, therefore if you find such event in SDL2 that would make fetching mouse position possible, such action could be performed, feel free to make a feature request in kivy/kivy or make a pull request.

hide pygame window on OSX

Pressing command-H in OSX immediately hides the active window. How do I achieve the same effect, programmatically, from Python? Specifically, I'd like to find a particular window that my application creates and then be able to show & hide it programmatically.
I already know how to do this with pywin32 but I'm afraid my expertise there doesn't quite cover OSX as well.
If it helps, the window in question is one created by pygame. I know that pygame has pygame.display.iconify() but that doesn't satisfy my requirements - the window doesn't disappear immediately, but rather the disappearance is animated, and there's no corresponding "uniconify" function that I can find.

Well, this ended up working. When I want to hide the window, I do pygame.display.quit() and make my code properly handle not having a display. When I want to show it, I do pygame.display.set_mode(...) with the former resolution.
The net effect is that of hiding & showing the window. Unfortunately the window gets created in a different spot than where it started, and although apparently you can tell SDL to create the window in a particular spot, I haven't been able to find a way to get the window's location...

Is there anything I need aware of using Tkinter and pygame together?

I am using pygame to write a program and I need some GUI configuration text field and button for control. I've already made the button using pygame, but I just can write a text field out of pygame. Maybe I need to use tkinter together with pygame.
I think if there is no way to made to pygame part and tkinter part together in 1 window, then I could put them into 2 separate windows.
I hope the tkinter part can update the global variable in my pygame part, would there if any problem? I might create a child process of tkinter from the pygame part so that the tkinter part can probably "see" the global variable in pygame part and modify them.
Can I do this? Are there any pitfalls?

Both Tkinter and Pygame have their own event loops, so doing what you want is far from simple. The problem is that Pygame wants to control both the screen and the events the user feeds into the computer. This doesn't work well with GUI libraries, which also want to be "in control".
I would suggest sticking with Pygame, it has some nice GUI toolkits that will help you create buttons and other controls. Go over this page - it should clear things out. You may also find this discussion useful.
Apart from the practical aspects, a GUI created with Pygame is also IMHO more suitable for a game than something done with Tkinter, since games usually have original, thematical user interfaces and not the bland "text box + button" windows we're used to in other applications.
Take a look at some of the sample games on the Pygame wiki, many have GUIs and you can borrow ideas and code from them.

from tkinter import *
import pygame
import random
import os
global playing
playing=False
def playpause():
global playing
if playing==True:
playing=False
else:
playing=True
root = Tk()
embed = Frame(root, width=640, height=480)
embed.grid(row=0,column=2)
playpausebutton=Button(root, command=playpause, text="Play/Pause")
playpausebutton.grid(row=1,column=2)
root.update()
os.environ['SDL_WINDOWID'] = str(embed.winfo_id())
os.environ['SDL_VIDEODRIVER'] = 'windib'
pygame.display.init()
screen = pygame.display.set_mode((640,480))
pygame.display.flip()
while True:
#your code here
if playing:
screen.fill((random.randint(0,255),random.randint(0,255),random.randint(0,255)))
pygame.display.flip()
root.update()
This works just great, I have used this method successfully in multiple cases.

I have also found pgu is awful. However, what you say about the tkinter event loop taking control is wrong. You just call root.update instead of mainloop, and this can go inside of a while loop to replace the mainloop. Answering your main question however, there is something you should be aware of. It seems that whenever I run the two programs alongside each other, this traceback occurs:
TclError: expected boolean value but got "-1"
Fatal Python error: (pygame parachute) Segmentation Fault
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Because of this I would avoid the combination, although I suspect this particular issue may pertain to my use of threads.

Can you auto hide frames/dialogs using wxPython?

I would like to create an application that has 3-4 frames (or windows) where each frame is attached/positioned to a side of the screen (like a task bar). When a frame is inactive I would like it to auto hide (just like the Windows task bar does; or the dock in OSX). When I move my mouse pointer to the position on the edge of the screen where the frame is hidden, I would like it to come back into focus.
The application is written in Python (using wxPython for the basic GUI aspects). Does anyone know how to do this in Python? I'm guessing it's probably OS dependent? If so, I'd like to focus on Windows first.
I don't do GUI programming very often so my apologies if this makes no sense at all.

As far as I know, there's nothing built in for this.
When the window is hidden, do you want it completely invisible or can a border of a few pixels be showing? That would be an easy way to get a mouse hover event. Otherwise you might have to use something like pyHook to get system-wide mouse events to know when to expand your window.
The events EVT_ENTER_WINDOW and EVT_LEAVE_WINDOW might also be useful here to know when the user has entered/left the window so you can expand/collapse it.
Expanding/collapsing can just be done by showing/hiding windows or resizing them. Standard window functions, nothing fancy.
By the way, you might want to use wx.ClientDisplayRect to figure out where to position your window. That will give you a rectangle of the desktop that does NOT include the task bar or any other toolbars the user has, assuming you want to avoid overlapping with those things.

Personally, I would combine the EVT_ENTER_WINDOW and EVT_LEAVE_WINDOW that FogleBird mentioned with a wx.Timer. Then whenever it the frame or dialog is inactive for x seconds, you would just call its Hide() method.

I think you could easily just make a window that is the same size as the desktop then do some while looping for an inactivity variable based on mouse position, then thread off a timer for loop for the 4 inactivity variables. I'd personally design it so that when they reach 0 from 15, they change size and position to become tabular and create a button on them to reactivate. lots of technical work on this one, but easily done if you figure it out