Refactor: new ideas welcome

[boydm]

I'm starting to take a good look at Scenic and am planning some fairly major work for it. If you have suggestions and/or requests, this is a good time to make them known. The next update will have breaking changes in it...

I need a bit more time to crystalize my opinions, but I already know I want to dramatically change the interface between the Viewport and Drivers. Will be much simpler.

There will be some breaking changes up at the Scene level. For example, Sectors and arcs should be defined by just a radius and angle instead of radius, start_angle, end_angle. The start/end angles is really just expressing a rotation, which can be done with a rotate transform.

Also going to deprecate the Path primitive and replace it with something more directly related to the new Viewport/Driver interface. Still working on the details.

So... If any of you have strong opinions or wish some parts were different, the next month or two is the time to suggest them. The next release will definitely have breaking changes in it.

Here is another change I'm considering that I'd like feedback on.

Some of the primitives (Line, Triangle, Quad) explicitly specify the positions of all their points. But other Primitives (Rectangle, RoundedRectangle, Circle, etc...) Draw from the origin and then rely on transforms to move them to their final position.

I'm thinking of changing Line, Triangle, and Quad to work more like the others. This would make the API more consistent. For example, Line would then just take a single x, y pair and draw a line from 0, 0 to the specified position. You would then use :translate to move it to the correct position.

Thoughts/Objections?

[crertel]

I like the idea; if I'm parsing it correctly, you're saying that Line, etc. will all be in local coordinate systems (that is, assuming (0,0) as the origin), and then devs will use transforms to move them around as needed?

[boydm]

@crertel Correct. Some of the primitives work that way now. Some don't. Feels inconsistent.

[crertel]

Can we spam other wishlist items here too?

[boydm]

