Use "named id" instead of generic "!{class}{n}" #212
Replies: 2 comments
-
Hello @BloodyRain2k , I took your idea from alejandroautalan/pygubu#287 and moved to BuilderObject class. It is working Ok for named widgets in the designer. I tried to enable this for all widgets (auto-generated names and named widgets). But it gives me a problem in the designer preview. I don't know yet what is generating this. For reference the error is this the following:
Full error:
Regards |
Beta Was this translation helpful? Give feedback.
-
I've done some work on my app that drives most of the changes I come up with and I've ran into the same "bad window path" error, but in an entirely different way: Not sure if that error might be related to the change with naming or if it's just coincidence. But another thing I noticed, was that the widget naming as you implemented it works only for child widgets. I'm currently looking into both things to see what it's about. |
Beta Was this translation helpful? Give feedback.
-
Maybe I'm overlooking something here, but it seems to me that the only use for giving a widget a custom id, is for asking the builder for that widget later.
When going through the children of widgets or such, it's still the same
!label2
or whatever the builder ends up assigning to it.For example, here I got an app that contains a label and a scrolled frame in the mainwindow (tk.Toplevel), both have names and both names are nowhere to be found:
The
nametowidget()
method would be probably easier to use, if I could tell it select.!results.!entry3.!file
and it would go from the mainwindow to "results" (the scrolled frame), then the 4th "entry" (simple frame) and the label "file" in that.Currently the actual query for that would be
.!tkscrolledframe.!frame3.!label
. And yeah that'd work the same, but looking at widgets and their tk paths would be a LOT more comprehensible if they'd use their assigned names.Taking the screenshot for the example made it even more obvious that I missed a couple layers that I wasn't aware of.
Maybe it'd be even possible to do both: keeping the old naming look up but also add custom names to the
children
dictionaries.I was already looking into trying to add that, but I'm still stuck trying to find the point where it's generating / updating a parent's
children
.Beta Was this translation helpful? Give feedback.
All reactions