Making arcs and filling them with in ui.Path
Hmmm, well this is embarrassing 😰😱
I really can't figure out how to use the ui.Path functions to create arcs or filled segments for a circle. From what I can see I have to understand how to correctly use sin and cos at minimum to be able to do it. I looked it up on wiki tried, but was just getting a headache.
Would be fantastic if someone had time to write a small func or class so I can do this. I want it to make custom views / indicators. Like a progress indicator for a download etc. I want to do one like apples app updates where a thinker arc is drawn around a circle and another style where the segments are filled in. I think I need back the the params for Path.add_arc(center_x, center_y, radius, start_angle, end_angle[, clockwise=True]). Assume I have to pass a Rect and the required angle, hopefully 12 o'clock being 0 degrees.
oh! Just found out I can not use another custom view to embed my draw method in, which makes sense.
It should be possible to do that. What does your code look like?
Is there a way to get/set the ImageContext object.
Not really. An
ImageContextis basically just a way to redirect drawing code into an image (for example, to save a drawing as a file). You don't really need an
ImageContextfor drawing in custom views. Views have a drawing context of their own, but it doesn't correspond to an
ImageContextobject, and you can't really access it (nor should you actually need to).
draw()method (of a custom view) is called (by the system), a drawing context is already set up, and all drawing functions affect the current context. So it's perfectly fine to do something like this:
# ... def draw(self): SomeOtherViewClass.draw(self)
to use the drawing functionality of a different view class.
@omz , thanks. You are right it does work. Not worth posting the code now, it's all over the place. Trying to work around many issues. But this will help simply a lot. Thanks again 😱
@omz , it's still crap now. But but i think it can go somewhere. Trying to work on a test container as well as a type of framework for a widget/gadget/whatever....😱
It's basic...but still trying, gist is here
@omz The default
ui.Viewdoesn't seem to have a
drawmethod. I assume this is special-cased internally to not cause errors, but it would be nice to have a default
drawmethod (even if empty) so we can always use
For example, this code currently fails, because
ui.Viewdoesn't have a
import ui class CustomView(ui.View): def draw(self): super().draw() ui.Path.rect(5, 5, 45, 45).fill()
But if we'd write a subclass of
CustomView, we would need to call
super().draw(), otherwise the custom drawing code in
CustomView.drawwouldn't be executed.
This isn't a big issue - currently you just have to leave out the
supercall when the base class is
ui.View- but I am a fan of consistency.
@dgelessus , I am not sure I follow you 100% here. But in this case wouldn't you just do something like
I know your statement was directed at @omz , but just curious
@Phuket2 I'm not talking about superviews of a view, but about the superclass (base class) of a custom view class. What I mean is that currently when you subclass
ui.Viewdirectly, you cannot call
super().draw(), but when you subclass another custom view class (that has a custom
drawmethod), you have to call
ui.Viewhad an empty
drawmethod, you could always call
super().draw()no matter what.
@dgelessus , I don't have a fraction of your knowledge. I knew you were not talking about superviews directly. I only mention that, because what I understand is if there is not superview it's the root view object.
But I have read some docs on Python objects. I can't remember exactly what it says, but I think it's something like there is always a base class. I think it said something like that.
So, I guess you are saying when super is called on the base class it should point to itself , just to be consistent and compatible will other Python patterns.
Hmmm, I am already regretting this post. I am in the deep end of the pool and need floaties 😱
Look if I am so wrong, it's ok. No need to waste your time to respond.
Yes, if you write a class and don't set any superclass(es) yourself, its superclass is automatically
object. (In Python 3 at least - the situation is more complicated in Python 2.)
This isn't really important here though. I mean that
ui.Viewshould have a
drawmethod, so that subclasses can use
super().draw()in their own
drawmethods. (Currently this fails sometimes because
@dgelessus , ok I think I see. Actually draw also does not exist in a custom class unless you have a draw method. I was just doing some print dir(obj) to understand your post.
If you print dir(custom_class) without a draw method defined it does not show up. So I guess it's just added at runtime as required. Not sure that's normal or not. I would have thought the method would be there, but not the ImageContext etc...not sure if it's normal or not . But seems like maybe @omz took a logic short cut 😱😈😈😈
Sure I will regret this post also, I am probably way off course. I will learn to keep my big mouth shut one day.