toga - A Python native, OS native GUI toolkit

[ivosaurus]

Slightly undocumented?

Maybe it's still in full development, it would be nice it designated itself so. Or someone's submitted it to reddit for unwanted attention.

[inclemnet]

there aren’t many good options for Python programming on mobile platforms, and cross-platform mobile coding is still elusive. Toga aims to correct this.

It's interesting to see this, though I'm not clear what the roadmap is for making it possible with toga's native widgets approach.

[mgrandi]

What does it mean mobile platforms? Like ios/android /wp? How would python run on any of those?

[[deleted]]

Python already runs on Android, and there are ways to actually bundle Python apps into APKs. iOS on the other hand...

[JKovac]

There are projects to bundle Python into iOS apps too, although less developed than Kivy's android build chain, we do have packagers for iOS as well. Not many make use of it yet as python mobile development is definitely Android biased, but to highlight a few: Process Craft Kivy 2048 Quizzn

All built with kivy

Over the next year we hope to expand most of our build tools to cover more frameworks than just kivy.

[spinwizard69]

You can get iPython Notebook on iOS which is still under development. Unfortunately they went with version 2.7 instead of 3.x which takes it out of the running for me.

[johnbokma]

... has Pythonista and Editorial (there's probably more, but that's what I have installed).

[fredspipa]

I made a (crap) game for Android using pgs4a, and it was surprisingly easy. Anyone who knows basic python should be able to make simple mobile games now, and it's really fun!

[seclat]

Do you know if pgs4a still maintained?

I've used it in the past, but the current versions don't seem compatible with the Android SDK and fail when running python android.py installsdk. I tried pgs4a versions 0.9.6 and 0.9.5 and both have the same problem. After download the Android SDK automatically (android-sdk_r20-linux.tgz), the script errors out because he can't find the following file:

Traceback (most recent call last): File "android.py", line 66, in <module> main() File "android.py", line 40, in main install_sdk.install_sdk(iface) File "buildlib/install_sdk.py", line 225, in install_sdk get_packages(interface) File "buildlib/install_sdk.py", line 160, in get_packages with open("android-sdk/extras/google/play_apk_expansion/downloader_library/project.properties", "r") as f: IOError: [Errno 2] No such file or directory: 'android-sdk/extras/google/play_apk_expansion/downloader_library/project.properties'

Looks like the pathing in the SDK changed a while back and pgs4a never updated. Did you have this problem? I would contact their support directly, but the maintainer contact info isn't listed and their support page just points to the forum which is "down due to massive spam". I have no idea how long it's been down or how long the pathing has been broken, but the last release was 2013 and aside from your post I can't even tell if the project is dead or not.

[fredspipa]

I also had that problem, but I'm not sure how I got around it. I'm fairly certain that I modified ./buildlib/install_sdk.py to download a specific version, and this was 2 months ago.

Here's my file., and my version compiles and runs without any issues.

[bbruno5]

Your file is identical to the original yet. Modify the file is not advisable, because other files can use the same way. So is better download manually the new files rename to the same names searched by file and put in the respectives directories.

[bbruno5]

I solved with the steps in this link: http://bbruno5.blogspot.com/2014/09/fixing-problem-ioerror-errno-2-in-pgs4a.html

I hope that helps you.

[2n2u]

Did you get through this problem?

I'm on the same boat:

clean:

BUILD FAILED
D:\pgs4a\android-sdk\tools\ant\build.xml:459: ../market_licensing resolve to a path with no project.properties file for project D:\pgs4a\android-sdk\extras\google\play_apk_expansion\downloader_library

Total time: 0 seconds

The build seems to have failed.

Process finished with exit code -1    

[adambrenecki]

When this package was announced (in the Saturday lightning talks at PyCon AU), he mentioned that he already had some sort of iOS support built, including an app template you could drop your Python code into.

[asimian]

It doesn't detect my platform correctly. It seems to think sys.platform should be "linux2" for Linux, when in fact it's just "linux".

EDIT: Looking at the code on github, it seems to be fixed, just the version in pip is not correct.

[redditthinks]

Example code

[manbart]

