As a games studio, we’re currently looking at using the Shotgun Panel in Maya to not force artists to get out of their flowstate or even just DCC, in order to merely see their tasks/update them.
However, since we are a game studio in Japan, pretty much all the tasks have japanese characters in one place or another. While names of our assets are in normal abc’s, the description, or the tasks on it, are in japanese.
Now… the Shotgun Panel seems to handle that just fine when displaying tasks, but not when something is entered into the search field. With an asset called Test, i can write “test” into the search field, and see an empty popup box with a slider, nothing visible. However, this emptiness is just an illusion, as the ‘hit widgets’ actually exist, and i can click in the seemingly empty space, and its apparent i clicked a widget, and it links me correctly to one of the tasks on the Test asset.
So, it seems only the search field popup widget, or rather the per-hit widgets and their formatting, doesnt deal well with unicode.
We’ve had the same problem with how we wanted to expose a few other things in our in-house tools when using the shotgun API, and were able to work the u"" magic there, so im not above taking action into my own hands, and messing around with core scripts of the panel, if there is no other solution.
So now, the question is - is there a solution that would allow me to fix the unicode characters problem (or can it be something else?) and if not, where would i find the python file that houses the creation of the search popup’s widgets, or rather a file that grabs data from shotgun, which is then i assume passed into said widget?
Let me share what I found out yesterday after my look into it.
It is definitely the case of shotgun not decoding the characters in several places.
Most likely, only two changes are needed for the search popup to not error out.
add a try/except clause, modifying the ‘matching’ var by adding .decode(‘utf-8’) in the
As for fix, this seems to have taken care of the problem, but it may not be perfect. There’s other places that might need this, and I’m not familiar so much with the toolkit yet myself.
Thanks for pointing out that bug, and thanks for sharing your workaround! We were able to reproduce the issue here, and so I just wanted to let you know that we’ve put in an internal ticket to track the bug. We’ll let you know when we get a fix out.
Thank you for the action you’ve taken to put it in the backlog!
On the subject of japanese/chinese characters, one thing that comes up as well regarding catering to this side of the world, is that one kanji may be worth one or sometimes more than one word in english, but the current search field requires at least 3 characters.
If i have for example 4 different horses and dont remember their internal abc-ified IDs, and want to write a “馬” which is japanese for “horse”, the search complains that’s not enough, haha. But as a user, that’s literally all i have to work with, so i’d need it to display the hits even with just one character, if the character is a kanji set. This may be trickier, but would be immensely appreciated.
Since these two issues are semi-related and seem to be fixable in the same files, I’m wondering if you could throw that in there as well, as a separate but related ticket?
That’s a really interesting point you bring up! I can see how that can be frustrating, and we English-speakers wouldn’t have thought of that issue, so thanks for raising it.
I’ve shared our conversation with the Product team; hopefully there will be some movement on both issues.
Hi @Pete – I just wanted to let you know that we released a new version of tk-framework-qtwidgets that fixes the bug around unicode characters in the global search widget.