Forum Archive

(Context for this post, is loading a pyui file into a class, hence creating a custom class (ui.View) with the pyui becoming the root of the class. Example gist, https://gist.github.com/c24156294c220668270d)
It was @JonB that got this working with bindings etc... @omz, I hope you can include this functionality into the ui package when you have time.

@omz, I think it would be great if for every ui elem in a pyui file (well in the ui designer ) had a switch to say that item's name would be added to a custom class as an attribute. Basically to provide a flattened out mapping. You can do it by hand, but it's time consuming And messy. I can see I can do some neat tricks with the custom attributes, like calling methods on self In the dict def of the custom attr. It's very nice But still a lot of hard coding. But that feature is still very cool anyway. But this seems like it should be native to me. No need for tricks etc.
In the designer, you really want to nest your ui elements Into custom views (deeply). But when it comes to the coding side, you want more of a flat representation of the ui elements. Maybe a attr is to much. Could possibly be a single attr with a dependency dict, containing ui.names with object instances or more....

Another great feature, would be if in the ui designer you could do a link to another object. Graphically or text entry (the ui object name). Then you would add another std attr to each ui elem obj like obj_ref or whatever, that would be populated with the instance var of the object referred to. The idea being that you could use that object's geometry as a parent when it comes to resizing. Hmmm, well that probably will not work itself. But if there was a editable index number for each item, by default just increment, but also editable. But if you relied on ordered redrawing in Layout, you could for example get a list of the items that need to be resized in the layout method, in order (I.e by index ) meaning if you have sizing dependencies you could calculate and size them in order. Maybe my implementation suggestion is infantile, but the idea is there. A more complete suggestion I think would be a flex ability to another ui object. Possibly even easier to implement, I am not sure. But I was trying to contain myself. :)
Again, I know there are ways to work around these issues, but I think more code that's part of the std api the better.

While not what you are after, did_load is a good place to handle this sort of thing, since it gets called after the view is fully populated when creating from a pyui. Here you can add all of your flattened variables in one spot. While this does take a few extra lines of code, it has the added benefit that autocomplete will now know about your ui components, plus it will be clearer where things are coming from( akin to from package import a,b,c instead of from package import *)

@JonB , yes you are right. If doing it by hand, then that's the place to do it. I often forget about that callback.
But i have a real love hate thing with ui module / designer.
It's so fantastic, but it always seems something is missing. The frustrating part is, I never really know what it is.
With your help and others you can do so very tricky things with ui now. I am not sure if you have tried it or not, but when you load a pyui into a class as the root, then in the custom attributes, you can call a instance method (just mean it's called automatically) . Only trick is to return a integer from the method, otherwise you get a warning messages. Also, having a custom attribute containing a dict so you can assign a lot of info without creating unwanted attrs. When you can just think Python, I am sure it's obvious that it should be possible. Takes me a while to click. But really, I love the ui so much, but it's still so frustrating when trying to create a complicated view. That's why I keep harping on it , it's because I love it. But I feel there just needs to be a few break throughs. Again, the frustrating thing is I don't know what they should be...I am working on a simple class now, just adds a label as a subview to a ui Element. The label just displays info such as height and width, x,y frame, bounds etc. each time you click the label, displays another information set. Just meant to help debug views. I know I go in circles, well crop circles, but it will dawn on me one day.

I can see another reason why I am so frustrated with the ui module. I just don't get mobile programming. I have just been reading the iOS Human Interface Guidelines. Something is starting to make more sense. I think, one of the reasons my ui screens are so complicated, is because I am trying to write a desktop style app on a mobile device. Regardless of the screen size, it seems they need to be simplified. The input system is very different (touch I mean).
So I will try again without trying to be so tricky. The KISS System.
I know things come slowly to me, but a lot to learn in many directions.

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/Anatomy.html#//apple_ref/doc/uid/TP40006556-CH24-SW1