Version 2

[leaanthony]

This is for discussing anything related to Version 2 of the project.

[SGarno]

I noticed your posting regarding Version 2 in that there are plans to support WebView2.

Where are you with that in the 2.0.65 alpha?

[leaanthony]

Absolutely! The v2-alpha branch already has support but not all of the Wails API is currently ported. Be warned though, the windows stuff is quite unstable right now. That being said it's fundamentally working:

[SGarno]

Awesome! Well, I would be willing to give it a go and provide feedback if that helps.

[SGarno]

I have fixed a few things with the windows side of the house on the build and vscode debug. I could do a pull request if that would be helpful.

[leaanthony]

How are you bundling the image? Are you using a plugin? I use base64 images and there's plugins to do that automatically

[SGarno]

What I am doing is trying to make Wails work with other ui builders native CLIs such as Vue, Nuxt, Quasar, Veutify, etc. I am currently using Quasar v2 beta as my starting point. Here is what I did:

1. Initialize wails project wails init -d sample2 -g -n sample2 -vscode
2. Delete the frontend directory that was created cd sample2 && rmdir /s frontend
3. Create the quasar app into the frontend directory quasar create
4. Update the wails.json with the following:

              "html": "frontend\\dist\\spa\\index.html",
              "frontend:build" : "quasar build"

5. Update main.go for windows adding in the lines:

 		Windows: &windows.Options{
			WebviewIsTransparent:          true,
 			WindowBackgroundIsTranslucent: true,
 		},

6. Run the build wails build

The quasar build command compiles and webpacks the code into the frontend/dist/spa directory which I am pointing wails to. At this point it should be nothing more than assets being included. I have traced wails (this is where I found the tokenizer bug) and I can see that it is going through the links and img tags and incorporating them into the embedding. Just not sure after that, why it can't seem to find the assets because the edge debug window disappears when I try to put breakpoints in and trace it.

The ultimate goal here is to allow wails to operate with other frontend cli's using their native capability (as opposed to requiring a specialized template) if possible.

