Fl4m3Ph03n1x
Background
I have a basic Desktop app with the following config:
application.ex
defmodule WebInterface.Application do
use Application
alias Desktop
alias Manager
alias WebInterface.{Endpoint, PubSub, Telemetry}
@impl true
def start(_type, _args) do
children = [
Telemetry,
{Phoenix.PubSub, name: PubSub},
Endpoint,
Manager,
{Desktop.Window,
[
app: :web_interface,
id: WebInterface,
title: "Market Manager",
size: {900, 900},
icon: "static/images/resized_logo_5_32x32.png",
url: &WebInterface.Endpoint.url/0
]}
]
opts = [strategy: :one_for_one, name: WebInterface.Supervisor]
Supervisor.start_link(children, opts)
end
@impl true
def config_change(changed, _new, removed) do
WebInterface.Endpoint.config_change(changed, removed)
:ok
end
end
This is basically the default configuration. You will notice the desktop app does not have a MenuBar. This is on purpose, as I don’t want one.
Problem
The issue here is that no matter what, the application won’t close:
It always reopens.
After checking the code of Desktop, I believe the issue could be in Desktop.Window:
def init(options) do
window_title = options[:title] || Atom.to_string(options[:id])
size = options[:size] || {600, 500}
min_size = options[:min_size]
app = options[:app]
icon = options[:icon]
taskbar_icon = options[:taskbar_icon]
# not supported on mobile atm
menubar = unless OS.mobile?(), do: options[:menubar]
Namely, I am lead to believe there is a difference for Mobile apps and normal apps.
Funnily enough, if add a MenuBar, then the application does eventually close, even though it takes forever for the process behind it to terminate:
{Desktop.Window,
[
app: :web_interface,
id: WebInterface,
title: "Market Manager",
size: WindowUtils.calculate_window_size(0.4, 0.7),
menubar: MenuBar,
icon: "static/images/resized_logo_5_32x32.png",
url: &WebInterface.Endpoint.url/0
]}
Cliking on the Menubar Quit option also closes the application.
Questions
Am I forced to have a Menubar, if my I have a Desktop app?
How can this be fixed?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest in /Elixir Desktop
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #ai
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
The “close window” icon and the “Quit” menu item do quite different things:
the “Quit” menu item ends up calling
Window.quit/0, which ultimatelykill -9s the BEAM from outside (!!).the “close window” icon ends up calling
Window.close_window/2which returns{:stop, :normal, ui}- which will result in the parentSupervisorrestarting theWindowprocess.Setting the
Desktop.Windowprocess torestart: :transientwould be prevent this restart.Not sure how the menu bar ties into this, tho…
Fl4m3Ph03n1x
I see that it spawns a process which eventually calls
System.halt. This is curious to me, as it raises a couple of questions:Why do we need to
spawna new process for this? The new process will kill everything (including the parent) so why not have the parent just do it?Why not use System.stop instead? I know it eventually ends up calling
System.halt, but it also does a lot of cleanup on the background before that.Here I am confused. Both
Window.quitandWindow.close_windowshould eventually call OS.shutdown which would in theory kill the BEAM process, thus preventing a restart.I am guessing the
:wxFrame.isShown(frame)is preventing this from happening, but I am not sure if this is intended behavior or not.Am I missing something in my interpretation of the code?
Also, huge thanks for helping !
al2o3cr
I’m definitely at the edge of my understanding regarding what’s happening on shutdown, but the main conclusion I draw from the code + issues is that “application shutdown” is a complicated mess when the app is coordinating Erlang / C++ / native entities all at once.
More examples:
OS.quit’s documentation mentions “destruction is crashing”Researching about the other “close” event mentioned in that last ticket turns up this note in the wxWidgets docs: