DirectGUI text shadow information is missing from the documentation

The keyword list here is incomplete, and there does not seem to be a more complete list anywhere else:
https://docs.panda3d.org/1.10/python/programming/gui/directgui/index#directgui

I simply guessed that “text_shadow” and “text_shadowOffset” can be used, but “text_shadowOffset” doesn’t seem to be accessible after the DirectFrame instancing. If you do this later in the code
DirectFrame["text_shadowOffset"] you are told that keyword does not exist.
"OnscreenText.configure: invalid option: shadowOffset"

The OnScreenText manual page also does not show how to do it, by instead showing how to set those values by methods, not a dictionary key: Rendering Text — Panda3D Manual

I thought maybe I could access the OnScreenText object of the DirectFrame object, but I don’t see a mention of how/if that can be done either.

I would recommend that you use the TexNode class, this is what DirectGUI uses under the hood

What do you mean?
You mean you can access a TextNode object which is inside the DirectFrame object? How can I do that?

Maybe the manual should be updated? I was just following the info available in the manual and API ref and it worked fine for all other text attributes.

I meant use it singly, however you can get it from OnScreenText with the function .node()

The documentation there notes that DirectGUI widgets will take “[a]ny keyword parameter appropriate to OnscreenText”. While the manual entry for OnscreenText doesn’t then provide a more-complete list, the API page for the class does, I do believe:
https://docs.panda3d.org/1.10/python/reference/direct.gui.OnscreenText

This is a point on which DirectGUI’s approach to things is perhaps a little non-obvious. In short, DirectGUI widgets keep an internal set of named “components”, numbered by state I think, which can be accessed via the “component” method. A DirectFrame’s OnscreenText object is such a “component”, and has the base-name “text”.

For a basic DirectFrame, having only one state, the relevant component thus has the full name “text0”. (Multi-state widgets, like DirectButtons, may have additional components named “text1”, “text2”, etc.)

So, you should be able to access the OnscreenText object of a DirectFrame as follows:
onscreenTextObj = myDirectFrame.component("text0")

In this case, it seems like OnScreenText has a bug/issue. It only allows to set the shadowOffset during instancing, you don’t have it exposed as a parameter, and I can only guess is it was forgotten.

Thanks for the workaround.

No, that may just mean that it’s one of the various parameters that DirectGUI doesn’t support changing after construction, I’m afraid.

That is, it’s less a “bug” than a “limitation”. Some of which can indeed be a bit of a nuisance at times, I’m afraid!

It’s my pleasure. :slight_smile:

Tomato-tomato, it should still really be patched.

I am developing a program which has dark and white themes, things like this need to be adjustable after constuction. I don’t think my use case is niche so I imagine not exposing enough parameters at the OnScreenText level is going to be annoying to more people.
Sure, there’s a workaround as you explained, but not even that seems to be clearly mentioned anywhere in the manual.

From what I know of DirectGUI, that may be more simply said than done; some of its issues stem from its design, I think.

That said, as you say, your use-case is unlikely to be unique. In which case it might be worth making an issue for the matter over on GitHub. (Or better yet, a pull request.)

(I know that I have one or two issues and/or pull-requests (I forget) open for similar matters, as I recall.)

That is fair: DirectGUI can be quite obscure at times, I do fear.

There has been at least one thread discussing the replacement of DirectGUI, but thus far there has been no decision to do so that I’m aware.

Just my two cents on this, if it matters:

I’ve used DirectGUI for relatively demanding tasks, thousands of clickable buttons with a unqiue image onn each, all attached to a DirectScrolledFrame, I didn’t notice performance issues.
So not sure if it’s so bad to warrant a replacement.

1 Like

Oh, it works well. But it really can be clunky to use at times–as you’ve found out.