Inspiration from first run on Gnome 43 (could Haiku do something similar?)

After finally messing around with Fedora 37 today, I can say Gnome 43 literally gets what I was hoping to do with Quick Tour for Haiku! These guys have a pretty good setup assistant and a quick tour, and yeah, Fedora has had this for as long as I’ve tried out versions for fun, but the point is the entire process (first run and tour) takes 13 steps.

It’s got me excited enough I’m literally bringing the screenshots I’ve taken here so Haiku can take inspiration from this and for real, I think we can build something better :slightly_smiling_face:

Fedora 37 first gives us a welcome, which I think for Haiku is already done with the FirstBootPrompt language chooser (because to be fair Fedora has the setup with extra questions Haiku doesn’t ask because Installer is literally set up the disk and install on Haiku). But I can say Haiku definitely could use an auto setup in Installer for newbies (but that’s another topic) :slight_smile:

Privacy, which Haiku doesn’t have to worry about really, but something that every OS and environment has in it, so somehow I could see where this would help Haiku by saying why it’s a good choice for privacy.

This one is definitely useful for Haiku; there’s several 3rd party repositories that aren’t included in the box; this would be a chance for Haiku to partner with them and feature them in a first run step where someone could check the ones they wanted to be enabled.

The other one is accounts, which granted, Haiku isn’t ready for yet, but it’s something we could literally do in the future. What I don’t get is why Fedora does this first before setting up a user account, which brings me to an idea Haiku could really use!

This one is one I really want to highlight! Why doesn’t Haiku have a labelled account? Even as a single user system modeled after the classic BeOS, it should be personal and have a touch of who is using it!

After first run is done, Gnome invites us to take a tour, and out of curiosity, I did to see what it was like :slight_smile:

I will say one thing they did that I don’t think Haiku should do is put another Welcome card there. Like if someone already was welcomed to it, why do that again? We can learn from their mistake here!

For Gnome, everything is the super key for the overview, but for Haiku, it’s the Leaf menu, so we should have something like that. Speaking of which, what could be a key we could use to quickly get to the Home menu? Could it be Gnome or Windows like, where the super key does it?

There is type to search, which Haiku doesn’t have but definitely could… I wonder if Find could be remade in R2 to generate queries while the user typed (after a delay of course, so it wouldn’t freeze up the system)? For now, maybe Haiku could highlight its unique query system?

And far as I know, outside Xerox and X11 environments, BeOS was the first to do workspaces or at least on a personal workstation, have where each could have independent display settings, and to do them in a friendly way. So why not have something similar here? Or Stack and Tile could be shown here.

We don’t have the swipe gestures shown here, but this does give me an idea. When an app is launched, could a background service take a screenshot of it and then put the thumbnails (or scaled screenshots really) into a Mission Control-like view? Haiku could have something where a hot corner or similar gesture could summon it, even if it doesn’t support multi touch on everything.

And finally, they have an exit card for all this…

Bringing this post back to Haiku, back in my Chlorophyll phone shell/UI concept I had put together an idea for what our setup might look like on a phone, which looked like this…

And I think the traditional desktop Haiku could use some sort of out of box welcome as well, so if people are good with me putting together yet another concept, I’ll see if I can put together something to show to the group :slight_smile:


If I understand you correctly, that’s what the menu key in my windows keyboard does.

Okay, I’m back with a partly new, partly recycled concept for this that I hope people like :slightly_smiling_face: I’d taken a look at a quick tour concept I’d made earlier this year and again in my Chlorophyll phone shell/UI concept and while some ideas here people will recognize are reused, there’s a lot of thought that’s went into some areas, and here’s how I think Haiku could have a seamless setup that could even be better than what Gnome 43 has rn

First run concept

First things first that I hadn’t thought of before is that if there is a long FirstRun process, there should be a way to do an unattended setup where someone could script it. Or avoid it altogether, so this is something I imagine could appear before Installer asks someone to restart.


When we do restart, like in all my previous Welcome/FirstRun concepts, we’re first asked for the language with an option to sync the keyboard prefs to it.

What’s new here is that if there’s not a response, we’d automatically get an Access UI which would make the whole screen clickable, and someone could right click or press Escape or get out of it, it’d be similar to VoiceOver on macOS and a first for Be history

Otherwise, FirstRun would just continue normally. The very next step after knowing what we speak would be to increase the DPI. If items are too small, we can’t get much farther, can we? Maybe there’d be a way to just show icons to represent this before language? (The only reason I don’t try that is if Access Mode was implemented, it would have to come first).