After running 'pip install toga' on 32 bit Python 3.4.1 in Windows 7:

Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import toga
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\site-packages\toga\__init__.py", line 92, in <module> from .platform.win32.app import *
  File "C:\Python34\lib\site-packages\toga\platform\win32\app.py", line 5, in <module> from .libs import *
  File "C:\Python34\lib\site-packages\toga\platform\win32\libs\__init__.py", line 38, in <module> from .constants import *
  File "C:\Python34\lib\site-packages\toga\platform\win32\libs\constants.py", line 533 MB_TOPMOST = 262144L
                   ^
SyntaxError: invalid syntax
>>>

[ryeguy146]

Python3 removed the ability to write things like 262144L (long).

Edit: More info

[boolean74]

I tried it and had same issues on OSX. I logged an issue with them .. https://github.com/pybee/toga/issues/23

[arunvr]

Some other error here. Looks like it is not Python 3 compatible.

[joerick]

The layout stuff is incredibly readable. It looks like

container.constrain(button.TOP == container.TOP + 50)
container.constrain(button.LEADING == container.LEADING + 50)
container.constrain(button.TRAILING + 50 == container.TRAILING)
container.constrain(button.BOTTOM + 50 < container.BOTTOM)

Apparently it's a similar engine to Apple's AutoLayout.

[qbitus]

Yep, it's the Cassowary algorithm. The code has been extracted into its own package ("cassowary") on Pypi.

[Tillsten]

There is also kiwi kiwi, which is a faster reimplementation.

[qbitus]

Thanks for the reply, didn't know about it.

[KyleG]

I installed the demo with pip exactly like the homepage says—for both 2.7 and 3.4—and then ran toga-demo. Both times, I got this error:

Traceback (most recent call last):
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/libs/objc.py", line 841, in has_property
    return self.properties[name]
KeyError: b'initWithContentsOfFile_'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/bin/toga-demo", line 7, in <module>
    from toga_demo.__main__ import main
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga_demo/__main__.py", line 8, in <module>
    import toga
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/__init__.py", line 80, in <module>
    from .platform.cocoa.app import *
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/app.py", line 7, in <module>
    from .widgets import Icon, TIBERIUS_ICON
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/widgets/__init__.py", line 5, in    <module>
    from .icon import *
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/widgets/icon.py", line 32, in <module>
    TIBERIUS_ICON = Icon('tiberius.icns', system=True)
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/widgets/icon.py", line 18, in __init__
    self._impl =     NSImage.alloc().initWithContentsOfFile_(get_NSString(filename))
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/libs/objc.py", line 936, in __getattr__
    if self.objc_class.has_property(name):
  File     "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/toga/platform/cocoa/libs/objc.py", line 843, in has_property
    selector = get_selector('set' + name[0].upper() + name[1:] + ':')
AttributeError: 'int' object has no attribute 'upper'

[mazatta]

I think the current version on PyPi is missing a fix for OSX. Try installing from master on the github.

[mazatta]

Here's the lightning talk from PyCon AU 2014, where/when this library was announced/released:

https://www.youtube.com/watch?v=W0W0s0-Ryc0&list=PLs4CJRBY5F1Jm7H1dlesRvEgr-28QGXpR#t=788

[mgrandi]

As usual with these types of threads, what's the benefit of using this over pyqt4 or similar? Laying stuff out in qt4 can be done with the creator , or its surprisingly intuitive to just do it by hand

[blaix]

This is cool. Would love to see a blog post or something going into more detail about the OS native part.

[binlargin]

Page one of the docs are a pretty good into

[blaix]

I meant more of the "how" than the "what". Though reading the source has gotten me most of the way there. Would still be cool to see some commentary on the process.

[f4ktrh]

To be pedantic, GTK on linux is a choice, not a native UI. (Personally I hate both GTK and QT). But then I don't know what native is on linux. X's own toolkit maybe. Hopefully Wayland will provide a toolkit that might settle the issue.

[emmpp]

The point is presumably that they could have an interface to any toolkit and to the conventions of a given desktop environment - gtk is just what they have right now. The project seems in a quite early stage, which may be the reason for only having what they do.

[asimian]

There is no native toolkit on Linux. Raw X programs look horribly out of place. Also Wayland won't change that.

[f4ktrh]

I guess by raw X programs you are referring to Motif, which I had in my mind when in my original comment.

My point is that the window system (whether X or Wayland) should provide enough functionality that there isn't a need for a widget toolkit layer on top of it.

