Widget sizes in the Toga browser example

[Tzu-ping Chung]

Hi,

I encountered this problem when trying to run the browser example with toga-qt. The constraints in the top (control) row of the main window are basically like this (in VFL for visualisation):

|-5-[url_input]-5-[go_button]-5-|

Running this yields two possible results (occur randomly):

1. The button displays normally, while the URL input is long and fills the remaining width.
2. The URL input is only long enough to hold the content, while the button stretches to fill the remaining width.

Looking at the constraints, both seem to be logical, so maybe that’s way Cassowary randomly picks one of the two. And I think this would result in an ambiguous layout in Xcode, although I have to admit I don’t really understand the algorithm and am only speaking from experiences working with native OS X and iOS apps.

But is this the intended behaviour? Should the users (of the lib) be responsible to add extra constraints to get what they intend (if so, how?), or should the lib developer add more hints in certain widgets to make them behave better? Both toga-cocoa and toga-gtk seems to ”work” under this example, but neither of them seem to contain anything special in this regard.

Thanks.

--

Tzu-ping Chung (@uranusjr)

https://uranusjr.com

[Russell Keith-Magee]

Hi Tzu-ping,

Your analysis is pretty much dead on - the two constraints solutions are both mathematically legitimate, assuming there's no other constraints. 

The catch is that AFAICT, there *are* other constraints under Cocoa that aren't publicly advertised. At the very least, there's an enforced minimum size on some widgets (e.g., text inputs); I suspect there's also some internal preferencing of expansion (e.g., text labels expand rather than buttons). It's these extra constraints that make the system non-ambiguous.

Constraints of this style *can* be implemented using pure Cassowary constraints... as long as you know what they are. Under GTK, I've added a couple of constraints to the widgets themselves in an attempt to get them right. However, I'm not convinced that I've got them all correct - there are a couple of edge cases where GTK doesn't behave quite right. 

So - unfortunately, I don't have an easy answer here. There is a mailing list for the Cassowary algorithm:

https://groups.google.com/group/overconstrained

and the list seems to be have some readers with inside (or at least, very well informed) knowledge of the internals of Apple's Cassowary implementation. I've been intending to post there to see if I can get some of my blanks filled in.

Yours,

Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Beeware Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beeware-develop...@googlegroups.com.
To post to this group, send email to beeware-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/beeware-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/beeware-developers/0d988eb4-3f60-43b9-a8fe-1c0e45a2c1eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tzu-ping Chung]

Thanks for the response! So I guess the lib should handle those extra constraints under the hood automatically, and make it “just work” for users. I’ll study at the GTK implementation and try to figure it out. Will also take a look at the overconstrained mailing list. :D

Cheers, 

--
Tzu-ping Chung (@uranusjr)
https://uranusjr.com

To view this discussion on the web visit https://groups.google.com/d/msgid/beeware-developers/CAJxq84-HjL6UeG86ikicuM9DStoMjg9c3U9xuWviEJJjazc2bQ%40mail.gmail.com.

[Russell Keith-Magee]

Hi Tzu-ping,

That's the theory, yes. *What* those constraints are is the question. Any help you can provide in this regard will be gratefully accepted.

Russ %-)