From here, the very next step would be to make sure that we’re connected. This is pretty much the same as Chlorophyll, except I’ve drawn in a place to add the computer name and realized there needed to be a Limits button next to Settings. I imagine the mobile tether would be done over USB when full support is finished.

For those that remember the Chlorophyll concept, I’d realized the idea of syncing Haiku profiles was dream land, and started thinking of something more realistic, syncing between devices on a local network, but I never dove into it much.

Here, I start taking this concept seriously and dreaming of how this plan would work. If a protocol like Samba is what we’d be using for networking to another machine, it’d need a daemon or a background service/server running to detect we were looking at it. Or we could write our own sharing service between machines since this would be strictly Haiku-only. From there, that server would need to report what people were on the system.

And so, there’s now imagined buttons for Network or a network map (because someone might not know the name or may want a GUI), a People button in case there’s more than one person that’s on the system, and an option to choose the connection type we want (more on this in a minute). In addition to this, we can choose to use an external drive if we wanted to. Not shown here (but considered) is you’d need to authenticate to see who was on the system as well unless in Unlocked Share Mode (more on this in a minute).

I also expanded on my imagined ‘bluetooth ID’ idea and again am pretty sure this would require a proximity_auth_server or something to be running and watching events on the host, but if it saw we were on the same network and the trusted Bluetooth ID was in proximity, it’d try to authenticate using that. I’m not quite sure how it would be built (for now anyway) but sync_server would be responsible for keeping whatever machines were registered with it in sync, maybe on every login, logout, or when an app requested it? I don’t know really; it’d take a lot to pull off if Haiku did this but it wouldn’t require the cloud, just user setup, and it might just be a possibility beyond dream land. We’d also have the option of using a randomly generated PIN (which would be handled by a separate server, maybe I imagine sync_addon_server or pin_server).

If someone was found, we’d get a nice notification letting us know that:

But I also picture something else. Remember we have multiple connection types?

  • Bluetooth
  • Wifi (wireless connection on the same network)
  • Ethernet (wired connection on the same network)
  • Ethernet (port to port)
  • Remote (I haven’t imagined up how the authentication for this one would work yet without needing to use a traditional password, since the Bluetooth ID idea would be local only)

And if this someday becomes a real thing for the 4 connection types that I imagine could easily be slipstreamed into Haiku, since it already has Bluetooth and Wifi support, we’d need 3 layers of safety to keep anyone from waltzing into the same network or even outside it:

  • Isolation Mode (no access). This would block all requests and keeps things local only. This is useful if someone annoys a server or another computer with sync requests. It might be possible to do by-device blacklisting, but this would be the simplest solution short term anyway.
  • Share Mode. This is the recommended default; in this mode, Bluetooth ID is a must, optionally with a PIN. If the system doesn’t have Bluetooth, like a server or headless workstation, it’d look for the same network or domain, and then would have someone authenticate with either an external key made from that device or a network served key. This, imho, would be harder to implement than the Bluetooth idea.
  • Unlocked Share Mode. This is the crazy mode imagined up below. I think this would be useful if someone needed to setup a whole payload of machines or something, like for school. If using this, no keys or any sort of 2-factor authentication is used at all. It’s dangerous because it means any machine on that network can read and copy data from it, but it conveniently leaves the server open so either scripted/unattended setups or a batch of machines could copy data concurrently without all needing to authenticate to do it. I imagine a timeout setting would be used for this mode, and also before someone calls me a total idiot, used on a closed network not connected to the wider Internet. Such warnings would be in the UI.

Moving on from that, another idea that I’ve thought out is what would be synced? Back with the Chlorophyll idea i just had ‘1/10’ but not what things were. Something that might take extra time is copying system states over the network, but maybe we could have that as an option in case someone wanted an exact clone of the same system on a new one?

I imagine a copy of a person (and btw, this is what user profiles would be based on, specially flagged person files assigned to the system with metadata attached to them, in a unique Haiku Way rather than user accounts like every other system has); how this would work is still something I’m trying to figure out but it’s fun to imagine up until I can present something that’d make sense. For now, I imagine home data, packages, and preferences would be the things that would copy over.

The same process would work for a whole system, but instead of just copying over one person’s stuff, it’d copy over everyone (and give the option to skip home data to save time):

When everything was done, it’d write a sync log (useful whether everything worked out or ended in an error) and clean up:

If we did skip the sync, we could have a system assigned person so that other machines could pick it up later. We could migrate people into the system from things like external drives (or go back to net sync), set up multiuser (a Glass Elevator dream for R2) but I think this step would look something like this:

