State of GUI toolkits with PyPy?
Looking at rewriting a number of my older python2 scripts to python3 and was hoping in the mean time to also make all of them play nice with PyPy where possible. However a number of them use pyqt when I needed a GUI. From what I can find QT still does not play nice with PyPy yet, however are there any others? Has there been movement on GUI toolkits/libraries with CFFI/CTypes/cpyext support via pypy? The compatibility wiki has not really had those edited since sometime around early 2013... https://bitbucket.org/pypy/compatibility/wiki/Home Wondering is all before I try and see myself and spend a few days trying to build them with pypy.
Hi Eric There has been some success with WxPython, but I don't think anyone got pyqt running on PyPy. Cffi is one option with pymetabiosis being the other one worth considering. Also I have a bit no clue how much CPython C extensions your bindings/qt uses, but we have an emulation layer for those that should work as long as the extension plays nicely (will be dead slow though) Cheers, fijal On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd@gmail.com> wrote:
Use Electron + RapydScript on client side , along with bootstrap or Material Design Light . https://github.com/atsepkov/RapydScript And use PyPy on backend. you got everything done in python. On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
I have a preference against web-based UIs for things that are meant to exist/run just on my one machine. Especially since some of these are shorter-lived but "heavy" scripts (working with them for only a few minutes). So the short update that I can see is: * There is/was work with WxPython as a GSOC project, but that has been left to mostly stagnate. ( https://bitbucket.org/waedt/wxpython_cffi ) I was unable to reproduce any of the demos/tests easily, probably a bit too much time has passed for someone like me to be able to pick it up and carry on. Would need an amount of love first from someone knowledgeable to bring it forward and be develop-able again. * https://github.com/rguillebert/pymetabiosis (aka: use CPython for a GUI toolkit via embedding the interp into PyPy), although quite the nice workaround I feel that if you are going to have to fall back to CPython (and thus install all the modules required there) I might as well stay with CPython for these scripts * cffi: aka "the hard way", write hooks/wrappers into toolkit of choice myself. * Some form of web-based GUI (eg flask+bootstrap, RapydScript, and more): Although I like web-interfaces, they are not appropriate for every use case. Thick, heavy workloads bound to one computer do not integrate or scale easily with python-based webUI stuff from my experience. * https://github.com/lazka/pgi works wonderfully and will probably be what I use here on out. * https://bitbucket.org/dholth/pysdl2-cffi Bit more work to get started, but nice if you need some of the bells and whistles SDL2 brings (joystick inputs, easy-ish GL use) Thanks Ryan for pointing me to PGI, few examples I have run worked wonderfully so far for all the widgets I need. On Sat, Sep 19, 2015 at 1:32 AM, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:
There is also pygame-cffi, which is I guess slightly higher up than sdl (but not something *I* would personally use for a UI either) - https://github.com/CTPUG/pygame_cffi On Sat, Sep 19, 2015 at 7:32 PM, Eric Driggers <admalledd@gmail.com> wrote:
Hi Eric, Thanks for this list that summarizes the situation! It's information that we should put or link to from somewhere (the FAQ?). Maybe it should be put in the compatibility wiki, but that wiki looks really, really outdated now, to the point that fijal suggested that we might as well close it down. The experiment of crowd-sourcing this wiki has failed. Nowadays you can, more and more often, go to the other project's website or PyPI page and see a mention about the PyPy compatibility status there. But it doesn't help much when gathering a list of all GUI toolkits available (say). So I would say that we should clean up from our wiki all projects with "not working" or "unknown" status (go check yourself what that project's PyPI page says), and then update it to contain at least Eric's list in the "GUI" section. Does anyone feel like doing that? If not, we will close down the wiki and add the list to the FAQ with a date. A bientôt, Armin.
For the compatibility wiki, if nothing major changes this week I feel fine doing a large pass through it to try and update it. So long as you don't mind me in the meanwhile on IRC asking silly questions about some of them. I long ago found it to be a useful resource, and it still places high on search results making it in my opinion something worth trying to salvage it a bit. On Sun, Sep 20, 2015 at 12:27 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Maciej, On Sun, Sep 20, 2015 at 6:08 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
I don't think this is true Laura, it shows up a lot in google searches
I don't think you can argue against Laura's "most people I meet simply don't know that it is there", which is in all likelihood a truth about the people that Laura meets. However what you said is also true: it does show up in various searches like "pypy gui". I think we can only conclude that there are many people that don't have the idea of using google to do the same searches as we do. A bientôt, Armin.
On 09/20/2015 09:27 AM Armin Rigo wrote:
1) If you ask me, the most important place to have up to date top level info presenting pypy as you'd like it presented, with references to further info is: https://en.wikipedia.org/wiki/PyPy 2) The other thing I'd like to see is less dead links. Maybe someone could see if pypy can run https://pypi.python.org/pypi/LinkChecker and set up a cron job to pester the page maintainers? ;-) (disclaimer: have not looked at LinkChecker, but seems appropriate) (might have to tweak it to detect dead wiki links though, since they produce an invitation to create a new page, not a 404 -- but you'd think wiki software would come with a tool for this ?) 3) IMO most wiki searchers will just be looking for info, and will not be able or not have the time to contribute, but if they could run a script that generated useful info about the compatibility of pypy to their platform/software context in the form of a report that could be pasted as the body of an email and sent for automatic processing (modulo spam control ;-/), and which contained an an html section to extend a compatibility table, then maybe crowd sourcing would work a little better? The qubes-os.org project does this to generate a table of hardware compatibility to help people identify CPUs and chipsets that can run their os with full or partial success. Their hardware compatibility page is table is https://www.qubes-os.org/hcl/ they explain how to contribute new data here: https://www.qubes-os.org/doc/HCL/ Maybe something analogous could be done for pypy compatibility? 4) BTW, they seem to be using cpython2.7 a lot, and I'm sure speedup would be good ;-) It's an interesting project. Security by compartmentalization, using xen and fedora, with others coming. Just thought I'd throw something into the idea pot ;-) Regards, Bengt Richter (lurking mostly, off doing other things ;-)
I'd advise you to try PGI (https://github.com/lazka/pgi). It's a set of PyPy-compatible Gtk+ 3 bindings that's mostly compatible with PyGObject. They're not complete, but I've used them before, and they work quite well. On September 18, 2015 12:53:18 AM CDT, Eric Driggers <admalledd@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
Hi Eric There has been some success with WxPython, but I don't think anyone got pyqt running on PyPy. Cffi is one option with pymetabiosis being the other one worth considering. Also I have a bit no clue how much CPython C extensions your bindings/qt uses, but we have an emulation layer for those that should work as long as the extension plays nicely (will be dead slow though) Cheers, fijal On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd@gmail.com> wrote:
Use Electron + RapydScript on client side , along with bootstrap or Material Design Light . https://github.com/atsepkov/RapydScript And use PyPy on backend. you got everything done in python. On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
I have a preference against web-based UIs for things that are meant to exist/run just on my one machine. Especially since some of these are shorter-lived but "heavy" scripts (working with them for only a few minutes). So the short update that I can see is: * There is/was work with WxPython as a GSOC project, but that has been left to mostly stagnate. ( https://bitbucket.org/waedt/wxpython_cffi ) I was unable to reproduce any of the demos/tests easily, probably a bit too much time has passed for someone like me to be able to pick it up and carry on. Would need an amount of love first from someone knowledgeable to bring it forward and be develop-able again. * https://github.com/rguillebert/pymetabiosis (aka: use CPython for a GUI toolkit via embedding the interp into PyPy), although quite the nice workaround I feel that if you are going to have to fall back to CPython (and thus install all the modules required there) I might as well stay with CPython for these scripts * cffi: aka "the hard way", write hooks/wrappers into toolkit of choice myself. * Some form of web-based GUI (eg flask+bootstrap, RapydScript, and more): Although I like web-interfaces, they are not appropriate for every use case. Thick, heavy workloads bound to one computer do not integrate or scale easily with python-based webUI stuff from my experience. * https://github.com/lazka/pgi works wonderfully and will probably be what I use here on out. * https://bitbucket.org/dholth/pysdl2-cffi Bit more work to get started, but nice if you need some of the bells and whistles SDL2 brings (joystick inputs, easy-ish GL use) Thanks Ryan for pointing me to PGI, few examples I have run worked wonderfully so far for all the widgets I need. On Sat, Sep 19, 2015 at 1:32 AM, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:
There is also pygame-cffi, which is I guess slightly higher up than sdl (but not something *I* would personally use for a UI either) - https://github.com/CTPUG/pygame_cffi On Sat, Sep 19, 2015 at 7:32 PM, Eric Driggers <admalledd@gmail.com> wrote:
Hi Eric, Thanks for this list that summarizes the situation! It's information that we should put or link to from somewhere (the FAQ?). Maybe it should be put in the compatibility wiki, but that wiki looks really, really outdated now, to the point that fijal suggested that we might as well close it down. The experiment of crowd-sourcing this wiki has failed. Nowadays you can, more and more often, go to the other project's website or PyPI page and see a mention about the PyPy compatibility status there. But it doesn't help much when gathering a list of all GUI toolkits available (say). So I would say that we should clean up from our wiki all projects with "not working" or "unknown" status (go check yourself what that project's PyPI page says), and then update it to contain at least Eric's list in the "GUI" section. Does anyone feel like doing that? If not, we will close down the wiki and add the list to the FAQ with a date. A bientôt, Armin.
For the compatibility wiki, if nothing major changes this week I feel fine doing a large pass through it to try and update it. So long as you don't mind me in the meanwhile on IRC asking silly questions about some of them. I long ago found it to be a useful resource, and it still places high on search results making it in my opinion something worth trying to salvage it a bit. On Sun, Sep 20, 2015 at 12:27 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Maciej, On Sun, Sep 20, 2015 at 6:08 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
I don't think this is true Laura, it shows up a lot in google searches
I don't think you can argue against Laura's "most people I meet simply don't know that it is there", which is in all likelihood a truth about the people that Laura meets. However what you said is also true: it does show up in various searches like "pypy gui". I think we can only conclude that there are many people that don't have the idea of using google to do the same searches as we do. A bientôt, Armin.
On 09/20/2015 09:27 AM Armin Rigo wrote:
1) If you ask me, the most important place to have up to date top level info presenting pypy as you'd like it presented, with references to further info is: https://en.wikipedia.org/wiki/PyPy 2) The other thing I'd like to see is less dead links. Maybe someone could see if pypy can run https://pypi.python.org/pypi/LinkChecker and set up a cron job to pester the page maintainers? ;-) (disclaimer: have not looked at LinkChecker, but seems appropriate) (might have to tweak it to detect dead wiki links though, since they produce an invitation to create a new page, not a 404 -- but you'd think wiki software would come with a tool for this ?) 3) IMO most wiki searchers will just be looking for info, and will not be able or not have the time to contribute, but if they could run a script that generated useful info about the compatibility of pypy to their platform/software context in the form of a report that could be pasted as the body of an email and sent for automatic processing (modulo spam control ;-/), and which contained an an html section to extend a compatibility table, then maybe crowd sourcing would work a little better? The qubes-os.org project does this to generate a table of hardware compatibility to help people identify CPUs and chipsets that can run their os with full or partial success. Their hardware compatibility page is table is https://www.qubes-os.org/hcl/ they explain how to contribute new data here: https://www.qubes-os.org/doc/HCL/ Maybe something analogous could be done for pypy compatibility? 4) BTW, they seem to be using cpython2.7 a lot, and I'm sure speedup would be good ;-) It's an interesting project. Security by compartmentalization, using xen and fedora, with others coming. Just thought I'd throw something into the idea pot ;-) Regards, Bengt Richter (lurking mostly, off doing other things ;-)
I'd advise you to try PGI (https://github.com/lazka/pgi). It's a set of PyPy-compatible Gtk+ 3 bindings that's mostly compatible with PyGObject. They're not complete, but I've used them before, and they work quite well. On September 18, 2015 12:53:18 AM CDT, Eric Driggers <admalledd@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
participants (8)
-
Armin Rigo -
Bengt Richter -
Carl Friedrich Bolz -
Eric Driggers -
Laura Creighton -
Maciej Fijalkowski -
Phyo Arkar -
Ryan Gonzalez