About

LaunchMenu has been a long time in the making, and has been a bumpy ride so far. In spring 2017, Sancarn created the initial version of LaunchMenu in the keyboard scripting language Autohotkey. A few months after the initial rendition was created, Sancarn asked Tar for advice on the UI development of LaunchMenu. Tar suggested the use of HTML to build the UI, and assisted in the creation of it in the c9 IDE. Tar fully joined the project in summer 2017. Since then a lot of progress has been made and in 2020 the LaunchMenu github organization was formed.

Below we'll discuss a more detailed history and give some information about ourselves.

History

Iterations

LaunchMenu-ahk

Mac OS X has a built-in application named "Spotlight", which provides a similar set of functionality to LaunchMenu. However, due to the proprietary nature of Spotlight, it has some flaws:

  • Single Platform
  • Lack of customisability
  • Lack of extensibility
  • Limited interactivity

This led Sancarn to the development of a Windows only version of Spotlight made with Autohotkey. This was named

LaunchMenu-ahk. Due to limitations in the AHK UI system, Tar suggested
LaunchMenu-ahk
use HTML rendering instead. From then on, LaunchMenu booted up an AHK window containing an Internet Explorer control, which rendered the HTML page. You can see the bare-bones AHK application on github, as early as 2017-04-15.

LaunchMenu-electron

It soon became apparent that AHK was not the right tool for the development of LaunchMenu, especially given that we wanted to target it as a cross-platform technology. Tar, now officially joining the project, suggested we stay in JavaScript, and we found an emerging technology created by Github - electron. This seemed to give us the flexibility to deploy on multiple platforms, while maintaining our preference for HTML and JavaScript. And so

LaunchMenu-electron was born.

LaunchMenu-framework

In terms of functionality

LaunchMenu-electron started to get close to a working product. But as we continued to improve our software development skills, we started to realize this version wasn't all that great. The code was hard to maintain, the UI wasn't amazing, and bugs kept popping up. This lead us to the first major redesign, where all code was scrapped and rebuilt from the ground up. This time, we established a set of key goals, and tried to design all code to adhere to them. These goals were:

  • LaunchMenu should be completely modular
  • Modules shouldn't have direct dependencies on each other:
    • Modules should be added to a registry
    • Modules should request instances of dependencies through the registry
    • Modules should be installable, and be able to override other modules in the registry
  • Modules should have native support for customization by means of settings
  • Never limit the user
    • The theme of the application should be flexible.
    • The user is given deep settings which allows full customisation of the product.
    • The layout of applications should not be dictated by the developer, but chosen by the user
    • The user can choose which modules are used to override other modules (including our own).

This led to the development of

