Don't create a windows gui application for fyne build

[hismailbulut]

Description:

Currently fyne build and all other commands sets -H=windowsgui on windows and this makes debugging nearly impossible.
Because fyne build is lower level than others and tries to mimic go build it is better to just generate a console app to make debugging easier. After this patch fyne build will generate console apps on windows by default but doesn't change others, all package, release and install commands will continue to generate gui apps.

Fixes #3604

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[coveralls]

Coverage: 61.77% (-0.008%) from 61.779% when pulling 57d16c0 on hismailbulut:no-windows-gui into 0800e0d on fyne-io:develop.

[Bluebugs]

I don't think that should be the default behavior even for the build command. If you call fyne build, it is likely from a terminal. So needing an additional window to write logs to when you're already in a terminal isn't really the most likely case. I do understand that you might want still want that behavior in other case, like distributing a debug build. I think in that case we could have a debug flags that will turn on the terminal and potentially additional things that will help collecting debugging information.

[hismailbulut]

If you call fyne build, it is likely from a terminal. So needing an additional window to write logs to when you're already in a terminal isn't really the most likely case.

This patch actually solves this. -H=windowsgui detaches console from application and we can't see stdout and stderr. With this pacth I am no longer needed to create another debugging outputs (eg. log file), I will just use the terminal I build on and see the output.

I do understand that you might want still want that behavior in other case, like distributing a debug build.

This is not about distributing debug builds but just only for monitoring stdout for debugging purposes.

Also this is default only for windows, linux and macos builds all have console, why it should be disabled on windows debug build. I can't just use go build because the metadata, app id and version information is important even when debugging the application.
When I say debugging I don't mean something like using delve, just printf

[Bluebugs]

I may have missed it, but this patch always turn on the additional terminal window on windows when using fyne build. I think that should not be a default behavior. It should be only on when you explicitly ask for it.

[hismailbulut]

I may have missed it, but this patch always turn on the additional terminal window on windows when using fyne build. I think that should not be a default behavior. It should be only on when you explicitly ask for it.

Not additional terminal window, it just prevents detaching from terminal only for fyne build and only for windows
But if you wish it can be an option named -nowindowsgui or -nowingui for fyne build and maybe for other commands. But I think it is enough just for fyne build

[Jacalz]

I agree with @Bluebugs. It is better to keep the current behaviour and instead add a flag to enable the terminal popup for those that want to do so.

[Jacalz]

Just one question: Does passing -H=windowsgui mean that you get no terminal output at all, even in the terminal you built the application from?

[hismailbulut]

Just one question: Does passing -H=windowsgui mean that you get no terminal output at all, even in the terminal you built the application from?

Yes exactly

[andydotxyz]

Just one question: Does passing -H=windowsgui mean that you get no terminal output at all, even in the terminal you built the application from?

Yes exactly

I just tested this because it seemed implausible... That does not seem to be the case.

I just built Fyne Demo using go build . in the cmd/fyne_demo directory. I then ran it using ./fyne_demo.exe and it outputted all the logs to the console.

Maybe I did it wrong, but that seems like it is debuggable just like in other OS despite having that flag added.

[hismailbulut]

Please try this on windows

• Go to the cmd/fyne_demo
• Build application with this flag using go go build -ldflags="-H=windowsgui" .
• Run fyne_demo.exe in same console and see the result, after that build it with just go build . without -H=windowsgui option and compare them

You will see the difference, First one built with -H=windowsgui will immediately detaches from console I run it and start as a separate process (not child). It is impossible to see the output.
Also I can't build my application directly with go because application mostly relies on the metadata that fyne injects, also app id and version information. Currently cmd/fyne always adds this option to go compiler flags and it is impossible to see the output of app built with cmd/fyne. In my opinion it should not be added for fyne build by default

[andydotxyz]

I did do it in Windows. Using the install sepcified in our getting started pages (MSYS2 Mingw64).
Perhaps you have a different setup and can provide the details? Maybe it relates to which console app you use...

[hismailbulut]

I did do it in Windows. Using the install sepcified in our getting started pages (MSYS2 Mingw64).
Perhaps you have a different setup and can provide the details? Maybe it relates to which console app you use...

May I ask what happens when you build with fyne build?

[andydotxyz]

Apologies, a typo. That was what I was testing. "fyne build ." Produces an app with metadata injected and when executed as "./fyne_demo.exe" it logs to the console it is connected to.

