In my never ending quest to curate a specific and consistent look across every inch of my UI, I have come to the topic of creating the usual 3 button layout similar to what is at the top right of every windows application.
The X is easy, the windowed/fullscreen toggle is also pretty straight forwards, but the minimize is tripping me up.
Is there currently a pythonic way to minimize the perform window even if it’s set to full screen with borders off?
I am able to minimize the window via windows 10, but it’s very annoying. I have to hit the windows key, hover over the application icon, then when the window preview shows up, I can right click on it and click minimize - so I know windows lets me do this to a full screen window.
The question is, how do I do this from with in Touch?
Totally down with even a hack approach, if anyone knows of one - since this is such a 1 way isolated function.
ctypes is included with python by default, so no need to import anything which is super nice.
If you want to minimize the touch window from another process (ie another Touch thread or python script) you’ll need to do a search for the window via title name, instead. So something like this:
Omg @Ivan that would be spectacular. After attempting to build an internal version of that windows top bar, it occurred to me how much functionality we could gain by having a python function that simply sets/gets the windows Left/Right/Top/Bottom edge or something like that. That paired with the monitor dat we already have, would make it pretty easy to maximize/window/minimize the perform window to any monitor, subset of a monitor, or span across multiple monitors, etc.
The mouse chop already provides the monitor it’s in, so this makes it pretty elegant for a maximize button to intelligently maximize to the correct monitor.
One thing we’re missing still is the ability to get exact Left/Right/Top/Bottom coords of where the perform window is in realtime. I made another post about that here though:
Right now I’m working on a python lib expanding on this ctypes stuff, that does this. I’m using an execute DAT to retrieve the PID of the Touch process ( os.getpid() ) and find the windows handle ID that corresponds to this main touch window, and storing this in a dat somewhere.
Then with that info persistent through the whole life of a touch process, I’m able to call these wrapper functions to place the window where ever I want, offset it, etc.
I’ll post it up if I can get it to a reasonably packaged up state soon. Caveat is like you said windows only though.
Riffing off what you’re saying here @lucasm - a project member that pointed to the pid would also be a helpful addition. I’ve similarly created work around solutions for those bits before, and if it was handled by Touch that would be really swell.
Ya for sure - makes perfect sense for the project class. having the window handle ID (I keep seeing it referenced as hWnd ) would be great too, but I’m not sure if that’s a worth while thing to have implemented unless it could be cross platform compatible.