# Options for developing GUI standalone app

**URL:** <https://discourse.julialang.org/t/options-for-developing-gui-standalone-app/52776>\
**Category:** General Usage\
**Created:** [January 3, 2021, 3:27pm UTC](https://discourse.julialang.org/t/options-for-developing-gui-standalone-app/52776 "2021-01-03T15:27:30Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![MA\_Laforge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ma_laforge/32/385_2.png) [@MA\_Laforge](https://discourse.julialang.org/u/MA_Laforge)\
**Post date:** [January 3, 2021, 7:53pm UTC](https://discourse.julialang.org/t/options-for-developing-gui-standalone-app/52776/7 "2021-01-03T19:53:10Z")

</div>

> [@dlakelan](#):
>
> Also how to structure this project? Its not a “Package” is there a standard way to structure a thing like this? For example it would be nice to make it run on Linux, Windows, or Mac. Doesn’t have to be a clickable gui icon, just easy to invoke without being a Julia programmer.

You are correct. You don’t technically need to develop a “Package”, but you should (at a minimum) create a “Project/Environment” for your application. That way, you can ensure your app will execute correctly - especially if you include the Manifest.toml file. Of course, including a Manifest.toml (project) file also means the user gets locked to _ **the exact solution you specify** _ (will not get updates of dependencies).

To help users run your application on their own system, I suggest:

### ConventionalApp.jl

> [@\[ANN\] ConventionalApp.jl](https://discourse.julialang.org/t/ann-conventionalapp-jl/52390):
>
> Simple framework for making conventional applications in Julia. [https://github.com/ma-laforge/ConventionalApp.jl](https://github.com/ma-laforge/ConventionalApp.jl)What is it for? Julia “Project Environments” define the set of packages needed to experiment within a particular problem space. The Julia flow therefore encourages users to activate a project environment and use problem-specific “scripts” to run their experiments. By design, project environments are meant for somewhat open, “interactive” explorations (i.e. assemble custom analyses…

And despite the fact that you don’t _ **need** _ to develop a package, I still suggest you do. I made a conscious decision with ConventionalApp.jl to treat application repositories as a package. Though your app-package does not need to be published in Julia’s General registry, I found it easier for the users to operate on their apps if they are treated as “packages”.

That’s because Julia’s `Pkg.jl` provides functions & objects that simplify how we access & manipulate packages. For example, a user can `add http://url/to/MyPackage.jl` to make Julia aware of any github-hosted package. Then, you can call `using MyPackage` to load it while simultaneously creating a `MyPackage` `module` object.

In contrast, Julia’s (non-package) project/environment toolset is not as extensive. ConventionalApp.jl only uses it to setup the active “Julia environment”, making sure the right set of packages are available to your application. (And cleans up the `LOAD_PATH` to its minimal useful state).

### Limitations

I created ConventionalApp.jl out of needs similar to yours. It is a very basic package, but the solution is not completely ironed out. Like I mentioned in my [ANN] post: I feel like I am missing a simpler solution staring me in the face, but I have not yet found it.

But even if this truly is the right way to go, the solution will likely need to be adjusted once people start using it. So feel free to open PRs.

---

_[View the full topic](https://discourse.julialang.org/t/options-for-developing-gui-standalone-app/52776)._