There is a talk for ElixirConf US this fall that is announcing Scenic. I can’t find anything anywhere about this framework. I am very interested in it. Has anyone heard of this? know where the Git repository is if this is open source?
Might be what @boydm is working on as ongoing effort after: https://www.youtube.com/watch?v=77FW-jrCyCs
7 Likes
It’s likely a maturation from https://youtu.be/77FW-jrCyCs?list=PLqj39LCvnOWZMVugtyKlHMF1o2zPNntFL from last year.
2 Likes
Ah! that makes a lot of sense. I was in that talk last year. It is exciting stuff!
2 Likes
Yes indeed! I will be talking about Scenic, which is what I was talking about at the last Elixir Conf (hadn’t named it yet).
I’ve been coding like crazy on this for the past year and it is really starting to take shape. Everything works great on a Mac, I’m finishing up the Raspberry via Nerves now and then a bunch of cleanup work over the summer. Should be up on Mac, Linux, Window, Raspberry 3/0 and more by the time the conferences comes around.
If anyone has questions about it in the mean time, feel free to reach out. I’ve been hesitant to give access until I feel confident the apis have stopped fluctuating wildly. I think I’m there. So it will be out in the wild soonish.
Whew. I’m looking forward to talking opening about it instead of just being heads down coding.
42 Likes
@boydm Scenic does sound very exciting, but as someone who’s been following (and sometimes contributing to) FOSS projects for more than 20 years, your “heads down coding” approach raises a red flag.
If you are unable to work in the open now, how can the community know whether you’ll be open to contributions later? Even if you are open to contributions, every day your code base evolves under wraps, the barrier to contributors becomes higher.
If that’s going on for more than a year, it’s a huge red flag. Please take this as constructive criticism. I’d love to see you succeed in launching and leading a sustainable, Open Source project.
It just occurred to me: maybe it’s not intended to be Open Source?
2 Likes
Huge red flag? Nonsense. Elixir itself took a long time to see the light of day. Plenty of projects do.
5 Likes
Discourse (the open source software that powers this forum) was in development behind closed doors for a year before it made it’s debut too - now it’s one of the best forum platforms out there.
I’m sure @boydm has a vision and perhaps he doesn’t want that diluted or complicated just yet. I am the same - if I have a vision for something I prefer to see it through, if it begins to get diluted or feels like a struggle (perhaps because others continually need convincing) I begin to lose heart.
When you lose heart, the passion starts to fade and things don’t turn out to be their best (imo). This is why I always encourage people to do what they feel is right and what their heart is in most - even if that’s their particular way of going about things.
I’m sure Scenic is going to be awesome 
7 Likes
Hey guys, totally get the debate. Asked myself the same question.
Some projects lend themselves to open from the start. Some don’t. In this case, I knew roughly what I wanted, but also knew that it would change significantly from the original designs as it progressed. (that definitely happened). The last thing I want is accreting inertia by having people write code on top of APIs that I need to feel free to change. Once an API is released to the wild it takes on a certain weight. There is an implied obligation to not jerk it around all the time.
So, I think it depends on the nature of the project. This one needed to incubate closed for a while. Or rather, with a close circle of other developers having access and giving feedback on it.
22 Likes
Came here to say the same thing. There is such a thing as launching too early because the second you launch anything, you immediately begin fielding questions, criticism, support, etc. All of that slows down your development efforts, especially if it becomes your job to communicate your vision to everybody while you build it.
Much, much easier to get it to the point that you are comfortable before releasing it. Every rough edge you polish first is a question you don’t have to answer.
Can’t wait to see it.
5 Likes
So excited to see this library in action, keep the good work up!
Just version it right as per semver, anything <1.0.0 is in-dev, any any 0.x.* change for x implies backwards incompatible, feel free to always move fast at this point, I do and don’t get any complaints, but the feedback is beyond invaluable! 
2 Likes
In theory this works great. In practice this results in lots of angry people opening issues on GitHub who don’t care that it’s 0.x. They’re just upset cause their production app is broken and they don’t want to do the work to fix it.
I totally support Boyd’s decision (although I can’t wait to see it)!
7 Likes
I’m probably going to first release it at something like 0.7, which will then be in the mode @OvermindDL1 suggests. @devonestes is totally right about the work so far though. Somebody would try to build something “real” on apis that I need to rearrange, rework, or whatever, and they would complain about the churn in the codebase.
I used to describe developing software projects as similar to making Jello. You’ve picked the flavor you want, but at first is all liquid and stirring around. Then it starts to harden, but is still mixable. Then it hardens more, generally keeps its shape, but bounces all over the place. Then the vibrations reduce until is is stable. Note that it never stops moving completely, it just gets very predictable.
To me, calling it 0.7 reflects that there is still room for feedback and possible breaking changes, but that the worst of the bouncing is in the past. Won’t call it 1.0 until it feels nice and presentable as a dessert or maybe in a nice fruit salad or some other analogy that is now past it’s original meaning.
11 Likes
To me, this means nothing, as versions have no upper bound. There is still a lot of room for breaking changes until you do the 0.99999 release, of which still a 0.100000 could follow while never reaching 1.0. No part of a version number stops at 9.
1 Like
You could use the Knuthian convention (who you recall used the successive digits of Pi to indicate versions) - you could use the digits of Phi (the golden ratio) - this would be appropriate for a graphics program.
Note that TeX is now at version 3.1415926 - Knuth thought that stability and having a version that worked in future exactly the same way as now was more important than introducing new features. He also offered a bounty of $2.56 for each reported error in TeX doubling for each new error.
The digits of Phi are here
https://www2.cs.arizona.edu/icon/oddsends/phi.htm
There are sufficient digits for many versions 
8 Likes
Or go with digits of 1/Phi while you still want to retain the ability to change the API significantly.
2 Likes
Boyd has done it! Open source as of this afternoon:
Congrats! So excited to see the start of a viable elixir-oriented GUI toolkit. Goodbye Qt!
Can’t wait to contribute some components and supporting libraries.
Some ideas for fun libraries:
- SVG renderer
- Code generation tool that ingests common UI design formats (Sketch, Figma, XD…)
- Grammar of Graphics style or D3-eque data viz primitives.
And of course all of the nitty gritty UI components, e.g. date pickers, scroll views, …
Woohoo!
21 Likes
Just finished watching the talk, super excited! I’m a little bit wondering about how Scenic ships, is it a release or a mix?
1 Like