[hismailbulut]

Apologies, a typo. That was what I was testing. "fyne build ." Produces an app with metadata injected and when executed as "./fyne_demo.exe" it logs to the console it is connected to.

Sorry but this is not what happens to me. I also use msys2 mingw64 and when I built fyne_demo with fyne build it just has no console output.

[andydotxyz]

Can you step through how you launch the built executable? Earlier messages were not explicit enough for me to follow exact steps

[hismailbulut]

Can you step through how you launch the built executable? Earlier messages were not explicit enough for me to follow exact steps

Here some information:

• OS: Windows 11
• go version: go1.20.1 windows/amd64
• gcc version: (Rev6, Built by MSYS2 project) 12.2.0
• Both fyne and fyne cli version: 2.3.3
• Terminal: Windows Terminal
• I tested using msys2, cmd, powershell

Steps:

• go to the cmd/fyne_demo
• run fyne build
• run fyne_demo.exe

It doesn't show stdout in every shell I tested it, app is detached from console immediately
Output is visible when fyne built with this patch

[Jacalz]

Would it perhaps make sense that ldflag could be disabled only when building using -tags debug?

[andydotxyz]

Agreed, that was my realisation as well.

[andydotxyz]

Ahaha I finally realised why this was happening to some and not others - cmd and PowerShell fork GUI apps but MSYS2 and Cygwin etc don't.

So for now just use a "unix like" terminal and you'll get the output.

[Jacalz]

Sounds great. Should we document that somewhere?

[hismailbulut]

I remember I also tested with msys but I got the same result. But if it works on you then I maybe did something wrong. Maybe because I started msys in cmd shell I don't remember exactly. Anyway IMO it would be nice to have a simple note on the website's Windows development page.

[Jacalz]

It seems to me like we agreed in the team that the previous behavior is more correct. I'll close this now given how long it has been open. We value the contribution a lot and I'm sorry for having to close this.

[mondy]

I have a related problem and would like an option to disable -H=windowsgui.
When I run the file generated by fyne build from the go program, I do not get any output.
I use mage as my build tool. This build tool configuration is written as a go program.

My environment:

• OS: Windows 10
• go version go1.22.0 windows/amd64
• fyne v2.4.4
• Execute on Git Bash

Steps:

Run fyne build the following code.

package main

import (
	"fmt"
	"os"

	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/widget"
)

func main() {
	fmt.Fprintln(os.Stdout, "out")
	fmt.Fprintln(os.Stderr, "err")

	a := app.New()
	w := a.NewWindow("win")
	w.SetContent(widget.NewLabel("win"))
	w.ShowAndRun()
}

Run go run the following code .
I don't use mage to clarify the issue, but mage does the same thing.

package main

import (
	"fmt"
	"os"
	"os/exec"
)

func main() {
	cmd := `<EXECUTE FILE PATH>`

	c := exec.Command(cmd)
	c.Stdout = os.Stdout
	c.Stderr = os.Stderr

	fmt.Println(c.Run())
}

If you run the executable generated by fyne build as is, both out and err will be output, but if you run it via go program, neither out nor err will be output.

Simply disabling -H=windowsgui would solve this problem, but it is frustrating that I can't do that.
I usually work on PowerShell, but using GitBash to get around this problem is a bit of a detour.

[andydotxyz]

The "fyne" tool is for building the GUI bundle - and Windows will not allow that to log.
You can use the "go build" as you say if you want to run it from the terminal.
This is working as the Microsoft OS requires.

[mondy]

The "fyne" tool is for building the GUI bundle - and Windows will not allow that to log. You can use the "go build" as you say if you want to run it from the terminal. This is working as the Microsoft OS requires.

There is no way to embed FyneApp.toml as metadata when using go build.
Or if you embed metadata with ldflags without using FyneApp.toml, it will not work when using fyne build.
It is silly to rewrite the contents of FyneApp.toml to ldflags just to use go build.

I think the quickest way to solve this problem is to provide a way to disable -H=windowsgui in the fyne build.

[andydotxyz]

I think what you are describing is a separate issue. metadata not being included should not be tied to the status of internal build flags. If there isn't already an issue open perhaps it is worth creating one to work through that?

[mondy]

I have tried to create an issue, but the solution is unclear. #4688

[andydotxyz]

Thanks. Issues don't need solutions anyway - that is for us to figure out I guess...