by i_am_ralpht on 1/13/15, 5:11 PM with 12 comments
by thomasfoster96 on 1/14/15, 6:04 AM
Only this morning I was thinking of how to implement a few of these types of interactions for a web app I'm developing - I actually might adapt some of the source code for my uses (assuming that's allowed under the License?).
If you're still working on a syntax for this, maybe you'll want to have a look at uilang or uiscript (both on Github) or Grid Style Sheets (http://gridstylesheets.org/).
by panic on 1/14/15, 1:47 AM
That said, this paragraph struck me as a great illustration of why I tend to prefer procedural layout systems to declarative ones, at least in production code:
Also note that there's slip! If you drag from the middle of the box, you'll see that the part of the image you grabbed slips out from under your finger. That's because the manipulator is just operating on the box's y coordinate. If we wanted to avoid slip then we'd have to create a new variable when the finger goes down, relate it to y (that is, fingery = box.y - 123 times scale, based on the current scale and finger start position) and then manipulate fingery instead of box.y. This isn't very hard, but the current manipulator code doesn't support it.
There will always be some situation the layout system's designer didn't predict. With procedural layout, you can write the procedure yourself. With declarative or constraint-based layout, you're stuck, since there's no way to express your special case in the limited language provided. Declarative systems are great for demos or rough prototypes, but when you want full control, there's no substitute for the power of procedural code, IMO.
by kabes on 1/22/15, 10:03 PM
by forrestthewoods on 1/14/15, 6:20 AM
by ux-app on 1/14/15, 12:58 AM
I've been meaning to get my head around cassowary for a while now. I think your project is the motivation I need to get to it :)
by jamieomatthews on 1/13/15, 9:49 PM
by thoughtpalette on 1/13/15, 9:23 PM