allw ppl to make there own styles

[gintama91]

Description

what do u guys think abt smthng like this?

shoes dont have this ig but this adds far more flexibility to user imho , in a scenario where we didnt implemented smthng like color for paragraph, user can still do tht by using this ig n tht would be cooooool

Image(if needed, helps for a faster review)

Checklist

• Run tests locally
• Run linter(check for linter errors)

[noahgibbs]

The difficulty here is that it adds something that's not Shoes-compatible, that requires one specific display server (those are CSS properties) and that we haven't marked as Scarpe- or HTML-specific.

It would be fine to have specific Scarpe extensions to Shoes, but then we should figure out how to mark that. Dot-scarpe file extension? Some property that we think will be ignored by Shoes3 and Shoes4? Scarpe-dot-app instead of Shoes-dot-app?

I do not think we should write a bunch of Scarpe-only example apps that aren't marked as such, particularly if they won't work if we switch to a non-HTML-based display server.

[gintama91]

makes sense, closing this.

[Schwad]

If you don't mind I'll add a comment though. Because I think this really touches on a big, big area that is going to require more discussion and thought at some point if not soon!

@noahgibbs thinking from API backwards

what about something like, and I really think we need to come up with a whimsical alternative term to "extensions", but

Shoes.app(title: "My funky shoes app!", extensions: ["Scarpelicious-WebView"]) do
  @note = para "Let's keep things funky in this app. Funk only!"
  @note.change_style(.....)
end

Extensions could also bundle other extensions. Think like all the treats in Ruby-facets back in the day!

Or if there was a way to be like, not an argument but:

include Scarpelicious::Webview
include SchwadStyle::Bootstrap::Webview

......

@_why was cool with people writing their own widgets. So I think we might be able to find a way to honor the author's intent, with extra functionality. But I think we should definitely keep these sorts of things isolated and consistent. And if we want it we should write a few examples to prove out the concept. E.g. I'm happy to do my bootstrap webview concept.

Perhaps any changes to DSL I have to inherit from either a display service widget and make their changes? And we wait until someone wants a multi-display-service extension to explore that?

class Scarpelicious::Webivew::Button < WebviewButton
  def my_new_cool_method
    style(height: 1000px, color: mahogany)
  end
end

I act like it's an experimental thought but I could see myself getting itchy to throw bootstrap support for webview before end of year if we're still hacking lol. But I'd want it to nearly be a separate gem altogether!

[noahgibbs]

I'm not opposed to us having some kind of extensions. The problem with the :extensions option to Shoes.app is that it almost works in other Shoes implementations -- and may not even raise an error -- but it's not clear to a casual reader that what you're looking at isn't a portable Shoes app. That's one reason I suggest a .scarpe extension or Scarpe.app instead of Shoes.app. They still don't work in other Shoes, but at least it's really obvious why not.

So we need to figure out if we want graceful degradation -- do we make it so that other Shoes impls would (probably, usually) run these as normal Shoes apps? That would be harder, but is possible. Or do we want explosive degradation, where there's a big "no, this is Scarpe-only" error? That'd be fine too.

What I do not want is unmarked Scarpe-only apps that fail in other Shoes implementations with a weird error and it's not clear why.

It's also possible to have modules/includes and widgets that are Shoes-portable. But that's not really what we're talking about here (I think I'll be able to add support when I fix the "self" thing.)

[Schwad]

Okay that makes sense and I appreciate the discusison.

@gintama91 sorry to be back and forth on this but what I'd like to do is leave this closed for now but I want to keep this branch/pr/discussion around for thinking after the hackdays. Is that okay?

I could see pressure for extensions going forward, and even if they're written by third-parties, I'd like for us to have an answer for people.

Thank you for prompting this thread!

[gintama91]

@gintama91 sorry to be back and forth on this but what I'd like to do is leave this closed for now but I want to keep this branch/pr/discussion around for thinking after the hackdays. Is that okay?

Yes.