Will defyne focus on GUI file deserialization, or completely an IDE

[ghost]

Feature request

Separate GUI file transpiler out from IDE.

Description

I just try out defyne and its GUI editor, it's great. But I can't find a way to make *.gui.json into a go file. Anyway, will defyne expose the transpiler (maybe just the function) or separate it into another module (function only or cli app). So that I can do something like...

w := app.New().NewWindow("Application")
w.SetContent(defyne.DecodeJSON("MainWindow.gui.json"))
w.ShowAndRun()

or

$> defyne compile
# MainWindow.gui.json --> MainWindow.gui.go

I am new to fyne but glad that someone bringing GUI to golang. Thank you for working on fyne and defyne.

[andydotxyz]

Good question. We could add "defyne compile" or "defyne build" as part of this project. However I doubt that we will add ".gui.json" support into Fyne because doing so does not allow you compile time type checking of the GUI widgets.

[ghost]

Perhaps a simple solution, JSON schema.

Besides, there is a very personal opinion and quite opposite to your hard work, I prefer to build an extension on other dev env, like Goland or vscode, instead of putting effort into building tailored IDE.

Simple reason, build IDE is hard enough, useful and user friendly IDE is more difficult. Perhaps spending more time on static checks or schema design would be worth more...

Forgive my inconsiderate, if there are many more concerns that take you to build defyne IDE.

[andydotxyz]

There are plans for VSCode integration, there are a few things we need to line up first because they use very different technologies.

I'm not sure what a schema definition would facilitate, do you have any specific ideas? Like I said Fyne won't be supporting reading this in directly.

[ghost]

I am up to here. still some problem with the definition of Container.Objects...

[andydotxyz]

I don't understand your message, what is the benefit of writing a schema for an application private storage file? The definition of the JSON is in the Go code that generates it currently.

[ghost]

Like I working on WPF in Visual Studio, most of the time I don't use the designer, but type the XML directly. JSON schema makes me have a choice to work without IDE, like using XML definitions on WPF.

Just a suggestion and a sample.

Besides, working on code can spot come components with no size, e.g. container in a container, I can't click on the inner container (which could be solved with a component tree on the side).

[andydotxyz]

Oh I see. The JSON file is not an API of any sort. It will evolve until a 1.0 release of defyne is ready - I would not recommend writing any tooling around how that file works at this time.

We do need a component tree (I think that is a separate issue) but zero size (or other fields) in Fyne is not a worry - we use the Go approach of sensible zero values for all fields.

[prifre]

The keyboard for terminal is incorrect somehow – I use Swedish keyboard and cannot enter backslash, ÅÄÖ, etc.

I would prefer a ”log” of what is happening instead of "terminal" – with info of what is created - history of created stuff. Possibility of multiple undos there – etc!

The integration with VSCODE and skipping text-editing altogether I think is the best way to go. Developers will anyhow use the Terminal in VScode and do coding of GO there, so more GUI-fyne-feedback and less GO-code-stuff would be preferable.

Even compiling/running might be solved through integration?! (switch to .go-editor & run!?! :-)

Component tree would be most welcome. ((... and also plz put error-messages like "Please select a container" into the GUI... ;-))

[andydotxyz]

The keyboard for terminal is incorrect somehow – I use Swedish keyboard and cannot enter backslash, ÅÄÖ, etc.

Please open a new issue to report problems like this.

I would prefer a ”log” of what is happening instead of "terminal"

This might make a nice feature request ticket, please open a new one so we can discuss.

The integration with VSCODE and skipping text-editing altogether I think is the best way to go

This is something we are considering - it requires the web delivery to be in production first as VSCode is using a web toolkit.

Component tree would be most welcome.

another great feature request, please open new ticket.

((... and also plz put error-messages like "Please select a container" into the GUI... ;-))

Yup a good bug report, just needs to be in a new ticket so we can work on it.