Wish list for next release
First of all, great job with 2.0, it's a great update, and everything I expected.
I don't know if you're planning to work on an editorial update next or pythonista, or maybe something else, but I thought I'd start a thread where people can post their thoughts about what should go into the next update.
I think for the next update, it would be helpful to just provide more modules for use. This would be a good contrast to 2.0, which updates the editor in a lot of ways. The top 5 modules I'd like to see the most are:
photosmodule but for videos
I think this alone would be a significant update to pythonista, adding a lot of functionality.
I'm curious to hear what other people want to see most from the next update.
@mikael Regarding the keyboard dismiss mode: Do you think this would really help on the iPhone in all the cases? I'm not familiar with these modes but is there really a mode that would hide the keyboard when the cursor is located in a simple text field and the view is not scrollbale?
I don't know if it has already been mentioned somewhere but it would be nice if the app shows that it's running a script via url "api".
If the app starts up and is not returning from a suspended state it just shows the initial screen and I am not sure if the script is running
The small indicator with the script name would be nice for the first start up
This is a wonderful idea. Also would be cool if when you tried to run a script while the other script is running, instead of just a modal dialog with one continue button if there was a button for "stop other script and run this one"
Or better yet ( I Don't have any idea of the technical feasibility of this) what if you could have multiple scripts running at the same time on entirely different threads with some sort of overhauled UI to make it clear how many and which scripts are running?
@marcus67, no, unfortunately I think this is just one more thing in our toolbelt, exact approach to be selected based on the individual use case and UI preferences.
Just to collect my thoughts, here's the ways we have for dismissing the keyboard on iPhone, until Apple does something about it:
- Add a custom UI element like a button in the top bar or a gesture somewhere
- Auxiliary key above the keyboard
- Using ScrollView/TextView scroll to dismiss option
One more thing:
Could we please remove or have an option to silence the various clicking sounds made by the editor auxiliary keyboard keys?
Currently they do not respect the system-wide setting, and are really annoying in a quiet environment.
A "busy" option in console.hud_alert for showing that something is loading. This can be seen on other iOS apps frequently.
@disorientedp You can use
@disorientedp The function
console.show_activitycan take a string argument, which makes it display a HUD alert with a spinner and that string message, in addition to the spinner in the status bar. This has been around since at least Pythonista 1.5 but is not documented anywhere as far as I can tell. @omz
@dgelessus is right of course, it's called
show_progress(). I wasn't aware that the optional message parameter is undocumented, but that does indeed seem to be the case. Sorry about that.
I would throw in module
lxmlwhich would give us enhanced XML support including XSLT 1.0 transformations.
@marcus67 I assume there's no XSLT 2.0 transformer available. (Thin on the ground last time I looked.)
lxml, since without that module it's rather difficult (or it has been in my admittedly somewhat limited experience) to get
python-xlsxto work and those would be useful to have in Pythonista.
@MartinPacker I haven't found anything. XSLT 2.0 is hard to come by, even outside Python. There's only a small number of implementations.
I am not sure if being able to subclass ui compents is in the wind or will ever be. But I thought of something that may be quite useful, at least in my mind.
The simplest form of my idea is that you could call a ui method that sets a callback function that is called upon creation of any ui component. We could be passed the object type, or worse case check with type.
A little more refined would be able to also set different callbacks for the different types of ui components.
That would offer a lot of flexibility and possibilities. Also, especially when testing would be so easy just to style the objects. I know, you can still just have a make button function anyway. But this just seems so much cleaner.
Not sure the impact this would have on performance or threading issues etc. I assume threading type problems would not be an issue as it would only be called on creation.
Phuket2. - see mikael's last post here
The ObjectWrapper approach is very elegant, and effectively allows you to subclass unsubclassable objects without much cruft.
@JonB , ok thanks. I have installed it. It's not really apparent to me yet why this is a good idea. I have read the doc. I am a little slow on the uptake.
But in your opinion does my idea make sense or is it full of gotcha's and a bad way to implement the functionality.
The little I can get right now, ProxyTypes will help with the subclassing but the thing I like about what I said is that you can centralise a lot of code for styling/adding dynamic attrs etc. Also when sharing here, is all built in.
I assume that if ProxyTypes is compelling , that @omz could include that.
I assume if that callback function was available, could even further help ProxyTypes, hmmm I think....
Ok. But thanks. I will try somethings I was struggling with before when trying the make wrappers around the ui objects
Uh... Speech recognition. Duh. For like, Siri.
@jbap Will you be more specific? I'm not sure I understand.
@disorientedp I think he/she means not dIctating code, but a module for recognizing user speech, which would allow him/her to create something like a basic form of Siri.
I'd first like to say that from what I've used so far, this seems like a wonderful app with lots of potential! A few things would really make it shine:
- Scipy (with scipy.io, specifically netcdf)
- some sort of geographic plotting, e.g. basemap
I also haven't actually checked this, maybe it is already there: but matplotlib stylesheet support would be nice