Suggestion: Stacky

[rorysmyth]

Have you thought about having the 'stacking' feature as it's own standalone plugin?

^ Would be an amazing plugin in it's own right. With all the amazing features you have in the full plugin, it brings with it instability. Just a simple, dumb stacking plugin would be so useful.

[aparajita]

Just a simple, dumb stacking plugin would be so useful

Yeah, he can call it DumbStack. 😄

The simple, dumb functionality of stacks works perfectly now with no instability (that I've encountered), and the padding functionality does not affect stacking behavior if you aren't using it.

But what about edge cases? Hidden layers? Symbols? Nested symbols? Isn't handling those useful? It isn't so easy to get all of that right.

[rorysmyth]

But what about edge cases? Hidden layers? Symbols? Nested symbols? Isn't handling those useful? It isn't so easy to get all of that right.

Totally. If its related to stacking it makes sense. Baffling it's not native in Sketch to be honest.

Haven't encountered any stacking bugs in the beta either. Which is fantastic. But you know how it goes. Each new Sketch release breaks something. Then that can break another. If all these features are dependant on something working, it could be hairy.

Been bitten by ambitious plugins like this in the past. Just a suggestion!

[kieranblack]

Yeah I agree! Splitting them up might be better for you in the long run. I teach some design students how to use Sketch on a regular basis and they have to install the behemoth of buggy features that is AutoLayout.

[DWilliames]

Really great points everyone! Sorry for the delay in chiming in here. @rorysmyth @kieranpblack @aparajita

I can see how splitting the plugin into 'Padding' & 'Stacking' may have it's merits; in the sense that it only does the one thing well; and in theory, would have less potential issues since it doesn't do as much...

However, I don't think that is necessarily the case:

• Duplicate code: Splitting them up means that they cannot share some similar boilerplate; which means there's shared code that would have to be maintained in two spots
• High cohesion: Padding and stacking is super intertwined in the layout management. e.g. Being able to handle Stacking, but ignoring Padding layers; and padding to take into account stacking
• Performance: A lot of the layout calculations are done for Padding and stacking at the same time; if they were split up, it would potentially double the calculation time – if the user has both plugins installed
• Stability: Because they are baked together and tested together as the one plugin, it makes it much easier to develop for it and make it more stable. As opposed to testing in the cases; Paddy only installed, Stacky only installed, Paddy & Stacky installed etc.

That's all I can think of off the top of my head.

I know people have been burned by Anima's AutoLayout; and I think that's for 2 main reasons:

1. Bloat: The plugin is massive – it includes Auto layout, animations, creating a website etc. Way too much 'bloat' that people don't want.
2. Business model: Their business model revolves around the paid features; 'Launchpad', 'Timeline' – so they invest all their time into those, rather than 'AutoLayout'.

I know a lot of people only use Anima's Toolkit plugin purely for Stack Groups – I hope to be able to build something that is stable and supported for those people.

In the end, I don't want to make Paddy any more than what it is — layout management for Padding and Stacking. So I shouldn't end up 'bloating' it like Anima have. Realistically; there's so much shared code for Padding and Stacking, that having Padding included with Stacking, doesn't add that much bloat.

Sorry for the long message. It was a really great question :)
I hope that all makes sense 👍

[kieranblack]

Really great to hear your thoughts on it and a perspective on how it is actually built. Keep up the great work!