@lucasfernog I’m sorry, I might not have been very clear - thanks for helping though!

@qyloxe I had begun thinking about events, and then saw your comment. This is exactly what I needed - thank you! Bonus points for including old IE event listeners and also removing the event.

I’ll dispatch a new event from my non-Vue/Quasar code with:

window.dispatchEvent(new CustomEvent('myEventNameHere'));

Thanks for the idea, @lucasfernog, but I’m not sure that could be done. The “external JavaScript” that would need to be able to communicate to the Quasar app would be dumb ol’ vanilla JavaScript, with no use of any Vue stuff.

I have some non-Vue/non-Quasar content that I want to be able to call a Vue method from. How can I call a method in my app from other external JavaScript code?

In this case, I just want to have this other content be able to change the app’s route to go home, like

this.$router.push('/')

That would be in a Vue method, but I just don’t know how to call that from “outside” the Quasar build.

Does anybody have ideas on how to do such a thing?

I’m on the tail end of a Quasar 0.17.20 Electron desktop app, and I feel “the feels” around this, too.

I’m not answering for anybody here, but I have thoughts towards this when wanting to use an open-source project in production “now”. If it’s in Alpha, don’t even consider/worry about it. If it’s in Beta, it will be in Beta for at least “another 60 days”, but more likely 90+ days depending (I don’t say this with regards to Quasar, but just in general…you really don’t know). If you’ll be getting into the main, serious development of a project before 30 days, then don’t consider a Beta. Depending on the release cycle, Quasar (or at least other products) have a Release Candidate stage that takes yet more time before being an official release.

Or… if a product is in Beta, and you aren’t delivering for at least 90 days, you can measure the risk of not-ready-for-production software and bring it into your project. And hope that you have a production-ready version to integrate into your project before your completion date. It’s a gamble, and not worth the risk, IMO.

The beauty and the pain of amazing open-source stuff, like Quasar, is that we want to use what’s coming down the pike… but can’t until the upcoming awesome stuff is really ready. It’s so much better to play it safe and use a production-ready version even if it’s not the “bright and shiny.” In my opinion, the project and the client won’t be worse off, only we the developers will have that light “fear of missing out” feeling

The uncertain delivery dates of open-source software is a benefit. The alternative is corporate-based software & tooling that must meet dates, and tends to really suffer because of that. Oh, and they cost to use, usually, too.

I haven’t used q-uploader, but when I tried this out, this is what I did:

In my template:
<q-uploader multiple :url=“url” @add=“uploadAdded”/>

Then in my Vue code:
methods: {
uploadAdded (file) {
console.log(‘file.length’, file.length)
}
}

I choose 2 text files from my computer, and I saw “file.length 2” appear in my console.

Do you see any errors when you run your code?

Did you add this component into the components area of the ‘quasar.conf.js’ file?

Hey, I was able to find out what was missing and finally got electron-builder to work with my windows icon.ico file, with no jagged results!

The deal was that some add’l config was needed in the builder object of quasar.conf.js. In electron-builder’s documentation, I went to the Windows target page: https://www.electron.build/configuration/win#WindowsConfiguration-target.

From there I found that there is an icon property. Include the ‘win’ object, and include the nested ‘icon’ object with the value being set to the path of your windows ICO file.

icon: ‘src-electron/icons/icon.ico’

My updated quasar.conf.js file (the electron section of it) looks like this now:

electron: {
  bundler: 'builder',
  extendWebpack (cfg) {
    // do something with Electron process Webpack cfg
  },
  builder: {
    // https://www.electron.build/configuration/configuration
    appId: 'com.etrac-mss.etrac',
    win: {
      icon: 'src-electron/icons/icon.ico'
    }
  }
}

I ran the build, and the installer file looked good. Then I ran the installer and the app icon looks good, too. Phew! Glad to find it’s something simple… (simple after it’s discovered, that is).

I’m wondering if this is something that should get added to Quasar’s documentation for bundling with electron-builder (hmmm, by me?). I guess I would have thought that this would be part of the docs already, or that I’m doing something odd. More likely, it’s an issue of “If you use an external package XYZ, you need to learn about XYZ”.

Here is an image of all my icons (pre and post build/install), and the one icon needed for my Windows distribution need (‘src-electron/icons/icon.ico’).

Big thanks @metalsadman for all your ideas and suggestions - that made a big difference and helped me along!

I didn’t know about electron’s BrowserWindow object’s icon property, so I tried that out but no go. I think a big difference between your build process and mine is that I have been using electron-builder versus you with electron-packager. I think I went this way a while back when I began because builder will also creates an installer file.

When I switched to electron-packager, lo and behold the file’s icon looks good like I’ve wanted. But, if I go this route I just need to figure out the installer aspect. On a whim, do you have an npm script in your package.json file that does this?

Thanks for going through your steps and showing your images. I can see that your app icons look fine and as-expected.

I know you mention editing the images in ‘src/statics/icons’. That was a big “Ahah!” moment for me, but when I tried that it had no effect…even using the original Quasar ones, they weren’t used in the build. Weird, huh? I do think, though, there’s something here that I’m not making a connection with, yet…

Did you do anything with the 3 Apple/Windows/Linux icons in ‘src-electron/icons’? That was my focus before your suggestions. From https://quasar-framework.org/guide/electron-preparation.html, it sounds like it’s actually the only place one has to deal with icons when only creating an Electron app.

Which bundler are you using? electron-builder or electron-packager? Below is my config in quasar.conf.js where I specify electron-bundler. I’m just wondering if there are obvious things that I missed in my bundler config (but’s this part of the file is dead simple).

electron: {
  bundler: 'builder',
  extendWebpack (cfg) {
    // do something with Electron process Webpack cfg
  },
  builder: {
    appId: 'com.etrac-mss.etrac'
  }
}

I do see where your various icon image filenames are mentioned in quasar.conf.js, but they are in the ‘pwa’ object, not the ‘electron’ object. I had paid little attention to it and had even deleted this from my file (I’ve now added it back in, just on a whim). It’s the only connection that I can see between a config file and the images in ‘src/statics/icons’. You can see an example here, https://quasar-framework.org/guide/pwa-configuring-pwa.html#Configuring-Manifest-File, which seems to be the only place where the icon files you mention are ever mentioned. But isn’t that detail just for representing a web app manifest for PWAs, and not for electron building?

I did follow you suggestion though, and had used Photoshop to create all the 9 PNG images.

Some add’l info RE: how I created my app’s icon files…

As per one of the (4) recommended tools (via https://www.electron.build/icons) to create app icons (the three formats required) I uploaded my 512x512 PNG image to https://iconverticons.com/online/ and grabbed the resulting files.

I would even try downloading other peoples’ icons from that site, and I do have the same jagged result. That’s what helped me determine that the jagged images are not a result of my image/icon production process.

I’ve tried another idea, building with just the win32 target:

$ quasar build -m electron -T win32

So, with building for win32 only I deleted the Linux icon (‘src-electron/icons/linux-512x512.png’) under the impresson that since I’m not building for Linux this isn’t needed, and that the Windows icon (‘icon.ico’) was all that would be needed.

The build failed because it was still expecting the non-targetted platforms’ icons. I sorta get that - one should just have all the icon files in there regardless of your build, ok… So this idea didn’t get me to a good place.