Live data from Hacker News

Stevia: Human-readable auto-layout in code

github.com

51–60 of 60 posts

Re: Stevia: Human-readable auto-layout in code

#51
post #10

Earlier quoted context omitted.

They do, but search and replace, diffing, and copy-paste of multiple elements and their constraints likely (I haven't used Xcode's editor much, certainly not recently) do not work as well as their equivalent in text. And of course, some people find markdown more user-friendly than a visual GUI for more or less the same reasons, so it should not be that surprising to find some people experiment with this. And of cours…

you can copy elements in interface builder, iirc. you can't copy their constraints, which makes sense because the copied instances necessarily have different constraints. otherwise the copies would just stack on top of each other. in my personal opinion, IB is great for layout of one view or screen, especially with the new IBDesignable and IBInspectable features. doing app navigation in a storyboard is a terrible ide…

couldn't agree more !

Re: Stevia: Human-readable auto-layout in code

#52
post #3

I find it strange that something akin to markdown-style syntax sugar is more user-friendly than a visual designer. Do the tools for developing a UI for iOS this way not include a WYSIWYG editor to set things such as contraints?

Using Interface builder is Great indeed it just has a ton of other issues down the road, this article sums it well : http://blog.teamtreehouse.com/why-i-dont-use-interface-build...

Re: Stevia: Human-readable auto-layout in code

#54
How do you approach adaptive layout with this? How easy is it to define a layout that can work on all devices and with different orientations? Are you able to specify size ratios between elements for example (one annoying thing missing from Apples visual format language)?

Re: Stevia: Human-readable auto-layout in code

#55
post #17

Since people are discussing Auto Layout alternatives, I'd recommend AsyncDisplayKit ( http://asyncdisplaykit.org/ ) – although it's a bit more advanced. Layout mimics CSS and Flexbox. It was originally built by Facebook and very actively maintained. You also get a number of other advantages, like moving UI operations off of the main thread (which is often a pain point in iOS apps shooting for 60fps).

AsyncDisplayKit is cool stuff, but I really wish it were possible to yank its layout and “doesn’t do layout on the main thread” parts and apply them to vanilla UIKit. It’s frustrating to run into the inevitable unsupported use cases, bugs, etc with alternative UI systems. UIKit has its quirks but it’s mature enough that coming up with a use case that it can’t serve in on way or another is difficult. It’ll be years be…

Doing asynch UI "by hand" might be easier than you think. Here's a table view example: https://github.com/pepaslabs/GlitchyTable

Re: Stevia: Human-readable auto-layout in code

#56
post #37

Looks like they've included their .DS_Store files within the git repository: https://github.com/s4cha/Stevia/tree/master/Stevia/Stevia Screenshot: http://imgur.com/5EPUNeZ

Can you elaborate on the consequences of doing that for the non-Mac users among us?

Re: Stevia: Human-readable auto-layout in code

#57
post #10

Earlier quoted context omitted.

They do, but search and replace, diffing, and copy-paste of multiple elements and their constraints likely (I haven't used Xcode's editor much, certainly not recently) do not work as well as their equivalent in text. And of course, some people find markdown more user-friendly than a visual GUI for more or less the same reasons, so it should not be that surprising to find some people experiment with this. And of cours…

you can copy elements in interface builder, iirc. you can't copy their constraints, which makes sense because the copied instances necessarily have different constraints. otherwise the copies would just stack on top of each other. in my personal opinion, IB is great for layout of one view or screen, especially with the new IBDesignable and IBInspectable features. doing app navigation in a storyboard is a terrible ide…

Was going to say something similar, that IB is great if you are doing one-off screens, but it isn't the best for creating reusable / composable UI elements.

Re: Stevia: Human-readable auto-layout in code

#59
post #20
post #18

Earlier quoted context omitted.

I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"

I mentioned it in my response to the other reply, but I've found that the average programmer's Google-fu is actually quite poor, and they would not do that subsequent narrowed search.

Doesn't matter anyway, Google nowadays just ignores some words if it feels like it. Even if you add quotes > then you're not guaranteed that the pages will have all the words in. Google need a "just show me the results I asked for" button.

Re: Stevia: Human-readable auto-layout in code

#60
post #18
post #13

It's not really on-topic, but why do people name their projects with names that are very difficult to find via search engine? I really don't understand this mindset.

I don't think this is actually an issue. You can always add context to searches -- rather than searching for just "stevia" you can search for "stevia iOS layout"

Sometimes you have to add the boolean nots.

PHP templates -"WordPress" -"joomla" -"codeignitor" -"drupal"

Post reply on HN