Only an idea, a type of GState for ui elementsbrowsing

Not really same as GState, more like overriding the default attributes of the creation of the various ui elements. So if you could say something like ui.Button.GState.width = 120, then every subsequent call to ui.Button() the width of the uiButton created would be 120. And so on for the other attributes. If it got that far, then you would also want to be able to do the same by sending a dict as a param.
Maybe this is really stupid. Just an idea

@TutorialDoctor, sure can create a custom view, also can create a function that returns a ui.button to your requirements. Could also use dicts with hasattr and setattr to do the same thing. I just mention from a sort of purest point of view. The less we have to do the better. Not about being lazy, just if you could set the global state for all the ui elements you will create without rolling your own, makes it much more readable to others as the API is std and we all get used to reading it.

I think I understand a little of the problems omz must have with the ui module. I personally think it's fantastic, but in reality I think it's not were he would like it to be as far as consistency goes.

For example, I wrote a class today, just full of attributes to pass to a custom class. In the init(), it just sets a bunch of attributes with default values. The idea being I don't have to provide methods in my custom class for all these various properties. But then I just added one small method to my properties class that allows me to set the attributes of my properties class with a dict. I haven't tried this yet with the ui elements, but would be great if you could do the same.

Maybe the above code is a little flawed. I will find out as time goes along. But I think that each ui element should support a similar call. My class only had attributes so I didn't need any checks. But the idea is there

@ccc, but is my thinking correct to think each ui element should be able to accept a dict of attributes at the creation time? Seems to me it would be easy to implement on omz side (I just think). Again, I am ok to be wrong and don't mind to be corrected. I would have thought this could bring a cheap (in effort) uniformity to ui elements. Please don't get me wrong, I am not trying to be smart or to be validated. I bring up these things because I think like others here, I am getting very passionate about Pythonista. I realise for omz only so many hours in the day and everyone will champion their own cause in terms of functionality. My cause is currently ui :)

The idea of passing in a dict of attributes at initialization time seems like a disruptive change from the current ui API. However, it should be easier to make a copy of a existing ui widget than it is today. The cookie cutter approach (implementing a __deepcopy__() method) seems more Pythonic than the passing in a dict approach that you mention above.

@ccc, fair enough. But if it was a named param, it would not get in the way. And maybe I am not being Pythonic, because I don't really know what that means yet. But just seems to me a great aux method to offer for any class. In fact, I think Python should implement it as a std feature. Maybe I will get burnt at the stake for such a suggestion. But it seems logical to me.