Vinay Gaba

@mxalbert1996 Actually thinking a bit more, I think we don't need this change. Instead, use the following setup with Showkase (I'll also add this to the README) - ```gradle debugImplementation...

@mxalbert1996 Yes that's actually how we are using it. This is actually a really full proof way to ensure that your previews are not being referenced by any piece of...

@mxalbert1996 no I meant purely having the Showkase root class that's annotated with `@ShowkaseRoot` along with the activity that references `Showkase.getBrowserIntent(context)` in the debug source set. The preview functions themselves...

@mxalbert1996 end user doesn't require it but Showkase needs it internally to add support for @Preview annotations. Anyway I've suggested what you should be using and what we use internally....

@mxalbert1996 It's here - https://github.com/airbnb/Showkase/blob/master/showkase-processor/src/main/java/com/airbnb/android/showkase/processor/ShowkaseProcessor.kt#L412

@mxalbert1996 I have it mixed up and I stand corrected 😱 The dependency I was suggesting (`ui-tooling-preview`) is needed in the `showkase-processor` (and is currently missing there) and can be...

@mxalbert1996 This actually rings a bell. I think that's the reason the dependency didn't live in the processor already. > However the current way of specifying the fully-qualified name of...

Since these are properties of the `@Preview` annotation itself, I'm open to adding them to `@ShowkaseComposable` and/or honoring what's passed as part of `@Preview`. For prioritization sake, I'm curious to...

Showkase exposes all your previews that it collects through the Showkase.getMetadata() function (more info here - https://github.com/airbnb/Showkase#5-showkase-object). Using this metadata object, it would be trivial to create your own browser...

Trying to figure out what the right solution here should be. I feel like even if I were to inherit Material, it would still break if you were using a...