Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toga: A Python native, OS native GUI toolkit

pybee.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Toga: A Python native, OS native GUI toolkit

#51

Post by freakboy3742 »

daurnimator wrote: post #11
calpaterson wrote: post #6

The use of constraints to let the user specify where to put things but still allow enough flexibility to do OS-dependant things is interesting (and possibly novel?): http://toga.readthedocs.org/en/latest/introduction/tutorial-...

Cassowary ( http://constraints.cs.washington.edu/cassowary/ ) is used by Apple for this.

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.

Re: Toga: A Python native, OS native GUI toolkit

#52

Post by rkangel »

rjn945 wrote: post #34

I was really confused when I read "the constrain() call takes expressions that define the relationships you want to impose" (emphasis mine) and saw this code: container.constrain(button.TOP == container.TOP + 50) Python doesn't let you pass expressions! Why isn't that just getting evaluated to true or false? Is this not vanilla Python? Is there a pre-processor? I dove into the code and found the answer here[1]. butto…

I am very conflicted about that trick. On the one hand it is a neat bit of syntax to express what you want, but it goes completely against your expectations of how Python syntax is parsed. 'Clever use of operator overloading' historically has always meant 'confusing use of operator overloading' - something the C++ community took some time to learn.

Python is very good at behaving as you expect it to, despite the fact that you can implement pretty much any magic. This is down to library design more than it is language design.

Re: Toga: A Python native, OS native GUI toolkit

#53

Post by rkangel »

For a project like this where there are many other potential options (wxPython etc.) the first question I'm thinking is 'why do I care about this new one'. I.e. What does this do better/differently/more conveniently. I assume the answer here us the native Python aspect and not needing big compiled libraries. Might be worth selling it a bit more on your homepage and making that advantage clearer?

It may be that everyone else picked up on Python native quicker than I did, I'm reading this in bed during a lie in so am a bit sleepy!

Re: Toga: A Python native, OS native GUI toolkit

#54

Post by freakboy3742 »

rkangel wrote: post #53

For a project like this where there are many other potential options (wxPython etc.) the first question I'm thinking is 'why do I care about this new one'. I.e. What does this do better/differently/more conveniently. I assume the answer here us the native Python aspect and not needing big compiled libraries. Might be worth selling it a bit more on your homepage and making that advantage clearer? It may be that everyo…

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)

Re: Toga: A Python native, OS native GUI toolkit

#55

Post by TheLoneWolfling »

rkangel wrote: post #52
rjn945 wrote: post #34

I was really confused when I read "the constrain() call takes expressions that define the relationships you want to impose" (emphasis mine) and saw this code: container.constrain(button.TOP == container.TOP + 50) Python doesn't let you pass expressions! Why isn't that just getting evaluated to true or false? Is this not vanilla Python? Is there a pre-processor? I dove into the code and found the answer here[1]. butto…

I am very conflicted about that trick. On the one hand it is a neat bit of syntax to express what you want, but it goes completely against your expectations of how Python syntax is parsed. 'Clever use of operator overloading' historically has always meant 'confusing use of operator overloading' - something the C++ community took some time to learn. Python is very good at behaving as you expect it to, despite the fact…

At least it's less magic than puLP:

  prob += x*2 + y, "foo"
This sets the objective function of prob to (2x+y), and assigns it a name of "foo".

  prob += x*2 + y > 3, "abcd"
That puts a constraint that 2x + y > 3, called "abcd".

On both of these the string is optional.

I'm also conflicted. On one hand, it's about the most compact syntax you can get for something like this - when similar libraries in languages without operator overloading resort to passing strings into functions... On the other hand, it can be utterly incomprehensible if you haven't gone through the documentation.

Re: Toga: A Python native, OS native GUI toolkit

#56

Post by ZenoArrow »

freakboy3742 wrote: post #39
ZenoArrow wrote: post #24

Earlier quoted context omitted.

Maybe I'm missing something, but isn't the main 'hook' for this library that it looks native? Looks like it uses GTK+, so from a technical standpoint it would be as "native" as Qt.

Project author here; let me confirm that Toga only uses GTK+ under Ubuntu/Linux. On OS/X, it uses Cocoa. I've just clarified the text in that section of the website. Thanks for the heads up.

Thank you for the clarification.

Re: Toga: A Python native, OS native GUI toolkit

#57

Post by _random_ »

freakboy3742 wrote: post #54
rkangel wrote: post #53

For a project like this where there are many other potential options (wxPython etc.) the first question I'm thinking is 'why do I care about this new one'. I.e. What does this do better/differently/more conveniently. I assume the answer here us the native Python aspect and not needing big compiled libraries. Might be worth selling it a bit more on your homepage and making that advantage clearer? It may be that everyo…

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…

"Python native" is an oxymoron, given the language's interpreted nature. "Python-idiomatic" would probably be a more correct choice of words. But that's just me.

Re: Toga: A Python native, OS native GUI toolkit

#58

Post by andreasvc »

_random_ wrote: post #57
freakboy3742 wrote: post #54

Earlier quoted context omitted.

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…

"Python native" is an oxymoron, given the language's interpreted nature. "Python-idiomatic" would probably be a more correct choice of words. But that's just me.

I think that is typically called "pythonic".

Re: Toga: A Python native, OS native GUI toolkit

#60

Post by andreasvc »

WoodenChair wrote: post #19

This project appears to be quite early stage (many missing APIs, no stable Windows support, poor documentation, etc) but very promising. If it had integration with a GUI designer and was feature complete, I'd start using it on projects. I've explored the options for Python GUI toolkits quite extensively. They're a real challenge to get running conveniently (by conveniently, I mean a simple PIP install away with no ex…

"No external C/C++ library dependencies" is simply impossible. Given that the host OS is not implemented in Python, some kind of bridge to its native libraries is necessary for a GUI library. Such libraries can be either compiled during the pip installation, or required as an external dependency installed using the package manager of the OS, Either way it's never going to be hassle free due to all the different OSes and package managers.
Post reply on HN