Scene Editor in Craft not updating Scene; also WYSIWYG and serialization

[gedw99]

Might be user training :)

The way the Scene can be changed at runtime is not fully worked out ?
Some values do update and some dont.

Above the Text of the Menu can be changed but will not update for example.

I get the feeling its not full baked as they say yet ?

[kkoreilly]

Yes, Cogent Craft is still under development and we will improve support for the scene editor when we work on it next.

[kkoreilly]

@gedw99 Yes, you can save and load the GUI using JSON. We also have generatehtml functionality and htmlcore for reading from HTML. The main issue with those approaches is they can't really save styling and event closures, but there are some ways to work around that, potentially using the yaegi interpreter. We are planning to make an interactive GUI editor at some point (cogentcore/core#1277); you can also see cogentcore/core#995 for more relevant discussion.

[gedw99]

Thanks @kkoreilly

ok this is highly encouraging. Yes I have seen those 2 links. I asked because I wanted to check how far you had gotten an if you wanted a fully serialisabme gui . Seems you do .

have you seen Datastar and hyper?

https://github.com/starfederation/datastar/tree/develop Is browser based

https://hyperview.org/docs/reference_doc is react native based

They both describe the signals in the xml using the htmx approach.

imho this is how you build a wysiwyg with full ability to change the gui at runtime because the gui and signals are all self describing in the xml itself.

cogent has all the rendering complexity working , but need a way to save and load the gui . The htmx approach has really proven itself , unlike the deadly xaml that died through layers and layers of abstractions.

I use deck in a htmx way to make it interactive . Its just replacing xml on the fly in the htmx way and letting the rendering engine render the partial and blip merge it into the frame.

https://github.com/ajstarks/decksh

the thing I am still working out with cogent is where the state on the client is saved and what is best . I noticed that when I refresh the browser , it remembers where it was both in route and scroll position . This is highly encouraging . Htmx systems hold this in the querystring ( or other data exchange pattern) so that a refresh gives the backend everything it needs to fully recreate what you have currently.

[kkoreilly]

@gedw99 Thank you for your suggestions. Our general thinking is that it is better to represent things with Go code than other formats like those you linked (see our principles). As such, our plan for the WYSIWYG editor is to make it dynamically edit the actual code of the app you are making, so the Go code is the serialization format. That Go code can be run using yaegi, so it would be a completely interactive editor.

Doing that would allow us to bypass one of the main issues with WYSIWYG editors, which is that they often result in unsustainable code that can't be developed into a fully featured app. If we make it produce Go code, then you can always use the WYSIWYG editor for simple things and then edit the code directly when you need custom features.

Therefore, I think we are unlikely to want to pursue an interactive XML/HTML approach like the ones you suggested. However, if our Go code approach doesn't end up working, we could look into the options you have suggested again.

[gedw99]

Thanks for your thoughts.

i think it’s a good option.

This what I currently do to accomodate the schema evolution aspects. Might be useful for cogent.

1. restart a project later. Hence the go code would need to be saved on the users hard disk ( or server ) for next time.

2. versioning overtime. The editor could look up the version of the go code ( against the version of the editor ) , so that the right editor can be loaded to match the version of the code . One of the big advantages of WASM. Not every user will want to upgrade to the latest version of the editor.

I run the editor as WASM on browsers , desktop and mobile to take advantage of this versioning ability.

3. Migrations. A migration script is still needed in the editor , which uses the built in patching feature. This allows the go code to be “ upgraded “ to match the editor version , if the user so chooses to upgrade.

This other important aspect is collaboration in real time. I designed around having the code be in the client and server ( or hard disk of user if using desktop version ) at both times , with a simple sync bidirectionally. This allows real time collaboration of the code .

[kkoreilly]

@gedw99 Thank you for your response. We will consider these issues further in the context of cogentcore/core#1277 and cogentcore/core#995, and after we experiment with things then, we will get back to you.