mirror of https://github.com/bsnes-emu/bsnes.git
7dda70baa4
byuu says: phoenix/Windows and phoenix/Qt are mostly fully operational now. All platforms support dynamic layout resizing. I tried WM_GETMINMAXINFO (thanks, OV2), but it was acting kind of choppy on resize, and it would get confused and go crazy if you snapped one direction to the minimum height but not another, so for now I'm leaving it off. phoenix/GTK+ will be missing some functionality in regards to window geometry. The other two have a more coherent strategy now: geometry() is the client area, and setGeometry moves the client area to where you ask for. This makes truly centering your client area trivial. frameGeometry() includes the borders, menu and status. There is no setFrameGeometry(), not sure if I really even want that, but it could be useful so who knows. All targets also support non-resizable windows. X11 is of course horrendously poor with frame sizes, Qt and GTK+ don't even pretend to simulate them, so they say the frame is 0x0 pixels in size until your widget is fully realized and visible to the end user. So for now, to get window positioning right, I have to wait until the window appears and then reposition the window again, causing a slight jump. My plan is to build some persistent caching support directly into phoenix. From here, I can just have the window snap the very first time you run your very first phoenix app. I'll then determine the frame size information, and use that to create future windows. Once they spawn, I'll recheck and update the frame size info in case it has changed (eg user changed themes.) Saving settings into .config/phoenix will allow me to avoid having to snap the window every time on first startup. If the config file is missing or unwritable, too bad, happens every time then. I'm thinking about renaming onResize to onSize, and getting rid of Window::create(). Rather make it spawn like every other control in its constructor. |
||
|---|---|---|
| bsnes | ||
| pixelshaders | ||
| snesfilter | ||
| snespurify | ||