Forum Archive

I have posted this here as I am not sure its a bug or not. But as far as I can see its not possible to create a std ui Search view as in ios using the ui module(as far as I can see, very possible I have over looked something).
But I think the main reason you cant get the same look and feel as a standard ios search view is because you cant manipulate some attrs of the ui.TextField, eg bg_color, corner_radius.
I would have thought you would compose the the view like -
1. Create a ui.View with a corner_radius and set the flex attrs.
2. Create an ui.ImageView and add the built in image 'iob:ios7_search_24'
3. Create a ui.TextField, with no border_width, corner_radius, bg_color
4. Add the image and textfield to the view, positioning them with x any attrs, set the flex of the textfield.

I have tried various things, but I cant get a search field view that is the equivalent of the ios one.

Again, maybe I am just missing some thing simple. Adding an search emoji in the placeholder is not the correct way.

Any insight would be great

I did a somewhat convincing search bar in my objc_browser.py in objc_hacks repo.

using:

• a container view (gray bg color), 320x420
  ** subview: textfield, frame=(20,4,280,32) to center it up in the larger frame, corner radius 16, border color 0,0,0, bg color slightly off white, and placeholder='\U0001F50E Search'
  with a delegate that looked like:
  def textfield_did_change(self,textfield): self.filter=textfield.text.lower() self.filtereditems=[x for x in self.items if self.filter in x.lower()] self.tv.reload()
  Well, probably best just to go look at the code...

I have in my half finished projects a wrapper that implements a UISearchController in objc_util, but this isnt quite finished(it displays, but is not functional).

you might also look at the blackmamba code -- i feel like this is something @zrzka may have done already.

There's no search controller in BM. I was kind of lazy to do it. I just use simple text field and table updates (insert, ...) or reload.

@JonB , thanks I did copy out the relevant parts of your objc_browser.py and ran it. It's not what Iam looking for. Have done similar before. The search icon should not be in the placeholder text, you do not get the same iOS feel. Clearly in the Native iOS version the search Icon is an image object positioned at the head of textfield in a different object. I am not trying to be smart or funny, but its pretty fundamental to the look of native iOS apps. I didn't look at @zrzka code, but the search boxes I see in his helper apps are not native iOS looking.
Look, I will post this as an issue on the repo. As far as I can see the only thing stopping us making a 100% native looking/behavioural iOS search view is the inability to modify some of the Textfields attrs. bg_color, corner_radius , bg_width. I am not sure why @omz ignores these attrs when you set them. There could be some technical reasons why he does this. I am not sure. But it seems to me we should be able to easily create this view. Then with the built in transform features go on to provide some of the different behaviours you see in different iOS apps like when you tap into the textfield, like in contacts, the textfield width shrinks and a Cancel button appears at the right of the enclosing view. Granted, this could also be done now.
Not sure ppl think this is an issue or not. I personally would be able to be able to make a native looking ios search view. Also with out the help of objc. I mention without the help of objc, for me it does not seem necessary and search fields do various transformations, more than the one simple one I mentioned above where a Cancel button is added to the rightmost of the field in the enclosing view. Although I dont know if objc could interfere with things like this but it would better not to have to worry about it.

If you are interested in a UISearchController, I wrote a wrapper for the native controller for PyDoc it needs a little bit of work still but it might give you a starting point. You can find it here this would be something that I would find very useful if it was in the std ui module.

I also had started a wrapper of UISearchController.
https://gist.github.com/874c3aead15a8be3c847f5c46c6397db

Basically works, though currently not move/delete.

Guys, please dont take me the wrong way. But I am not really into the whole objc thing. I am happy if I can just get better at Python. I am glad objc is included in Pythonista and for sure others code with objc has helped me in the past.
But having zero experince with it makes me feel quite uneasy when I am relying on something that uses objc.
But as I say I am personally happy its there as I know a lot of cool things can be done with with. Eg. Not that I have looked, but i expect BlackMumba relies on obj, I use BM all the time. But as a utility. I install and forget, the way it should be. I suspect StaSH also relies on objc (I am not sure about that, I am not sure objc was around when StaSH was released). Anyway, I like I am sure many others rely on that also.

So thats why I am hoping this will get resolved in the ui Module. I feel it should be quite simple thing to do. I was just interested to make a function that created a search panel and basically save it as a snippet. Same as IK did with the Cancel_OK button view I posted the other day. Might have given it some Basic functionality, but more important for me was just creating a well behaved view that could be created to another view and visually take care of its self size wise just using flex.

Anyway, I guess we will see. I opened an issue.

Once someone develops something with objc that works, and provides a convienent python interface that hides the details from you, then it effectively becomes no different than the native option, and you never need to worry about the objc underpinnings.
You just have to import an extra module.

The question becomes, what should that interface look like? I am thinking a SearchableTableView should be identical to a tableview, except it should have an option to show_search_bar, which will toggle the search box. The datasource then is responsible for implementing a searchbox_did_change(tableview, searchtext), and filtering the results. The SearchableListDataSource would be the "default" to work like ListDataSource, and would handle the default use case of presenting a list of textual items.

@JonB, in the case you cited I agree. Basically where its a module you import and only interact with it via the intended API. I was more thinking about building blocks. Were you are more likely to paste the code into you module and interact with it a bit more than you would in a standalone module. Look, I realise you could can put anything in a module and import it. Sometimes it doesn't seem so natural to do that. But natural has different meanings. I have had this mental block with Pythonista in the past of using a lot of modules. And it's because in past to share (simple projects) that contain multiple modules is not the easiest thing for a lot of ppl to install, test use etc. I mean trivial projects. However, with the beta and iOS11 this is quickly becoming less problematic. Less problematic is not the right phrase, its getting quite easy. Even though there has been bridges between Pythonista and 'Working Copy' before, the multitasking between the 2 apps now is great. Working both ways with repo's makes like so much easier.
So hopefully to share trivial multi module projects in the future will become a no brainer.
What I should have mentioned, whilst the project might be trivial, you still might say have 5 modules for the trivial project, as 4 of those modules might be just helper modules you include in every project you make. You make only use a couple of classes/functions from one or 2 of the modules. But to me it doesn't make sense to go through and cherry pick out those support modules/classes or functions each time you want to share something. In way, this has hindered me as I have never really made my own support files directory with modules that I could reuse in all my projects (this is my own fault). But I think I will start to do that now.
Sorry for the tangent, but I feel its all related, well for me it is.

@JonB , your searchable table script was almost exactly what I was looking for in order to provide an iOS citation picker for my writing. I've adapted it a bit so that it inputs a list of my citation keys. However, I can't seem to figure out how to return the selection. Tapping on an item only highlights the item itself but never returns it or closes the search table. I've tried to adapt the script to return the selected item, based off other examples, but have been unable to figure it out. I'm sure it's relatively simple but I'm quite new to python and only at the level of basic trial & error. Any help you could provide would be most appreciated, and thank you for your work either way!