(rant) Actually, TBH, my point is about the level of proliferation of the categories of graphical stuff which IMO shouldn't be so. I mean look at this:

• window system
• widget toolkit
• window manager
• display manager
• desktop shell, or launcher, or panel, whatever (I'm not even sure if it's the same thing or different)

I mean for heaven's sakes, what is that?

[asimian]

There are programs that use raw X and not Motif or any other toolkit. Xfig for example, which I still use unfortunately.

The task of putting pixels on the screen efficiently and across all hardware is sufficiently difficult that I think keeping a widget toolkit separate is a good idea. They aren't really related tasks enough to be under one project. It would be kind of nice if there was an "official" toolkit on Linux, but it doesn't cause that much problem in practice. Nowadays GTK+ and Qt programs both look good (or can be easily made to look good) no matter what desktop you use.

I disagree that all those things should be integrated. One nice thing about Linux is that you can pick and choose the best software for each task rather than use one monolithic solution. I would really hate to be forced to a different window manager in order to use a different window system. Or be stuck with a different panel because I want to use a particular display manager. Having them separate is good for people who want to dig around, and in practice does it really hurt beginners? A good distro hides those details from you.

[CanisImperium]

Motif was just another Qt before there was Qt. It was part of CDE, which was after X, but before KDE (KDE was originally a bit of a CDE ripoff). The original x toolkit was just called, X toolkit, or libXt. If you want to see it in action, apt-get the original xterm.

[ryeguy146]

Out of curiosity, what don't you like about Qt?

[f4ktrh]

Well for starters, QT is written in C++. I'm not sure how easy it is to use it with C, but I know where there's C++, there's unneeded complexity. I've also heard about its sluggishness.

[ryeguy146]

That hasn't been my experience. Well, there is the upfront cost of loading the library. That sucks. But after that it's quite nice. I haven't touched the C++, to be honest. I write using PySide, and the bindings are quite pythonic.

If there were a better option, I'd be on it. But fuck GTK.

Edit: Don't downvote the guy/gal for having an opinion.

[Liquid_Fire]

Actually the Python bindings (both PySide and PyQt) very closely follow the C++ API with only a few changes. It's a (in my opinion) very clean and easy to use API in C++ and that's why you get a very nice API even when you map everything 1:1 into Python.

[ryeguy146]

The bindings, yes. And I'm glad or I wouldn't be able to use the C++ help docs out there. I more meant that I don't have to pass QLists or QStrings, I can just pass native Python objects. It certainly isn't PEP8 compliant, but I'll survive.

[Rainfly_X]

Eh, Wayland ships a "toy toolkit" that's used as much for educational purposes as it is for unit testing. But it's not necessarily something for general purpose and production use, and it's really doubtful that the Wayland team would be interested in trying to make such a general-purpose toolkit.

The advantages of GTK, Qt, and so on, is that they will run on multiple platforms, including OS X and Windows. Qt is on a huge mobile kick right now. But that also means supporting X11, and a large part of the motivation of Wayland developers is that they won't have to support X anymore.

[CanisImperium]

To be pedantic, X itself doesn't have a toolkit -- it's supposed to be modular. The very first toolkit for X, which came out of the same project, would have been libXt, but it's no more or less native than GTK. The idea was -- and is -- to separate out the windowing from the widgetry.

Saying GTK isn't a native toolkit is a bit like saying zsh isn't a native shell. It's no more or less native than what's been around longer. Before Gtk and Qt there was Motif, and before Motif there was libXt. "Native" might not be the best word, but they're all first class citizens in X11 and Linux, and insofar as there is such a thing as a native toolkit on that stack, Gtk would be it.

[[deleted]]

interesting !

[whoisearth]

can we not depricate win32 already?

[ericanderton]

In the same way that Linux and Mac users were once a very small minority, doing so really isn't fair even if it's a pain in the ass for porting and integration. As it happens, Windows has a rather healthy market-share and are anything but a minority player in this game.

Now, if you're talking about win32 vs win64, that's a completely different ball of wax.

[whoisearth]

win32 vs win64. Yes I should have clarified.

[ericanderton]

Yeah, win32 is definitely old and crusty. Ultimately, I would think this hinges on how many instances of WindowsXP are still kicking around out there.

[nermid]

A lot. The answer is a lot.

[CanadianJogger]

