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.
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
Not sure if this thread is still being checked, but for me, split screen multitasking is a must. I use and ipad pro and with my screen real estate it's awesome to be able to have half me screen dedicated to the code I'm writing and half dedicated to a webpage or PDF that I'm reading from. I probably won't be using pythonista much until such a feature is implemented and instead will have to use coda to SSH into my home computer instead.
@mason Please see:
Forum search is helpful in this case.
@omz has good reasons not to implement it, but there are a multitude of good workarounds. I do think that this will eventually have to come to Pythonista, but enabling split-screen in iOS as it is right now would mean that locking the rotation would be completely impossible in any part of the app, which is fairly essential to the
@Webmaster4o Thanks, that's too bad.
@mason Don't give up hope! WWDC is just around the corner, and perhaps Apple will make some changes/additions to the SDKs that would handle split screen stuff automatically (for example if you're app initiates full screen mode it becomes undocked and goes full screen.)
import locale locale.setlocale(locale.LC_ALL, 'fr_FR')
I think it would be great, if v.present('sheet') could have a factor param. And if the factor == 1.0 or more it is full screen on the device.
Long winded example below
It's not so evident why this is good. But often you have the chicken an egg syndrome with 'sheet' and 'full_screen'. For me it's very difficult to handle these cases elegantly. I can do it, just it does not feel right.
Maybe I am dreaming, but I don't think so. So hard to explain. But if no comments then i know I am being stupid again.
# coding: utf-8 import ui class AnyCustomClass(ui.View): def __init__(self, *args , **kwargs): ui.View.__init__(self, *args, **kwargs) if __name__ == '__main__': _factor = .50 f = (0,0, ui.get_screen_size() * _factor, ui.get_screen_size() * _factor ) v = ui.View(frame = f, bg_color = 'green') acc = AnyCustomClass(frame = (f)) v.add_subview(acc) v.present('sheet')```
v.present("sheet")on an iPhone is already the same as
v.present("fullscreen"). Though that might be different on iPhone 6+ and such. Or are you writing something that fits in a panel on an iPad Pro, but not on normal iPads?
@dgelessus , I just think the below is convenient. Could be improved upon I am sure. I think the .present() is pretty important in the scheme of things.
I realize the below is not compelling, but would be nice to have more built into ui.View.present() I think
import ui class SomeCustomClass(ui.View): def __init__(self, *args, **kwargs): ui.View.__init__(self, *args, **kwargs) def show(self, modal = True, factor = 1.0, *args, **kwargs): m_bar = 0 if kwargs.get('hide_title_bar', None): if kwargs['hide_title_bar']: m_bar = 44 if factor <= 1.0 and factor > 0: f = (0,0, ui.get_screen_size() * factor , (ui.get_screen_size()-m_bar) * factor) self.frame = f self.present(*args, **kwargs) if modal: self.wait_modal() if __name__ == '__main__': scc = SomeCustomClass(bg_color = 'white') scc.show(modal = True , style = 'sheet', factor = .5) print 'fell through...'