While wxPython  is really nice in the way it integrates in the UI, it's downside is the use of OS generic controls which do not allow enough customization to make them really integrate in Poser's UI.

For example if you're using a wx.ListBox, you can set foreground (font) and background color but you cannot change the colors for selected elements, they'll display with the system colors. And even worse, on a Mac they don't change at all.
Same problem with a Textbox: colors change on Windows and don't change on the Mac.
Even worse (both Windows and Mac): wx.RadioButtons only change the background color, foreground does not work...

So, did anyone of you a) find a workaround for that (other than adjusting your system settings to match Poser's UI colors ;-)) or b) code some replacement controls?

You should ask SM. The entire UI is wx, so clearly you are attempting to integrate wx with wx and not aware of how Poser does it. Neither am I, or I'd say.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Yes, guess I have to ask SM, but that way I can't finish it today :-)

All the Poser UI elements appear to be based on custom classes (apart from the splitters) wxWidgetCanvas and wxPoserChildFrame.
These presumably are a container for the PSD resource based controls and the Poser style window frame, and we have no access to these (otherwise is would be easy to match the internal UI style), so to match UI styleyou'd need to subclass standard controls and override the appropriate drawing functons.

Well, SM support confirms that it's currently not possible.

As CheckBox and RadioButton are my main concern, I just accompany empty labeled ones with  a StaticText in my own CheckBox and RadioButton classes. That way the color can be changed...

Yeah, it involves a lot of workarounds and extra pushing to try and get things to look integrated.  It's funny that something that is supposed to be a GUI cannot allow you to fully and more or less easily design the UI the way you have a vision for it.

Its certainly not SM's fault.

Tkinter is just as bad when you are going cross-platform.

But back to wxpython, I've found that buttons and panes you can get at pretty well.  You can even throw a graphic tile on the pane to get a Poser "sandstone" look, however it feels like such a hack/workaround to get it in there.  But you're right, listboxes and the other elements wind up looking generic and funky on the mac.

Another thing that blows me away is information is often kind of spotty so you either have to hunt for ages or blow up Poser's UI a few times to figure things out.  At least that's my experience.  LOL

.

I wonder why it's always the Mac versions that need special treatment. Be it Java, Mono, WxPython. It works fine on Windows and Linux, but you have to do all kind of weird stuff to get the Mac things working (if you or your testers don't lose interest before it's done).

I have my own check boxes and radio buttons (using the regular ones+labels) to get those suckers colored properly... But coding everything again is kind of ... counterproductive...
I wonder if Poser faces the same problem with the numeric inputs for the dials... Those also pop up another input after clicking... maybe the regular numeric input is resistant to background color changes, too, like wx.lib.masked.numctrl... ;-)

That's even true of tkinter and poser's dialog resources.  I had scripts failing on Mac with dialog resource cannot be found (or somesuch) and I had to define where the poser UI elements are. o.o

Normally, we can do this:

dlg = poser.Dialog(file="./Runtime/ui/simpleDlgOk.xml", message=msg, width=wd, height=ht)

but I found that instead I had to do this (or similar) or Mac OSX 10 was having a baby:

poserPath = os.path.split(poser.AppLocation())[0]
okPath = os.path.join(poserPath, 'Runtime', 'ui', 'simpleDlgOk.xml')
dlg = poser.Dialog(file=okPath, message=msg, width=wd, height=ht)

.

That's just due to the difference of what Windows and MacOS consider the current directory to be.
Using an absolute path is always going to be safer cross-platform, unless you're really sure where a relative path is going to be based on.

I guess I just made the wrong assumption that file="./Runtime/ui/simpleDlgOk.xml" would be cross-platform since the "example" scripts also use this.  Maybe Mac has completely different versions of the scripts that come with Poser?  Hard to make everyone happy if you're getting the wrong information to start with :D

.

Starting a path with "." makes it relative to the current directory.

For Windows this will be the directory in which the EXE being launched from (by a double click) is, or the directory specified by the shortcut as "Start in:"
Windows also keeps a current directory for each drive which can make for a gotcha.
I don't know the specifics of MacOS's behaviour, but I'd expect the current directory to be the user's "home directory".

Command prompts on both behave similarly, in that the current directory is where you may have changed it to (not sure how this affects Windows shortcuts, but would any EXEs started).