I would also like to get quasar dev during wails dev using bridge mode (I haven't gotten to that point yet).

(edit)
In case it helps....here is the exact error in the console:

Pushing event listener: wails:sync:store:updatedbybackend:wails:isdarkmode
VM9:1 Pushing event listener: wails:sync:store:updatedbybackend:wails:loglevel
VM9:1 Pushing event listener: wails:sync:store:updatedbybackend:wails:appconfig
VM9:9 ChunkLoadError: Loading chunk 3 failed.
(error: )
    at Function.i.e (<anonymous>:9:81978)
    at component (<anonymous>:9:83875)
    at <anonymous>:9:16772
    at <anonymous>:9:17022
    at Array.map (<anonymous>)
    at <anonymous>:9:16998
    at Array.map (<anonymous>)
    at It (<anonymous>:9:16948)
    at <anonymous>:9:16458
    at p (<anonymous>:9:20183)

[leaanthony]

Are you trying to bundle images? This won't happen automatically and you'll need to use a bundler plugin to do it. Remember, there's a big difference between a site/app that has all its files on the local FS and a Wails app where everything is bundled into the binary. If you reference local paths, then don't be surprised if your app can't load them. What would be amazing is if we could bundle those kinds of assets without relying on a 3rd party plugin. We actually already have the start of that in the html package, but it isn't a priority as there are plenty of solutions for frontend bundling that already exist.

One last thing - however you bundle your frontend, chunking is probably not what you want to do.

[SGarno]

Ok, I think I am confused then. In v2/internal/html is assetbundle.go, the function loadAssets calls processHTML which seems to be adding the assets that are referenced in the html file. Is that not the case?

[leaanthony]

Not entirely: it looks for the JS and CSS files from the HTML. The reason we've done this is that there is an experimental server mode that will run your app headless and that will deal with assets a little bit differently to desktop targets.

There's a case to be made for bundling images but what if they are remote images? Do you leave them be or pull them in? What if the image is being created dynamically? At the moment, we assume that all the image/font bundling is done by the developer via EG webpack and will "just work" by executing the javascript. If you want tips on how that works, look at the v1 templates.

[AlienRecall]

i'am waiting for version 2.0 since my app doesn't work on windows because some react libraries doesn't load on IE11. Is there any fix for that or i need to wait for the 2.0 release?

[AlienRecall]

where can I contact you to send you the project?

[leaanthony]

You can invite me if it's private or paste the link here if it's public.

[AlienRecall]

done, I've invited you in a demo repository, also feel free to use it as wails v2 + react template

[AlienRecall]

any news?

[leaanthony]

A couple of things to start:

• You are including both v1 and v2 runtimes. This will not end well!
• You seem to have ported v1 template instead of making a fresh frontend (i can see wails-react-scripts)

If I were you, I'd delete everything from frontend, generate a react template using whatever the current fashion dictates, then add the ready() hook into your project. Once you get a project working, you can convert it to a template.

[twiny]

Hello,
I've create a small template to quickly start a Wails v2.0.0-alpha.65, Svelte & Tailwindcss.
github.com/superiss/desktop

Application works perfectly on MacOS but I m wondering how to build my app to window or linux in "v2.0.0-alpha.65"?

[twiny]

@leaanthony Awesome. thank you very much. I will try it out tomorrow morning. i will post update.

[leaanthony]

Thanks for being an early tester! It's really hard to get everything done, including testing, so all help massively appreciated.

[twiny]

Hello,

I cloned the repo, and install the Wails v2 command from v2-alpha branch.

this time wails build finish building without errors. but when i click on the app .exe. the app does not open. however on wails dev mode, i got a connection error to the bridge.

backend debug:

platform not support. from this:

wails/v2/internal/bridge/session.go

Line 78 in 31cf04a

func (s *session) start(firstSession bool) {

wails doctore output

On MacOS it works as expected. here is the example of the app on the test: https://github.com/issmeftah/wails-template

I m not sure what i m missing.. installed the cmd from v2-alpha branch.

[twiny]

@leaanthony, i can maybe write some doc for wails v2, tell me where to start

[leaanthony]

Thanks for the offer! I see you've done great work with your template. The Windows port is currently underway so don't be surprised if it's not 100% working right now. I'll try and clone your template and debug it.

[svengreb]

First things first: This is a great project, thanks a lot for your effort 💪🏼
It is finally a solution to strip Electron from my projects. I used Node's IPC module and native Linux sockets (pipes on Windows) to communicate with a Go application that was embedded into the Electron bundle and executed as child process when Electron started. This way I was able to do all the "heavy work" in Go and let Electron only do the rendering with React by pushing messages via IPC. Wails on the other side is exactly was I was looking for all the time and I've spend some months now to create a usage concept for my projects and already started to port some of them (with absolute success 🎉).
Sorry for the small off-topic, but I know that feedback is important for OSS maintainers.

After porting one of my projects to Wails v1 some months ago I started to migrate it to v2, but got stuck when running the development mode. After spending some hours with (unsuccessfully) debugging my own code. I suspected that the chance it high that there is a problem in the Wails v2 alpha branch itself so I started to debug with a local repository clone of Wails. The main problems were two JS problems when running in development mode:

• undefined is not a object (evaluate window.webkit.messageHandlers)
• undefined is not a object (evaluate main.Basic...)

So basically somehow the window.webkit was not defined at all so calls to keys like messageHandlers and messageHandlers.external.postMessage also failed. The second error indicated that the Go <-> JS bindings are not available and checking the window.backend object only returned and empty object (since {} is set as default in the code).
After digging into the latest commits I noticed that the setupIPCBridge function of the v2/internal/runtime/js/runtime/bridge.js file has been changed and the definition of the window.webkit has been changed in wailsapp/wails@d2e4a0b0 to use the window.wailsInvoke function instead which explains the first JS error.

function setupIPCBridge() {
	-// darwin
	-window.webkit = {
	-	messageHandlers: {
	-		external: {
	-			postMessage: (message) => {
	-				websocket.send(message);
	-			}
	-		},
	-		windowDrag: {
	-			postMessage: () => {
	-				// Ignore window drag events
	-			}
	-		}
	-	}
	+window.wailsInvoke = (message) => {
	+	websocket.send(message);
	+};
}

The error regarding the empty window.backend object is a result of the first error since the IPC message is never send and bindings are not set up.
Note that the problem is likely only relevant for macOS users since the function call was adjusted in the windows.js file.

To fiy both errors I've adjusted the SendMessage function in the v2/internal/runtime/js/desktop/darwin.js file to use window.wailsInvoke instead:

export function SendMessage(message) {
  -window.webkit.messageHandlers.external.postMessage(message);
  +window.wailsInvoke(message);
}

After rebuilding the assets (using the rebuild.go one-shot-runner) everything worked fine again. However, I'm not that familiar with the code to say that this is the only adjustments that is necessary. I found some more places where the window.webkit.messageHandlers.external.postMessage is called, i.e. in the v2/internal/ffenestri/ffenestri_darwin.c file.

Since these changes were published in [@wails/[email protected]][1], the development mode and (production) builds will break for all macOS users who did not pin the npm package to an explicit version. Using @wails/runtime@<=v1.13.17` works fine.

TL;DR;

The npm package version @wails/[email protected] breaks builds for macOS users due to the darwin JS runtime changes made in wailsapp/wails@d2e4a0b0. Adjusting the SendMessage function in the v2/internal/runtime/js/desktop/darwin.js file fixes the problem, but it might require more changes because it looks like there are other places where the window.webkit.messageHandlers.external.postMessage function is still called, i.e. in the v2/internal/ffenestri/ffenestri_darwin.c file.

Maybe you already noticed this bug on your local system already, but haven't pushed a new commit yet. Anyway, just wanted to share this finding to save other (and you) from spending more hours into finding the root cause.

[leaanthony]

I'll test build tonight though I'm not sure it's clear how this is happening as this is a native message handler that's nothing to do with the JS runtime!

I've made headway with the DLL issue and can confirm that the issue is partly due to me not fully understanding how the webview2 component works and how to link that against our apps. I've been doing a bit of work on splitting up the code into "webview2" functions and "native wails runtime" functions. I'm not sure when it'll be ready but today's work was a deep understanding of how this all ties together. For clarity: the webview.dll is not needed, at all. Delete it and it'll still work on any machine with the runtime installed. WebView2Loader.dll is essentially some code to find where the webview2 library is on the system and load it in at runtime, so it all works. The issue is, how do we get the webview2 runtime on the system? It's a big issue at the moment that's a pain point for a lot of projects. Looking at how the webview project does it, they use an "intermediary" dll which is built using msvc. This allows it to statically link against the webview2 library and pull in what it needs. The resultant DLL is linkable using mingw so that's how we get it to work in Go. The tricky thing is this: Wails generates code for bundling the assets so there needs to be "wails code" that's separate to "webview2" code that gets compiled and linked. I'm in the process of doing that.

[leaanthony]

@svengreb I've done some more experiments and got to the bottom of what's going on. It wasn't sitting right with me that webview2 was working for webview apps but not wails apps and that webview.dll was less than a meg, when the webview2 fixed version runtime was 150M uncompressed. And then it hit me: webview drops back to edge rendering engine if it can't load webview2. If you right click a webview app (with debug enabled) on a machine with the webview2 runtime installed, it will work and you'll get a menu and devconsole. If you run the exact same program from a VM with no webview2 runtime, it will fall back to edge - and you can tell by trying to open a dev console: there is none. So, to come full circle, there's nothing I need to do from code perspective to get this working on a fresh machine other than determine what to do with how to get the correct runtime on the user's system. I'll open up a new discussion for that!

[svengreb]

On the one hand, that's good news, but on the other, it's not either 😄
So basically the situation for Windows is the same like that of Electron: bring your own runtime or rely on the user to set u the system beforehand. I've saw the new discussion thread in my notifications yesterday and will contribute to it later on.

[leaanthony]

It's the same situation as any project using webview2

[leaanthony]

@svengreb Got some updates on this on the other discussion - I have a working solution: #736 (comment)

[dwdcth]

I have tried v2. It's good enough for me to start a project. Is there any way to add GetPosition and GetWindowSize function to the window api?

[leaanthony]

We could look at that. Be aware that it's still alpha so the api may break. What platform are you targeting?

[dwdcth]

Ok, I only have Windows now, but my target is crossplatform.