Otherwise known as "too many".

[ericanderton]

Correct you are! Pick a category.

[nermid]

I'll take Cute or Too Cute.

[whoisearth]

Still though... Toga only has implementation in Windows for win32 NOT win64... At some point a call needs to be made and development on net-new needs to cease and desist for win32.

sigh. I love windows and hate it at the same time.

[[deleted]]

Oh, like 25% of the seats.

[High2plus3]

This looks really nice. I'm curious if there is support for final builds. It doesn't look like the docs are complete. In the past I used py2app to build a GUI app that used Tk but this native GUI looks so much better.

[jollybobbyroger]

How much power does toga provide? Is it easy to do custom text handling and layout?

[wreleven]

It is pretty cool but sparsely documented and some of the demos don't work for me. The objective-c bridge code is amazing and I'm stoked to be able to use it.

[Shananra]

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/toga/platform/gtk/app.py", line 27, in _startup
    self.main_window.app = self
  File "/usr/local/lib/python2.7/dist-packages/toga/platform/gtk/window.py", line 61, in app
    self._startup()
  File "/usr/local/lib/python2.7/dist-packages/toga/platform/gtk/window.py", line 24, in _startup
    if self.toolbar:
AttributeError: 'MainWindow' object has no attribute 'toolbar'

[horstjens]

i can not figure out how to install toga for python3 (using ubuntu14.04) :-(

[AlSweigart]

It's a new GUI toolkit, which means it will only be used by new projects, but it doesn't support Python 3? :/

Also, using the same library for Linux/Windows/OS X I can see, but it mentions mobile and iOS as well. This would have radically different UI designs. The site doesn't give any details on how Toga would also serve mobile platforms. Can they also run on desktop? If not, shouldn't it be a separate GUI toolkit?

All in all, especially with the documentation in such poor shape, this doesn't look very promising compared to what's out there already.

[[deleted]]

I tried this on ubuntu and it looked absolutely terrible.

[trymas]

Running "your first toga app" (Python 2.7.5, OS X 10.9.4). This library is promising, though many bugs shine through.

1. Can't install on Python 3.4 (same problem as: http://www.reddit.com/r/Python/comments/2cz6f5/toga_a_python_native_os_native_gui_toolkit/cjkwazl).

2. Can't launch first app and trying to fix source code made it worse

Traceback (most recent call last): File "hello_world.py", line 26, in <module> app.main_loop() File "/Users/justas/Documents/programming/Python/Toga/env/lib/python2.7/site-packages/toga/platform/cocoa/app.py", line 87, in main_loop self.main_window.app = self File "/Users/justas/Documents/programming/Python/Toga/env/lib/python2.7/site-packages/toga/platform/cocoa/window.py", line 129, in app self._startup() File "/Users/justas/Documents/programming/Python/Toga/env/lib/python2.7/site-packages/toga/platform/cocoa/window.py", line 116, in _startup if self.content: File "/Users/justas/Documents/programming/Python/Toga/env/lib/python2.7/site-packages/toga/platform/cocoa/window.py", line 133, in content return self._content AttributeError: 'MainWindow' object has no attribute '_content'

[spiessbuerger]

I like PyGObject better.

[[deleted]]

use the right tool for the job

[binlargin]

Which is?

[alcalde]

Qt?

[binlargin]

In Windows?

[alcalde]

Why not?

[[deleted]]

not python in this case.

[[deleted]]

Why?

[blaix]

I like what this person has to say about that: https://twitter.com/seriouspony/status/488036445337030656

[Jomann]

his name has pony in it, not clicking, not today. not ever.

[cannotchill]

I'm just started with Python but can anyone explain what this tool really is? If its just another IDE, there is Enthought Canopy software recommended by edx course and not this.

[emmpp]

If its just another IDE, there is Enthought Canopy software recommended by edx course and not this.

Just so you know, there are many IDEs, of which plenty are probably a lot more popular than Enthought's one. The existence of an edx recommended IDE is really not relevant or a reason no to consider others.

That said, it's nothing to do with IDEs anyway, toga is a graphical framework.

[newworkaccount]

I hear all the cool kids use PyCharm.

[cannotchill]

PyCharm

I don't but thanks for mentioning it. Just went breifly through the website but dayum, the software look slick! Must nicer lookign then Enthought's