Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Only an idea, a type of GState for ui elements
-
Couldn't we just extend the button class somehow and modify it?
An example I saw:
class MyView(ui.view): def __init__(self):
-
@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.
def set_attr(self, d): for attr in d: if hasattr(self, attr): setattr(self, attr, d[attr])
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
-
See copy_button.py for a working example that copies attributes like action, border width, rounded corners, etc. If you have a better way, please submit a pull request.
-
Lol, @ccc I am sure it will be sometime if ever I have a better way.... But it's in my mind now :) nothing like a challenge to get the blood and brain surging. Let's not hold our breath though
-
@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 :)
-
You must have read the last paragraph of https://docs.python.org/2/library/copy.html ;-)
Two interesting options here:
- Ole could create
__copy__()
and/or__deepcopy__()
methods at the base class level - You could create
__copy__()
and/or__deepcopy__()
methods at the your subclass level
NOTE: I was wrong above, you can subclass ui.View but not the other ui.widgets. :-(
- Ole could create
-
@ccc, I am a little confused. The above , is that your answer for this question or the question about the problems I am having copy my day class in the other post?
-
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.
-
I replaced
copy_button()
with a simpler and more generalcopy_widget()
which should work with other simple widgets that are simple subclasses of ui.View.