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.
[share]Interactive MatplotLib backend
-
thanks. yes my intention was to try to have something that could be useful for ther things. (eventually I am thinking about dockable toolbars, that can have submenus that fly in and out from screen edge -- which could be used as a replacement for the defunct sidebar present mode)
I was somewhat lazy in the touch handling code. All dragging, including the resizing, is handled by the top view touch handling code. If the content view is enabled, you will need to drag from the title bar. I need to give the resize arrow its own touch handling.
As @Webmaster4o has pointed out, the menu bar does not jive well with ios ui philosophy. I think a title bar may still be needed, since it needs to contain the figure title, but perhaps something akin to safari where the title shrinks down when not in use, and a tap opens up a larger menu ( which could eventually include other matplot specific toolbar items, such as data select, delete, data cursor, as well as docking/resize presets)
On the matplotlib side, I am also not particularly happy with the update rate performance, and am rethinking the entire renderer approach. Right now, each time you do anything to the figure, it has to rerender the entire thing, that means drawing out each little line segment, marker, etc get drawn into a bitmap. I am thinking it would be possible to use UIBezierPath's that get created and cached, and make use of ios transforms rather than matplotlib's transforms, and only get regenerated when the data changes. The matplotlib backend api is pretty poorly documented, (and no other backends take advantage of such path caching), making this an annoying exercise in trial and error.
-
@JonB , 0k. I was just coming here to make another comment.
You have this code,with a comment
@classmethod def detail(cls): '''detail, a.k.a. editor panel. dragging does not work yet until gesture recognizer is added''' return cls
But in my example above i am running in py3, the TableView scrolls, I can swipe to the console or help panel, the palette is still there and appears to behaving itself.
I did change the below attr to True, to get the list to scroll
self.content_view.touch_enabled=True, it was FalseSo I am not sure what is not working?
Edit: all the underlying screens working as expected. -
For content views which do not have PanGestureRecognizers, which would be anything not in a scrollview or tableview, ui.Views do not take ownership of touches that occur in their bounds, and any type of touch motion gets stolen by the PA2SlidingPanel container. This has long been a complaint of mine ( presenting a custom view in a
panel
breaks any custom touch handling that is achieved by simple touch_moved), but using Gestures.py, it is possible to install a gesture recognizer that prevents the PA2SlidingPanel container from recognizing swipes if they are recognized by the custom view.You can see the problem if you set the parent to Windows.detail in the original example, and try dragging the window left or right -- you get one move, then the pythonista panel starts sliding.
For content that use pans, the the only way to move would be through the title bar( another reason to not completely ditch the title bar), though perhaps using something like long press to switch between the content getting touch events, and the Overlay container getting the events.... Not sure. Floating interactive windows are not a concept used by iOS, (the ios9 PiP content is not interactive for example) so I don't know that anyone has thought through how they should work.
-
@JonB , sorry I dint really figure out how to make the change you pointed out to see the problem with panning.
If not too much trouble could you just write the change.
I have the original ready to try on.
I think I get what you are saying though. Still like to see it -
@JonB , but anyway I really like how it fits in with minimal code. I realize you are not finished. But I really like when you can do something like the below. Meaning it seems natural to how things already work.
Getting the name from the content needs some help though. If content.name is None, error expects a string. Small thing I know, just let you know.But one line and your overlay works in a normal senerio. That's great
class MyClass(ui.View): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.overlay = Overlay(content=self) self.make_view() def make_view(self): tbl = ui.TableView(frame=self.bounds) tbl.height -= 44 tbl.data_source = ui.ListDataSource(items = range(0, 100)) tbl.flex = 'wh' self.add_subview(tbl) if __name__=='__main__': f=(0,0,600, 800) mc = MyClass( name = 'My Table', frame = f)
-
@JonB , sorry, don't mean to bombard you post with senseless code. But this just seemed to small to put into a gist.
Anyway, the below is more inline with your original example about and fitting it into a so called normal use as I think of it anyway.
I thought It would be nice to see what happened when drawing into the content view. You would hope it all just works as it does. But I guess a lot is going on. Also nice to see that the alpha is working all the way back to underlying Windows.class MyClass(ui.View): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.content_mode=ui.CONTENT_SCALE_ASPECT_FIT self.overlay = Overlay(content=self) self.overlay.content_view.touch_enabled = False def draw(self): w = self.width if self.width < self.height else self.height r = ui.Rect(0, 0, w, w).inset(5, 5) r.center(self.center) s = ui.Path.oval(*r) ui.set_color((255, 0, 0, .4)) s.fill() if __name__=='__main__': f=(0, 0, 300, 400) mc = MyClass( name = 'My Red Cirlce', frame = f)
-
@JonB, I don't know if this special or not. But I had both your original version running and my modified version running at the same time. So 2 different apps running at the same time. The overlays still working normally. Maybe you expected that. I launched the other version by mistake. That's pretty cool
Actually there is a third app running also. I was replying to the post in an app that is in a panel.
-
Overview(content, parent=AppWindows.detail)
or
Overview(content, parent=AppWindows.accessory)
(in the latest github version)
-
@JonB , are you still refining the overlay class? Not sure about the real world use cases for it. But I think one real world use case is when you are making tools for ui. Look, I call it a floating palette, but toolbar or whatever. But can be be very handy if you want a bunch of cmds to act on a view without having to incorporate the interface into the view.
Just saying you might be more inclined to refine it in a certain direction if you can see a real world use for it.Same idea as below...
-
yes that is a good idea. i probably ought to revive editmenu as an overlay...
-
@JonB , I really think it's a great idea. Granted it's not a normal iOS interface element. But many other uses also I suspect other than a floating toolbar/editmenu. Realtime property sheet of the current view for example. But it does something that is very unique. It can float and it's not modal.