Forum Archive

Hi everyone,

I recently tried Pythonista and fell in love! Since then out of sheer curiosity i whipped up a few things I wanted to use in planned projects.

I'd like to share with the community but not until its tidied up a little..

Wondering what the community here would like (if any of course)

I've done (in varying levels if completeness):

• Tab bar clone (Load views via bottom tab bar)
• Progress bar (based on PIL/generate graphic bar)
• Checkbox View
• Modal/popover with ability to launch under uiButtonItems (pseudo drop down from title bar button, HUD style views, and traditional web style modal box look)
• Updates to the stash pip module to accept requirements.txt
• ui based "config" using a modified form dialog to allow for lists, file and folder selection.

amongst others...

I am keen to finish one of them off, and I know there has been a ton of these through here before but I always tried to make it different.

at any rate, l share whatever I finish but looking for some inspiration as to which one.

Thanks for any input and have a great weekend!

@reticulated, thanks for posting this. For my projects, the last three on your list look most applicable.

@reticulated, hey, great you are doing this. For me I would love to see a Modal popover class. But fairy generic so it could be the go to whenever you want to create a quick popover menu. I have tried this before, but failed. I get too caught up in the detail and dont know when to stop and some of my skills are not good enough to do justice to what I want to have.
At least in my mind there would be a base class you inherit from. The base class would provide enough functionality to do say a quick and dirty list with accessory items, like checkmark. They base case could also expose some helper methods/functions for extending the popover. Also, maybe ABC could be used to help the base class be more useful by forcing the user to implement some methods. The other thing that would be nice is persistence (file) for selections/settings. Another important thing would be the handling of different iOS displays. Eg, ifI make a popover for myself, i set the height to 75% of the window height. The width is a little trickier I think. I normally use an arbitrary number, which is not correct. I should be doing more checks and logic based on the device etc.
I am not sure if you are on the beta or not. In the beta there is a call to get the windowsize vrs the screen size. Not sure that call is in the App Store version or not. But this so you can respond to split screen mode etc...
Anyway, thats my idea :) Maybe inheritance is not the way to go. But to me it seems like a nice way to go along with ABC to help the base class to help the subclassed class in a orderly manner.
Just food for thought :)

@mikael

Thank you!

@Phuket2

First and foremost thank you for the detailed response!

For me I would love to see a Modal popover class. But fairy generic so it could be the go to whenever you want to create a quick popover menu.

Agreed! The current structure utilizes a base class which effectively attempts to do the screen and window measurements, kind of like a helper.

Most recently inspired by dialogs._FormDialogController I am working to implement a 'content_view' which allows me to set some base options, including defaults such as (but not limited to:

• border
• padding (not a fan of text to the edge)
• corner radius
• dismiss button boolean
• dismiss button styling (button options)

I have tried this before, but failed. I get too caught up in the detail and dont know when to stop and some of my skills are not good enough to do justice to what I want to have.

I've seen your work and respectfully disagree with the lack of skill

I am notorious for obsessing over details, especially edge cases which have no major impact on the project!

At least in my mind there would be a base class you inherit from. The base class would provide enough functionality to do say a quick and dirty list with accessory items, like checkmark.

In my implementation the base class is a straight up plain view, but funny you mention it, I was planning on including my own version of the form dialog + list dialog + edit list dialog, all things considered these are prime use cases for the modal.

However- as you suggested I don't want to reinvent the wheel with an encompassing solution- as it already exists and does a great job.

They base case could also expose some helper methods/functions for extending the popover.

With that, perhaps:

• Method to produce tableview popover
  • form style (basic) as per above
  • option list (checkmarks)
• Methodnto integrate my config class
• Method for ImageView modal
• Method for TextView
  • Read only
  • editable
• WebView
• Add View (any)

Also, maybe ABC could be used to help the base class be more useful by forcing the user to implement some methods.

I didn't think of that! That solves a couple gotchas I had in mind

The other thing that would be nice is persistence (file) for selections/settings.

Already in the works!

Options include:

• Pickle - dangerous but can even save custom objects which may be embedded
• JSON - more work to inspect/assume what should be saved but safter

Another important thing would be the handling of different iOS displays. Eg, ifI make a popover for myself, i set the height to 75% of the window height. The width is a little trickier I think. I normally use an arbitrary number, which is not correct. I should be doing more checks and logic based on the device etc.

I strictly use percentages- but allow the developer to override at their option.

iOS is pretty easy in the fact that all of the device resolutions are known.

I would likely follow the method Bootstrap uses, where (pseudo code)

get screen size
get window size # yes, in the app store

if screen size < window size:
    split_screen_logic()

setup_width_however

if width < (2nd smallest size):
    do stiff
elif width < (3rd smallest):
    do stuff 
...

present final view

This gives me an idea - The popover class could power a helper utility which pre-sets each screen size - assuming your device can display it, to help test your view designs!

I am not sure if you are on the beta or not. In the beta there is a call to get the windowsize vrs the screen size. Not sure that call is in the App Store version or not. But this so you can respond to split screen mode etc...

Im not in the beta, but id sure love to, however get_screen_size is in the app store version.

Anyway, thats my idea :) Maybe inheritance is not the way to go. But to me it seems like a nice way to go along with ABC to help the base class to help the subclassed class in a orderly manner.
Just food for thought :)

I will definitely look into these things.

Once I have a decent start ill put it up on GH - and let everyone have a time picking it apart.

Oh before I forget, I also implemented a helper class for styling the modal.

I am going to expose it, but as well as setup method get_styling() which will return a clean, serializable object which can be used across a project.

Any other thoughts and ideas are welcome and appreciated.

• r

(Sorry I wrote this a few days ago, but looks like i forgot to submit it) :(
@reticulated , thanks for your detailed reply. Sounds great what you are doing. I also agree about the padding. I also try to use a content_view same as @omz when doing such things. It's super helpful. Only small issue iteration over items in the view. But @JonB ViewWalker helps with that.
I never use pickle. I am just scared of it :). Just because I dont understand all the gotchas. But for the config/state etc... if you say choose json, for config/settings etc, you could possibly have an object that does the read/writes etc in your storage of choice, shelve for example. But the object may allow for different storage's. I only mention because TinyDB project has this concept of custom Middleware and storage. But this maybe over the top.
But really looking fwd to seeing your project. I have put a watch on this thread so i will get updates