Time could be set on the spot, using the same UI as the Time preferences (previous concepts didn’t use Haiku’s layout):

And in keeping with the sync_server idea, we could sync from something like or do that from the local network if we wanted to:

This is nothing new to my concepts (just a step showing Haiku is committed to privacy with options to share hardware data and reports on automatic) but also has an “always make KDL restarts automatic” switch here:

Again, nothing new, but the thing is I have begun to think of how this would work…

So instead of a generic assistant like before, I think if this ever were to be real, it’d be a set of new queries that’d live inside the usual place, but in a subfolder called ‘actions’, ‘smart_queries’ or whatever. When enabled, Haiku would copy them from say like /boot/system/add-ons/smart_queries to the person’s home and scan for both traditional and ‘smart’ queries using smart_query_server. What would then happen is when Find was opened, anything matching that action would be recognized and launch.

And the user could add whatever they wanted with a nice little app, maybe in Preferences, to manage, restore, delete, and make their own actions. They could be scriptable sets of stuff like Shortcuts on iOS, a launcher as environments on Gnu/Linux call them, or filters for sorting files. But whatever someone chose, they could make their own and share them. I imagine these ‘smart’ queries could exist as bundles or loosely compressed packages, containing the scripts inside one file. And… other than adding this functionality into Find, making a new server and preflet, it wouldn’t be too hard to do. Maybe there could be a QueryDepot for distributing them in the Haiku community, but that’s a concept for another time :laughing:

Again, same idea talked about earlier (and in Chlorophyll) so I won’t write it twice. But what’s new here from last time is that someone could import the saved devices from a flash drive or similar to the new machine, as well as pairing and setting up a new one…

From there, we’d be totally done in about 19 steps (or if someone were to sync over everything, in about 5!)

I imagine from here, things would fade into a nice animation saying ‘Welcome to Haiku’ in whatever language we had set, which brings me to Part 2 of this concept, the Quick Tour!

Quick Tour v2 concept

This would play on first run when Haiku was first installed (it’d look for a file, and if it wasn’t there, it’d go ahead). For read-only environments, or if someone doesn’t want to see it, there’d be a skip button.

These are pretty much copied over from an earlier concept, and all the text is on them, but they’d look like this:

1/8: Desktop

2/8: Home

3/8: Leaf

4/8: HaikuDepot

5/8: Preferences (nice window shown here, although maybe the Deskbar one would be a better idea so it looks the same?)

6/8: WebPositive

7/8: Tabbing (a quick stop animation showing the tabbing process would play here, and I do have the frames, but since there’s already so many pics, there’s just this one):

8/8: Forums

And that, everyone, is my idea for both the FirstRun/setup process, some ideas in between, and a v2 of the QuickTour. Hope everyone enjoys the time I’ve poured into these as experimental Glass Elevator (#GlassElevator) ideas that I hope someday are useful to somebody here, and happy holidays! :smiley:

(added note just in case anyone gets confused: These are all imaginary/concept ideas; none of this is a real part of Haiku!)


A system tour a la windows xp could be nice.

But doe the first run what is the point to ask all these irrelevant questions?
Should NTP be enabled? Yes it should.
Why ask for network at start?
Why ask for screen scaling when we can make a pretty good guess already?

Some ideas for configuring the system are nice, like treating severall computers as one unit (akin to using the same appleID)
but i dont see what this has to do with the first run, currently we ask the very minimal stuff we need in the installers firstrun and that is sufficient


If this could install a web browser from HaikuPorts, we could avoid having to have a native, bundled browser. Can this introduction be done without HTML?

Just read USERGUIDE… omfg

Userguide is HTML and works with a web browser only. I think doing things independently of the web browser would be more streamlined.

Web+ comes with Haiku… Why need other complicated things? KISS
Just open and RTFM (userguide).

You call making every piece if documentation dependent on Web+ KISS eligible? Web+ is the only app that is presently included with the current OS that requires a vector unit in the CPU and any significant amount of RAM. Is that a simple option?

If there was a small portion of WebKit that could be used to render hypertext from a binary, that would be simpler. Having compiled WebKit a few times, I know half of the library is the JavaScript JIT. Why make something simple and heavy? I’d rather have modularity to let the unused parts stay unloaded. Simple and inefficient is not “keep it simple, stupid” eligible.

Guys I was hoping that this would spark ideas and Glass Elevator stuff, not be like a spot to argue over HTML and Web+


What, why? ​ ​

Never mind. A native browser is important.

Why using the WIN key when there is a LEAF key? :grin:
BTW, there’s a menu key (most times ignored) that you can use