Any User Interface requests?
Here is a simple split view type controller class, implemented using ui rather than objc. You set the .mainview and .detailview attributes to your predefined views, it autosizes them, then dragging inside the view right or left shows/hides the detail menu. Also can be linked to a button, as shown in the example, or in general user can provide delegates that get called when detail is toggled. Rotation works as you'd expect.
Currently won't work quite right in
panel, since panel hijacks gestures on custom views. I am remembering that I had to implement this with a scrollview as the touch interface, but this might get the ideas flowing anyway. Also, I realize this may need a close button on iPhone, or rotate to landscape,to dismiss the view, since tableviews steal the swipe gesture.
@JonB , nice and exiting. I got the script, the sliding is nice. I will try to make a later today. Thanks for sharing
@TutorialDoctor , I still struggle with Python, so no reason for me to start looking into objective c 😬
But I had seen it was available in oc. I have no idea of the reach of the objc_utils packagage in Pythonista. But would be super cool if some of these elements not included natively by omz could be somehow loaded into the existing framework, meaning as a ui.View. Maybe @omz will just include it in the next beta 😱🎉👍
I made an update which uses a scrollview instead of touch.
This plays nicer with other ui components and
panelpresent style...now you can swipe over tableviews, textviews, etc and it works.
@JonB , there is something wrong with the update. If you show in a sheet, it's bouncing. No were near as good as the first version.
@JonB , another issue with the scroll view approach is the sliding on rows in a table. Eg, delete
tweaked again to fix bounce, or at least the overscroll in one direction (dragging left when detail is hidden, or right when shown).
ack, yes tables are broken in this approach.
i will experiment with a scrollview behind the other views, rather than a scrollview container.
Webmaster4o last edited by
@JonB , thanks. But it really doesn't work. What about not using the scroll view, using version 1 with a margin in between the 2 view. Well the margin/border also being a uiView that the width can also be defined in the params. Also access to the margin/drag view via method call or property to make it easier to load a custom pic etc to use.
If you did something like that, it would be very nice to keep the detail and main views still responsive to dragging. Will be times when a control is not taking up the whole view. I am sure I have seen this behaviour in apps before
@JonB, I don't just assume you will or want to make these changes. But If you don't mind working on it, I don't mind testing it and giving feed back. I don't want to dig into your code though. I mean I am reading it, but I am not good enough to run with your code myself. I would love to have this view in a rock solid form if possible. I am also happy to try and make helpers for simplifying the detail and main views.
Anyway, I will leave it to you.
Just in case a few items:
**style = 'slide' ** , if style is passed None, it still slides. If it's passed None, it would be great if the panes were just fixed. Ie touch events are negated
Layout , I noticed layout is not being called in your code. Maybe it's fine. I haven't had a chance to test that far. But maybe it's all being handled with flex
opening state, I know this can be changed with toggle_detail. But it would be nice to have a param for the opening state.
**menubar and status/footer views ** would be nice if there were properties to add a view for a menu_bar and/or a footer_bar (ui.Views). And the split view still takes care of the geometry
Food for thought 🎉😳😝
I am not Su
@Webmaster4o , I really have not read the press, rather just skimmed it. But from what I can see, it's not if swift will replace it, it's just when will it replace it. I seen a few months ago, swift lept way up there on the charts of language usage. As I say I have skimmed the articles, but I think there is no doubt about it, swift will replace objective c. But please note, I say , I think. But realistically, I think you will not find them too far apart. I think the hardest thing is getting your head around the apple framework more than the language in this case. I am guessing the objective c guys will not have such a hard time to make the transition.
working with version 1 touch events
@JonB, I wrote a class for both main view and detail view. All appears fine, expect for main is not receiving any touch began events. I put in a print statement.
But I made sure the print touch_enabled is set to True as well I also bring the view to the front.
Even with your main code with the simplest of class definitions like the one below, if I set your mainview var to TheMainView, touch stops working. I have tried all sorts of combinations, I can't work it out. It could be a bug, or something so simple I am doing wrong.
Do you have any ideas. I have looked through your code, I can't see any reason for it.
class TheMainView(ui.View): def __init__(self, **kwargs): ui.View.__init__(self, **kwargs) self.touch_enabled = True self.bring_to_front()
I guess I should have mentioned that this approach will not work touch enabled views. How would the system know which view you meant your gesture for? This is the same reason swiping over a tableview doesn't work. I suppose one approach would be to look for touch handlers within mainview, and then if the splitview decides the touch is not a swipe, it would call the mainview touch class. So you would be allowed to implement maybe touch_moved for vertical swipes, and touch_ended, touch_began would be delayed.
There is a splitview method show_detail and hide_detail and toggle_detail which let you hook this into other ui elements, like the menu button, or custom gestures within your main/detail view. So if we are willing to do without swipe to dismiss and instead have a close button, or implement within the custom views, this becomes very straightforward.
Alternatively, if we wish to dedicate a small area at the border or in the title bar for swiping, this could work. I updated the repo with an attempt at this approach. The gray color could be changed or not there at all. this implementation was a bit messy, but it shows the idea at least. I also gave you access to the mainview and detilview in the constructor, and the initial state.
The intention here was that one would write a separate NavigationView type class with optional top and bottom menu bars, which you would set as the splitview's mainview, and/or detailview. There it would make sense to implement a custom swipe action which could be hooked into the splitview. Alternatively, one could add this splitview as a subview to another view, for instance if you wanted the sliding container to only be a small portion of the view.
Note for changing the main or detail view, you simply set the attribute to point to the new View, and the SplitView class takes care or removing the old one, and adding the new as a subview, as well as (in the scrollview version) adding a splitview attribute to the main and detail views so you can more easily relate main and detail views ( i.e from the mainview you could write self.splitview.detailview to find the detailview).
TutorialDoctor last edited by TutorialDoctor
I also agree that the Apple framework is the harder thing to understand. I have been looking at the UIKit and Foundation framework references. Okay, so how do you use them?
I do however see similarities between how the Apple framework works and how Pythonista's own UI module work.
I wonder if there are analogous parts. Perhaps a class that extends the ui.View() module with Objective C controllers would do the trick. I would rather have it be authentic than try to fake it. If I do use Objective C (once I see how it works) I will try to make it as easy to understand and edit as possible.
If anyone has a solid solution to this one though, I will go ahead and use that.
Found a good source of information on how they work though
Tizzy last edited by
I tried to do a simple GET call using swift... and oh my it needed like 50 lines of code, nothing like our beautiful requests module in python. When I first saw it I though YES LOOKS LIKE PYTHON. Not the case.
I'm +1 for the split view. @jonB the behavior of the split view in your example has a slight oddity feel-wise. You can slide out from the left without paying attention to where you touch, but to slide it back you have to start EXACTLY on the grey vertical bar. Would it be possible to make it so that you can slide it back with a general purpose slide from the right? I feel like that would feel more natural.
Also, even if you select iPad mode, it seems to ignore it and just have the slide out panel. (iPhone 6s+)
The ipad/iphone mode was really intended to both be run on ipad, where you have the extra width, to see what it would look like on iPhone... Since things get resized for fullscreen, I suspect they would look the same. I don't actually have an iphone to test this out on though!
I agree I am not 100% happy with the behavior. One option which I think would work well would be a swipe on the title bar. I may try playing around with objc to see what can be done easily. The nice thing about the all ui module approach is that it will be easier to extend/modify for the average user, and is less likely to result in an ugly crash.
One approach which I recommend, is to start with a top level ui.View. Then, you use ObjCInstance(myview) to get the OBjC object. This makes it a little easier to present, since you can just use myview.present().
Note you don't actually have to use steven troughton's UIKit module or Foundation module, and in fact I would advise against it (since he is instantiation ObjCClasses of every possible class, most of which you don't need, plus not all of these are available on ios 8). Just use what you need.
In many cases it is easier to use the ui module version of things like buttons, etc, and using objccinstance if you need to add these to objc views, etc.
Ok, figured it out. I kept with the scrollview approach, but added a method which allows scrollviews/tableviews, etc to scroll inside the main scrollview. There was an objc method which allowed this. This lets tables use the delete row swipe.
(edit: Arg... so this works in sheet, but not in panel. back to the drawing board)
@JonB , I just tried the latest version. I am not sure we are seeing the same things or not. But on my ipad pro, I get like a slide, then like a snap to then a bounce type effect. Just running your example without any modifications whatsoever. What I see, I don't think a user would enjoy that interface. It's almost like you have to flick the screen rather than swipe it
@TutorialDoctor , did you pick a project to work on? Another idea I have had in the past is to make ui's based on iOS apps. I still think it should be done. Like, contacts, reminders, notes , system prefs etc... I am guessing generally these are the core interfaces. Hence my excitement for a slideview.