I thought about Artemis for a while, and I think I turned on my ink machine.
When Canonical announced the end for Unity and the convergence plans for Ubuntu, I was a bit devastated. Unity 7 was a great desktop environment that certainly challenged other environments, and I really didn’t see a good reason to jump ship to Unity 8 (yet). As a response to this message to continue this environment, I started the Artemis Project (at that time, known as Enjade). Back then, the goal was simple: recreate Unity inside of Plasma and keep going with it. Things got a bit complicated, though, as people were looking for a legitimate Unity fork; as a result, I sprang up the Pure edition, marking the original project as “Core”.
It’s been months now since the inception of this project, and it’s gone through a few changes. The website got redone several times, though the final design is pretty much here. Jaeden’s blatant refusal of association with anything that I’m involved in helped rebrand the project to a community name: Artemis (the question of thanking her or still feeling butt-hurt remains). Communication is much better with a connected IRC channel and a Riot room to go with it.
There certainly has been a bunch of changes, but the foundation of keeping Unity alive still remains the same; however, maintaining two different entities of the same nature, especially with other goals in mind, is not only difficult but pointless as well. While Core would probably be preferred by many with its modern capabilities, Pure would still be there for people who wanted X11. Essentially, I’m holding onto an ink machine that can’t figure out how to dispense ink and a dead horse that can’t really figure out how to properly “die”.
Within the last few weeks, I’ve been thinking about what Artemis could be, and my growing and continuous experience with Wendy’s is certainly helping that. Artemis should be a desktop environment that delights every developer and user, rather than a fractured mess that appeals to two different audiences. So, I put on my thinking cap and began working on a few mockups that could turn into a new Artemis that fulfills my own personal goals with the project. Here is the result of that.
As aforementioned, I had several goals when it came to Artemis:
- Be as accessible and open as possible
- Work as a desktop environment of the future, not just of the present
- Looks and feels as good as it functions
- Give power to users and developers while keeping the first goal
As I worked on the mockups while constantly listening to “Gospel of Dismay” and “Build Our Machine”, I kept these goals in mind. A fair warning: the mockups are in fact Bendy and the Ink Machine-themed; the actual environment and theming may look a bit different.
A language of the future: Swift
I wanted to choose a programming language that kept the essential goals in mind and the flexibility for me to actually contribute to the code of the project. I could learn more C++ and C, but there was an alternative language that I sought out that made more sense to me: Swift.
Before I enter into the positives of Swift and why I have it as a preference, I have to mention some of the downsides to this language. To begin, although Swift is open-source, it is still heavily managed by Apple Inc., whom is reluctant and not well-known for playing nicely with others. Swift doesn’t have a proper editing tool like on a Mac with Xcode, so most of it is command-line based. Bindings with Qt and/or GTK are a bit iffy, if not doable.
Nonetheless, Swift still remains a wonderful language and has served me well. Modern features like type inference are amazing to use and implement, and syntax that can be frustrating (aka. “Semicolons everywhere”) is not present, at least in my usage. Although Apple-owned and maintained, Swift still remains open-source, with a vibrant and growing community behind it. More things are being brought into Swift, expanding upon its usage.
What makes me choose Swift the most, however, is accessibility for the future. Technology is rapidly evolving, and learning how to code is becoming an essential in today’s world, especially in education settings. I’ve seen other languages sort-of push for that, but, by far, I have seen Swift being pushed the most; with Swift being accessible on not just Linux machines, but Apple devices, especially the iPad, as well, the ability for the future to start coding and see something amazing happen as a result is becoming more of a reality. I know there are other languages like Rust and Lua, but I haven’t seen a proper solution for other devices like the iPad; Swift Playgrounds, however, provides that. I’m not pushing for Swift just because of accessibility, but giving others a chance to see their code come to life in a playground when connected to Artemis is a must. I know there’s Pythonista, but there’s a light barrier in price for it; Playgrounds, however, is free.
I know that experimenting with GTK and Qt bindings for Swift will be a bit difficult, but should (and can) be doable; it would bring about a strong (maybe not so stable) foundation for the future to build upon. In addition, Artemis may have a better chance at connecting to other devices that aren’t Android-based, though that isn’t a priority for me.
So, GTK+ or Qt?
This led me into another slight issue when making my mockups: GTK or Qt? When I first started Artemis, I went with Qt for its overall better approach and lack of popularity when compared to GTK, which isn’t a bad thing. However, the idea was attached to a Plasma-based scenario, which these mockups don’t rely on.
In theory, Swift should be able to work with Qt in some way or another; however, I am unsure if the experimental bindings are enough to create an entire desktop environment out of it. On the GTK side of things, it appears more doable as there are several repositories exploring this idea. My intention, therefore, would be for Qt; the reality would be “whatever is less painful”.
And time for the mockups…
Without further ado, I present my amazing mockups for a futuristic, Bendy-themed Artemis desktop.
For the most part, the desktop is a bit harder to distinguish between itself and Unity 7; however, there are some underlying changes that differentiate the two. To start, the interface has been flattened out with a bit of shadowing and Material Design embedded into it. This can be seen with the launcher on the right and the top menu bar. A new indicator for open apps result in a glow of the icon’s edges rather than the entire area, seen with the System Settings icon.
Another thing that makes a difference would be the Big Friendly Button (BFB). The BFB is now more prominent and different from every other icon, like in the original Unity days. Currently, the icon is of Alice Angel, but the real icon would be different; this also indicates an ability for themes and manufacturers to customize this button to their liking. It’ll still open up a Dash, like Unity, though it’d be a bit smarter.
The notifications in the mockup are now more apparent and behave a bit differently. Hovering over them won’t do the annoying “blur and hide” like in the current Unity, though it will show an ‘X’ in the corner for dismissing it (a touchpad gesture can do the same without entirely hovering over it). Clicking on them will open the respective app and work, rather than hiding (as aforementioned). A timeout option will push them into a Notification Center for later viewing; I will go over this later in the second mockup.
The design of the notifications, however, will be the most interesting; these notifications are context-aware, pulling information from the respective app to not only display data, but customize the notification. For instance, the text message from Bendy clearly shows his face masked onto the messages icon rather than a generic message icon. In theory, this would be available for any app, including third-party ones like Riot. Any app that doesn’t have that ability or doesn’t need that context-awareness will show the app icon.
The final change of note in this mockup is the top-right button; rather than showing a lot of indicators on that side, that button alone will include indicators in a panel as widgets, which will be gone over in the second mockup.
The second mockup includes more features of Artemis that weren’t displayed in the previous image.
To begin, integration between video and audio calling and Artemis will be a bit tighter. Inspired by iOS, the menu bar will turn a slightly lighter color to indicate whether you’re in the middle of a call or not. Video calls also get their own dedicated window, as if in a picture-in-picture mode. Any app will have the “(in-call)” text after the app’s title in the menu bar as a reminder.
Another major point in this mockup is the native picture-in-picture mode for videos and calls, as stated. Rather than having to implement a new version in every app, they can all us a common API for this function, regardless of website or control.
Finally, the biggest change in this mockup is clear: the Overview panel. This panel is activated by the button in the top-right (also a touchpad gesture) and gives access to information, widgets, and notifications that weren’t dismissed but timed-out. The top of the panel always greets the user for personalization, giving a sense of comfort. Below it is the date/time indicator, as well as a Conky-like message for CPU and RAM usage in “plain English”. Below it sits the Widgets area, though no widgets are present in the panel. Other indicators like networking, volume, keyboard input, etc., can be added to an Indicator widget in the panel, as well as other widgets like a clock, RSS feed reader, media playback control, and others.
Below the widgets is the Notification Center, which shows missed notifications by app name and content. These notifications also show the different types of notifications: first-party, third-party, and a first-party app without context.
This Overview panel can be adjusted and scrollable as needed for content, allowing for flexibility and customization. If the user desires, indicators can sit up in the menu bar as normal.
Although some of these ideas aren’t fully baked, the foundation for a futuristic desktop with a conversational and anticipatory interface remains. Built upon a strong (and stable, haha) foundation with Swift, the future for an open and accessible desktop environment becomes closer to a reality. If this “radical” idea is accepted and made possible, we may even change how Swift works on Linux, maybe by bringing a proper tool for editing apps.
Again, this is all nothing more than an idea; maybe some parts of this concept will be brought into the real deal, but it’s still a departure from the current situation, so nothing can be guaranteed. Nonetheless, the idea is now out there and somewhat documented. If you want to further discuss ideas, be sure to join one of the Artemis chat rooms by heading to http://artemis-project.github.io/contrib.