LaunchMenu-framework. In this version we started using react to render the UI of LaunchMenu. We made a lot of progress on the core aspects, and then decided this should become a stand-alone framework that could be reused for other programs. Some videos of this version can be found in the following YouTube playlist. Unfortunately the code for the tabs that can be seen from the third video on was lost when the project was deprecated.

    Adjust

    After working on

    LaunchMenu-framework for a while, we once again decided it was time for a redesign. During the process of making
    LaunchMenu-framework
    we noticed several issues, but also realized the great potential of this framework! We set out to make a next version of the this framework to fix the following issues:

    • Modules live in the window that they render in, so in order to move them from one window to another they have to be completely serialized:
      • This serialization requires manual code for each module type
      • This serialization is the cause of several issues
    • Modules have to communicate with each other over IPC, since they may live in different windows
    • Modules are referenced and imported by name, but names might not be unique which could cause issues

    So we chose to create a new version of the framework using a newly discovered technology, TypeScript, and called it

    Adjust. This version of the framework addressed the major issues by making all modules live in the main thread. Modules would then send content, via IPC, to windows for rendering. We essentially moved to a full MVC setup, where communication happens over IPC. This allowed us to seamlessly move modules from 1 window to another, without any need for state-transfer of the module's runtime. One benefit of this model allowed users to render the same module in multiple places simultaneously. Some demo/test videos can be found in this Youtube playlist.

      The addition of TypeScript allowed us to neatly define interfaces of modules and use these to seamlessly obtain module instances that adhere to these interfaces from the registry. At this point we also went overboard with TypeScript definitions, and tried to get perfect intellisense for, what was actually, a rather dynamic process. This is a trend we continue to this day, but we try to adapt our code style to reduce boilerplate and allow simpler type definitions.

      LaunchMenu

      Adjust
      was taking shape, and was even used as the framework in another (private) project by Tar. However, we once again started doubting the code that was in place. It was becoming hard to maintain due to tight coupling, and the large amount of required boilerplate made us doubt whether real applications would be built using this framework. We decided that this warranted a redesign of Adjust to a system. One which wouldn't force a strict module pattern or a tightly coupled system, but instead supply a set of independent utilities with interfaces to interact with the system if wanted/needed.

      We however realized that at this rate LaunchMenu would never get finished. So we decided to shelve the Adjust framework and to move away from this highly idealistic scenario. Instead we focussed on the aspects that are really important for LaunchMenu itself and started planning our requirements for

      LaunchMenu. With a rough roadmap in place, development was started. To be more organized we used github kanban board, issues and branches to track progress. Around 9 months after starting with
      LaunchMenu
      , and about 4 years after the initial inception, we finally had a working version LaunchMenu. Now, after filling the documentation gap, we were finally ready for the initial release of
      LaunchMenu
      .

      Timeline

      • 2017-03-01

        LaunchMenu idea and AHK demoAHK Version of LaunchMenu.

      • 2017-04-08

        LaunchMenu-ahkInitial HTML integration into AHK LaunchMenu application. Commits via C9.IO.

      • 2017-04-17

        LaunchMenu-electronMove to electron and full JavaScript implementation.

      • 2018-07-05

      • 2019-05-31

        InfoLab releaseDevelopment of LaunchMenu-like system by Sancarn due to lack of actual LaunchMenu system.

      • 2019-06-18

        AdjustMove to typescript and rethinking of framework.

      • 2020-03-08

        Adjust v3Start of second rethink of the framework, imminently shelved.

      • 2020-06-09

        LaunchMenuStep-back from framework development. Focus on LaunchMenu product.

      • 2021-02-26

        LaunchMenu documentationDocumentation of features, applets, history and developer documentation.

      • 2021-06-25

        LaunchMenu initial releaseThe initial release of LaunchMenu.

      • ...

      • Simple applet developmentRelease some more applets that are simple to implement, such as the calculator and some of the remaining core applets.

      • General LaunchMenu developmentLaunchMenu as a system will continue to be developed with new features such as mnemonics and improved searches.

      • File system applet developmentThe file system applet needs a lot of work and will be in developement for a long time.

      • ...

      • LaunchMenu v2/Adjust v3??We will most likely end up rewriting things again at some point...

      Founders

      Sancarn

      1993

      founder

      Hi there, I'm Sancarn, and I'm the founder of LaunchMenu. For most of my childhood I wanted to be a Physicist. When it finally came to going to university, I decided to do a Theoretical Physics degree. Soon after starting at university, my friend introduced me to Minecraft. Through Minecraft, I found redstone which led to me learning a lot about Digital Electronics and Engineering overall. I learnt how to use redstone mostly through experimentation and reverse engineering. Through Minecraft I met many other creators including Tar.

      Throughout my degree I never really understood the point of programming. We were often given a task to achieve, but that task was nothing "new" and only served in developing the student's knowledge. I was never really interested in that. I wanted to make things which had an impact on other people's lives! After I started working for companies I quickly realised that programming was really beneficial to those around me, which quickly became my sole driver for improvement of my programming knowledge. To this day I spend more time programming than anything else, and continuously develop and expand my knowledge of this field. I love it! I'd definitely be classified as a blue sky thinker and I always love to improve my work, and develop new technologies for people to use!

      In recent years, I have mostly taken a back seat on the developement of LaunchMenu, as I've spent most of my time either working overtime or maintaining other open source projects, but I'm still an active contributor to software architecture discussions and documentation. Besides programming my interests don't really reach out that far... I enjoy data analysis, playing video games, socialising with my friends and I always love a good YouTube binge!

      Tar van Krieken

      Aka TarVK

      1998

      cofounder

      When I joined the project in 2017 I had some basic experience with web-development. Up to that point, I'd learned everything by experimentation and most of my code was a mess. I started writing software around 2012, by reverse engineering some Lua code I found online. I quickly noticed I was decent at turning the ideas in my head into working code, but it took me a long time to develop a semi clean/neat code style. Today, I've had some professional web-development experience and gained a bachelors degree in computer science. Obviously, I am still not the most skilled developer out there, but I think I have become quite good at writing modular and maintainable code. As you might see within LaunchMenu however, some things are still rather messy. This is likely due to having my own coding style and not always following standards and conventions.

      Nowadays I mostly enjoy trying to come up with novel ideas, often related to software architecture. I also quite enjoy all my theoretical computer science courses and will likely continue to pursue this area throughout my career. As can be read from our history, I am also not prone to the sunken cost fallacy. Perhaps I should be more worried about sunken costs... but I love to continuously improve my work!

      Writing code takes up the majority of my time, but I do also have some other hobbies. I do enjoy doing some "mechanical engineering" using lego technics or 3d printing, and I also spend time on some physical hobbies such as juggling and doing (beginner-level) parkour from time to time.

      Acknowledgments

      Bram Hoven

      code contributor

      Table of Contents