Sure. No promises that they get in though. Once things stabilize (won't be right away) I'll update main and can take PRs...

[boydm]

Hmm. I should probably release the current main as a minor update.

[crertel]

Things I'd personally like (some of this may be redundant now):

• Better spec/docs for how drivers work...ideally, a reference driver that just spams to logs with what's getting tripped and when, and then we could fork it to do more interesting things
• Proper support for image tiling/rotations/etc. ( Feature request: Add support for image fill sampling and scaling #120 )
• Better docs around input events; it'd be great if we had both a list of all common events (ideally, including touch and gamepads and more exotic input devices) as well as an explanation for how drivers can implement custom input events
• Can we use Record instead of maps for styling? Would that get us better help from Dialyzer?
• Mix generator for creating new component boilerplate (mix scenic.gen.component)
• Mix generator for creating new scenes (mix scenic.gen.scene)

That's all I've got at this hour, but I'm sure I'll think of something. I'm happy to help contribute patches--the mix generators for example look like easy low-hanging fruit.

[crertel]

Oh, also, some kind of events related to resizing of the viewport. Useful for various things.

[Eiji7]

Firstly I would like to ask how we plan to organize code in future for new features?

#77 and #127 are good examples here …

On one side we don't know what to do for new features like gamepad and on the other side textarea component issue was created nearly 2 years ago!

I believe we need to:

1. Declare what we want to have in core
2. Properly document best practices extending scenic - from trivial library naming up to design decisions (documentation for writing input drivers)
3. Create something like: https://github.com/kormie/awesome_scenic, but with our core projects + for asking for maintainers

Personally I would be interested in truncating scenic core project. The core needs to focus on most important things (like fixing bugs, speed improvements etc.). Just truncating core gives a preview of our priorities. I think that we can for example move all components code (of course except lib/scenic/component.ex) into separate library.

Later from a basic component library we may create a phoenix-like framework for writing business apps with support for notifications, sounds, themes etc. Let's call it xyz and related libraries would be:

1. xyz_graph (something like phoenix_html) for example:
   Xyz.Graph.Dialog.ColorChooser
Xyz.Graph.Form.Button
2. xyz_live_dashboard
3. xyz_live_view
4. xyz_integrations_windows_xp - for OS-specific integrations or
5. xyz_notifications - notifications for all OS
   Xyz.Notifications.Custom
Xyz.Notifications.KDE4
Xyz.Notifications.WindowsXP
   etc.

If components-based library would quickly grow it may even give scenic core a huge input - from bug reports up to some benchmarks.

[crertel]

I'm a bit against truncating/keeping stuff out of Scenic. It's kind of annoying and discouraging to be told repeatedly "that would be a great Scenic addon!"...and the ecosystem of extra Scenic plugins unfortunately hasn't happened.

If we become so overburdened with features and development, we can always split them out later.

This would also greatly simplify setting up CI/CD and other things to make basic quality and compatibility guarantees (and I'm happy to take a stab at getting this moved over to Github Actions or some similar CI

I very much agree that we probably want to make best practices documented and maybe some kind of umbrella org to hold on to all of the Scenic stuff--or at least, some project portal webpage.

[boydm]

@Eiji7 really good suggestions. I could use some help getting it organized.

Some more things...

I'm going to move Scenic and it's associated libs into a dedicated organization.

Secnic.Sensor will be renamed/refactored into Scenic.PubSub, which is a better description of what it does. - This is a good candidate to move into Scenic core

Some new components can go into scenic, but I still want to keep larger components out. If they are good enough, then can go into the org.

[Eiji7]

@crertel I'm a bit against truncating/keeping stuff out of Scenic. It's kind of annoying and discouraging to be told repeatedly "that would be a great Scenic addon!"...and the ecosystem of extra Scenic plugins unfortunately hasn't happened.

That's how we came back to previous question (i.e. why scenic was not adopted so much) and there are few things:

1. Slow development (see issues with 2+ years)
2. Lack of documentation
3. Bugs

Without 3rd point people would look at source code for inspiration. Without 2nd point people would quickly fix bugs. Without point 1 people would use scenic in production causing creating many new components. Honestly? Go on and document whole scenic and I can take not even textarea - I can even write a full markdown editor with preview.

Right now when I take a look at Scenic.Component.Input.TextField I see for example handle_input usage. I think: good, now let's check from where it comes (import or use). The only one is use Scenic.Component, has_children: true call and within it I need to search for use Scenic.Scene, unquote(opts) and finally I found it's usage in Scenic.Scene. The documentation of it does not gives an examples of handling keyboard events.

It's nothing surprising that adoption of scenic does not goes easy … It's like with Linux - if big companies would not use it in production then they would not support it and therefore I would not write this comment. 😈

[BWheatie]

Agreed that a mix task for Scenes/Components would be really great.

Big thing for me is developer experience. Would like a full debugger. I started down this trail but it was.... tough... Have some ideas but mostly need a super lightweight debugger to help make sense of the current graph, maybe a grid to help align objects, find hidden/untranslated prims. Like I said, started working through this but think maybe a dedicated driver would be better than a full included Scenic app.

In the layout work I ran into some issues with font metrics. Ultimately if you are using a custom font, getting those font metrics over to a separate lib is... not fun. Could have been missing something but it was not the dev experience I was hoping for users of the lib.

Aside from these things, overall we need some blogs. I have been wanting to write some for a while but just never got around to it.

@crertel reminded me of another: expanding input events or some docs on how to do this.

[crertel]

I'll open up a PR for those generators I mentioned and see if we can get the ball rolling.

@boydm :

Some new components can go into scenic, but I still want to keep larger components out. If they are good enough, then can go into the org.

Maybe we should just have a single scenic_components library that gets all components, and then remove components from core Scenic entirely?

I don't understand the reasoning behind "hey, let's keep adding barriers to entry to offering components". As I mentioned above, the problem Scenic has is not that it's drowning in weird deprecated components...it's that there is not a happy-path to adding components.

I'll also note that getting new developers to add a component to core Scenic (or to the scenic_components library mentioned above would be a great onboarding path to get other contributors and maintainers.

[crertel]

Opened up that PR here if folks want to sanity check my approach before I finish it off.

[boydm]

Upudates:

I'm going to leave the line,triangle,quad primitives alone. Explicit points make sense.

Does anybody use the :font_blur style? Can you give an example? There are other ways to achieve that effect that might be more generic...

[boydm]

@Eiji7 Do you have a twitter name or something I can use to get a hold of you directly? I'd love do a chat on a call... send me a message there so we can start a DM conversation

[boydm]

Some updates.

This is going to be a fairly large piece of work. I am going to restructure the driver mechanism. I've started writing up a doc on in... I'm trying to keep impacts to the Scene level minimal, but there will be some.

One of the breaking changes I'm thinking of making is to the scene_ref primitive. The current version attempts to do multiple jobs at the same time. Overall, I'm trying to simplify things, so am thinking of breaking into several new primitives. One would be :component, which as it implies connects to genserver scenes running components. Another would be :script, which would be a compile graph that is ready to be drawn. (more on that in a bit).

There has always been this sub-id field for graphs, which was a hack to allow a scene to support multiple graphs at the same time. The :script primitive would eliminate the need for that and make it more clear how you manage static portions of your graph.

[Eiji7]

@Eiji7 Do you have a twitter name or something I can use to get a hold of you directly? I'd love do a chat on a call... send me a message there so we can start a DM conversation

@boydm Looks like you don't allow DM on Twitter. 😈

You can send DM to me on (sorted by preferences):

1. forum: https://elixirforum.com/u/eiji
2. https://elixir-lang.slack.com: https://app.slack.com/client/T03EPRA2X/D64JKPQ1L
3. e-mail: [email protected]
4. twitter: https://twitter.com/ElixirEiji

[boydm]

@Eiji7 Yeah. Sorry my DM's aren't open on Twitter. I have to follow you back. I was in the video game industry for a long time, which doesn't necessarily lead to well mannered conversations from people I don't know.

[boydm]

I'm at that point where I've torn out the old driver model, but putting it all back together is really daunting. At least this shouldn't have the crash-and-launch-new-drivers-forever problem.

[grahamhay]

Boyd, I would be interested in your draft document "I've started writing up a doc on in..." . I am trying to get my head around the proposed new structure of the parts and their connections from the snippets of comments and posts etc.

[boydm]

@grahamhay. The doc is up here: https://github.com/boydm/scenic/wiki/February-2021-Big-Scenic-Update---RFC

[grahamhay]

Boyd, Excellent. Many thanks. Graham

…

On 15 February 2021 at 20:53 Boyd Multerer ***@***.***> wrote: @grahamhay https://github.com/grahamhay . The doc is up here: https://github.com/boydm/scenic/wiki/February-2021-Big-Scenic-Update---RFC — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub #207 (comment) , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMSCL7G7OF2JIVWIXWCZTS7DHHTANCNFSM4W56VP3Q .

[rm-rf-etc]

Will support for window resize be coming? I understand the explanation given here, so if it's not currently on the list of priorities, could you maybe share some details that contributors could follow for features like this?

[nyaray]

Unless I'm late to the party and if we're requesting API breaking things, it would be nice to have the argument order in group_spec be changed so that the one in my (merged) PR is the new default. It would make code nicer by default, as shown in my PR examples.

I'd be willing to comb through the codebase to make the change in a PR between a suitable pair of branches if this would be considered within the scope of the Upcoming Major Refactor of Doom™ :)

[boydm]

Hi @nyarray. You are not too late to the party.

What changes need to be made where? Take a look at the v0.11 branch. That is where it would go, although it might be easier to do after I merge it as a PR into main but before it gets published to hex.

I'm doing a docs pass now, which is causing a few more ripples through the code. (Something about explaining what you've done helps you see a few more improvements).

[pcarvsilva]

I don't know if it's too late, but perhaps using a Entity Component System approach would be a good idea. Instead of Button being a Component, Button Should be a ScenicEntity that has a ImageDrawerComponent a ClickableBehaviourComponent and so on ... Game Engines use this kind of strategy and it's really a big advantage into creating whole new pipeline for other behaviors. Collision detection for example could be another application and dependency on your project outside scenic which adds the CollisionBodyComponent and checks for collisions running the scene.

[boydm]

@pcarvsilva Yeah. Too late for the current update. I'm trying to push it out the door.

This is something I'd like to learn more about tho. Ping me in November and lets discuss.

[boydm]

v0.11.0-beta.0 is published to hex
I'll close this when the RC goes out.

[crertel]

Closing, we're up to 0.11.2 now!