freakboy3742
Joined 16 years ago
Karma
173
Submissions
40
Member since
Jun 22
Recent submissions
Comment · 9 years ago
The full standard library is a work in progress; at the moment, there's only a couple of key parts of sys, os, and the like. But Ouroboros (https://github.com/pybee/ouroboros) is a project to develop a full standard library that can be integrated into any Python implementation. Effectively, you can use all the bits of the standard library that are written in Python by just compiling them; the rest requires native integration (which is the work in progress).
Comment · 9 years ago
Good news on the generator front - VOC fully supports generators, lambdas, passing functions as arguments, and all sorts of things that Python allows but Java (the language) doesn't.
As for a guide to calling Java from Python - we don't have any good documentation for this (yet), but it's entirely possible. Here's a sample Android application. If you're familiar with the Android APIs, you should be able to see the syntax conventions in place. https://gist.github.com/freakboy3742/7beb22c587e57240610777a...
Comment · 9 years ago
If you want a smaller target, VOC (http://pybee.org/voc) can generate a "Hello World" APK in about 1.6MB.
VOC is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.
If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA
(Full disclosure - I'm the primary author of these tools)
Comment · 9 years ago
AFAIK, Plyer will give you access to native APIs like accelerometers, but not to the native GUI layer.
An alternative approach is VOC (http://pybee.org/voc) - this is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.
If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA
(Full disclosure - I'm the primary author of these tools)
Comment · 9 years ago
The primary difficulty is that JNI is really limited on Android. It exists, but it's really slow, and there are some hard limits imposed at the kernel level.
An alternative approach is VOC (http://pybee.org/voc) - this is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.
If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA
(Full disclosure - I'm the primary author of these tools)
Comment · 12 years ago
Erm... RTD does none of those things. There's a default site theme that is specific to RTD - they don't try to impersonate anyone. They don't "lift" anything unless the project owner has opened an account and requested that their documentation be hosted on RTD.
I'm at a complete loss how you've even come to the impression that RTD does the things you claim it does - because it does nothing of the sort.
Comment · 12 years ago
Why you put Read The Docs in the same category? RTD doesn't host anything unless you specifically set up an account and say you want to use them. They don't troll the web looking for projects, and hosting their docs whether they want them to or not.
Comment · 12 years ago
The Fellow's immediate reporting chain is to a subcommittee of the DSF. Effectively, they're "working" for the DSF (although as a contractor, not as an employee); that committee is responsible for working out if they're doing what they're supposed to do, whether the DSF is getting good value for money, and so on.
The technical board is there to provide decisions on technical issues, whether they come from the Fellows or from the general population. I'd be very surprised if the Fellows didn't regularly identify issues that needed the technical board to render a decision, but the technical board doesn't have any specific control over the fellow.
Comment · 12 years ago
Thanks for the feedback! I cover some of the "why" in the docs, but I agree the homepage could do a better job of making the case for a new UI toolkit.
The short version:
* System native widgets, not themes
* Installable via "pip install" - no third party or binary dependencies
* Not just naïve wrappers around widgets - capture the underlying use case and provide an API wrapper.
* Genuinely Python native. This means exploiting language specific features (like generators and context managers)
Comment · 12 years ago
FYI, Toga uses Cassowary as well - natively through Apple's implementation on OSX and iOS, and via a Python implementation of the algorithm (http://pybee.org/cassowary/) for GTK and Windows.
Comment · 12 years ago
Spotify's UI is many things, but it doesn't even begin to appear system native.