Live data from Hacker News

Vector based UI design tool that generates ObjC

paintcodeapp.com

51–60 of 82 posts

Re: Vector based UI design tool that generates ObjC

#52
post #7

Earlier quoted context omitted.

Think 'Save As NSView Code' for Illustrator.

Your PDF is going to be resolution independent and end up being used in much the same way as the code, so I'm to sure it's a significant difference. I do like the automated color derivation though.

Add a parameter or two to the generated code, then you'll see the difference,

Re: Vector based UI design tool that generates ObjC

#53
post #47
post #46

Earlier quoted context omitted.

It's how Apple has commoditized mobile apps and is now trying the same on the desktop.

Not sure what you are accusing Apple of ... This developer does have a choice you know. He could have made a trial available on his own site. Apple does not disallow that.

Choice is a funny word.

When all the customers are going to the supermarket to buy their fresh veg, you can set up your own puny little stall in the alley, but guess what, no one's buying because they can't even find you.

Apple does not allow you to sell iOS apps outside its app store, and there's every reason to believe they are pushing the desktop market in the same direction. Why wouldn't they?

Re: Vector based UI design tool that generates ObjC

#54
I made an open source project last year called Mockdown that does the opposite of PaintCode. It takes declarative design code and converts it to PNGs so they can be used in iOS apps. The original idea was to do mockups but it actually turned out to be more interesting as an open source design tool.

Here's a short 5 minute walkthrough in designing the Mail app in Mockdown:

http://vimeo.com/23869680

Re: Vector based UI design tool that generates ObjC

#56
post #43

You could just create you assets in Illustrator/Vector and you would be set for any future resolution increases. However the PNGs would still increase your bundle size. What I'm curious about, maybe someone here has the answer is if there would be a significant performance gain from using Core Graphics over just loading a PNG?

On the Apple developer web site you can watch the WWDC videos, there is one on graphics and animation that talks about just that.

Conventional wisdom, especially for small images, it is much more efficient to draw them with Core Graphics than use a image, more so if there is transparency in the image.

This will even be true for non-ios systems. Microsoft has said for years, that generating a 16x16 image is faster than getting it from disk (depending on complexity and disk speeds).

Plus, code does tend to be more compact (again, within reason), so it is less that has to be loaded when your application starts.

Re: Vector based UI design tool that generates ObjC

#57
post #9

I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…

What about localization? That combined with what others have mentioned below adds up to a lot of imagery.

There's also no reason you can't build your images the first time they're used, and save them out to PNG files for successive uses (if profiling determines that it is indeed more optimal). Even if you end up using graphics at runtime, you'll save work by using code to generate your graphics.

For instance, simply write utility programs to generate all of your graphics with code -- this is definitely faster than photoshop when you have buttons in lots of different languages. It's also useful if you want to use a font where it's not legal to embed it. (You can generate all of your button imagery using code and localization files, then remove the embedded fonts and use the generated PNG files in the release version.)

Re: Vector based UI design tool that generates ObjC

#58
post #57
post #9

I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…

What about localization? That combined with what others have mentioned below adds up to a lot of imagery. There's also no reason you can't build your images the first time they're used, and save them out to PNG files for successive uses (if profiling determines that it is indeed more optimal). Even if you end up using graphics at runtime, you'll save work by using code to generate your graphics. For instance, simply…

Sure, I've written tools to do this before - for localisation, nonetheless.

Re: Vector based UI design tool that generates ObjC

#60
post #9

I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…

Using something like the Apple-provided CGLayer, you can draw the image once, then use it like a bitmap while it is in memory, AND they can keep it cached on the graphics card. These guys could easily produce code that does that. Reference: https://developer.apple.com/library/mac/#documentation/graph... (it works on iOS too)

In practice, CGLayer is not some pixie dust that magically makes your drawing fast. It helps only in a specific instance: when you are drawing repeated instances of the same content, into the same context. Otherwise, it ends up being extra complication for no benefit.

(Note that CGLayer is not related to CALayer or CGTransparencyLayer -- they are absolutely separate things. CALayers are incredibly useful in practice; CGLayer was kind of a dead end.)

Post reply on HN