Ideas for Haiku R2 from the "Gonx" concept

I’d found the Gonx concept for BeOS (apparently it was supposed to be an ‘R7’ concept, as the concept mentions “an other beos r7 nickname :-o” in one of the screenshots). Please note, this idea is NOT mine, but had appeared on a French website long before. Far as I know, Gonx is merely artwork of something the author had imagined, and no code was committed to it (if anyone knows, and I’m wrong… let me know).

Note: I managed to find an archived copy of original website on the Internet Archive. Gonx was featured on “contito!” and a link to the site (thanks to the Archive) is here:

But anyway, I’m posting about this here because there were a lot of mesmerizingly cool things about this that I have not seen in the actual BeOS (or in any Be fork or related desktop modeled after the BeOS (like the customized Xfce on Zeven OS).

And again, Gonx is NOT my work!


1. NetOptimist has query support.

Next to Bookmarks and a drop-down menu for Go, NetOptimist has a Query box. There is of course the unified search box in Chrome (I think called the Omnibox?), the ‘awesome bar’ in Firefox, and more recently, the same feature in Safari which all search through bookmarks, web search results, and browser history.

And at least, from Firefox, I know that you can tag bookmarks, so it comes very close to achieving this idea. But what none of them do is actually give the bookmarks metadata – imagine if you could not only sort bookmarks into folders and tag them, but you could instantly search for them with something like Spotlight built into the bookmarks folder by metadata, like “show me results related to fishing sorted by most recent”. Not only would the browser show results matching fishing, but it would parse the request into parts, looking for boats, fishing stores/shops, or other results matching the criteria, and of course sort it by date.

2. nPlayer has bookmark(s) support

Distinct from file history or playlists, this idea would be really cool, as it would allow the media player to keep a list of tagged files from various sources, including the Web, in one location. Paired with the idea of having a location bar and nav buttons in the player, this would definitely be an interesting feature for the modern age with Internet radio. Again, I have yet to see this on BeOS/Haiku, although an equivalent feature is in Apple Music, Spotify, etc.

3. Built in Help

Of course, the obvious thing here is the support for multiple environments/profiles or ‘users’, which is ubiquitous to every modern OS, and I know is something Haiku is working on. But my focus when I see this screenshot is the nice link to Help in the bottom right corner. This is something sorely needed in Haiku, and is a nice touch in the Gonx concept.

4. Remote connections

One thing that the Mac can do in the Finder (10.0+) is connect to remote resources, including FTP shares. A similar feature also exists in Konqueror and as ‘map network drive’ in Windows’ File Explorer. In addition, NT could (and still can) also connect to network clients as well. This is definitely something worth exploring for Haiku, most likely on the Nightlies on the long road to R2 after the glorious day R1 has at last been shipped.

5. Quick access controls

The Deskbar is an awesome little tool, but I noticed that Gonx divided it up into basically what DockBert is today, desktop applets and the clock in the top right corner like the Mac, a movable palette with Settings, the home folder, and an exit to Maui on it, and on the right side in a sidebar of sorts, Help, News, an Offline switch, Workspaces, and a Temp area.

While the floating launcher has become LaunchBox, and Workspaces can be dragged out as a replicant, Haiku doesn’t have a quick on/off switch for ‘airplane mode’ (or for determining system-wide away status). And while having News and Temp always pinned would be annoying, the idea of the offline/online button, Help, and Workspaces would be worth consideration.

Modern examples of what Gonx got right appear in iOS, macOS Yosemite and higher, Gnome 3, and in Windows 10, where each has an area for quick controls.

6. Tweaks for the Deskbar

(Obviously, there’s not much for me to say in terms of file sharing, which I do see is the main focus of this screenshot, as there are clients available via the Depot/repos that handle this task well, far as I know).

But what I did want to point out here is the conceptualized Deskbar on the bottom edge, which sports a menu with equivalents to zoom (or maximize), hide (or minimize) and close controls and a label that appears on hover.

Running applications have an indicator under them like the Dock on macOS, and I personally see where little improvements like this would make the Deskbar more intuitive. Maybe since DockBert already does this… maybe add it as an official add-on to Haiku?

7. Multiple desktops

As a guy who tries his personal best to have fun looking at UX, I would concede a 3D desktop cube is a novelty at best, and I can truly say this as I used to spend hours having fun with Compiz/Beryl. The various effects make a nice toy, but a lot of the plugins, like wobbly windows and cover flow tab switching are eye candy at best. Even macOS, which had the 3D login cube effect, removed it.

But I do think Gonx was ahead of its time here, as there does need to be something higher than a desktop switching widget to effectively manage the desktop. BeOS was an early pioneer of this, with an intuitive way for switching between workspaces with a fluidity X didn’t quite have, and even supported switching color depth in between them – which Haiku can do, but the thing is, it’s stayed this way while others have adopted ways to move forward.

As real time examples of how workspaces have evolved, Gnome Shell, the modern Mac/iOS, and Windows 10 all have workspace views where multiple desktops and applications are displayed over the application windows like a birds-eye view of it. I’d almost suggest that maybe in R2 or R3, Haiku could adopt a more dynamic workspace manager.

8. Unified toolbars

One thing that Gnome 3 and the Mac have both begun to do is to unify the toolbars in applications, and although the title tabs on the apps below remain separate, Gonx definitely had an early idea of saving vertical space by bringing the menus and buttons together where it made sense to do so.

(Notice the background window with a passel of buttons has most of them on the bottom, whereas the foreground window has them on the top with the menus).

9. Pop out home folder

Similar to the unified buttons idea, Gonx actually had something interesting going on here. It appears to be similar to the circular menus I remember mice in the late 90’s had as a plugin, or the early form of what would later become Stacks on the Mac in Leopard, (which was recently enhanced in Mojave), and is something that I truly believe would be beneficial to Haiku in something similar to this.

I mention all of these because this was the last concept done back in the OpenBeOS days by the looks of it. It definitely has the experimental title tabs of Dano and Zeta, and so I imagine was something done around that time.

I’m not saying the idea of Gonx was perfect, as there are areas in here (like the three buttons being squeezed together) that I see probably could use continued refinement. But what I am saying is that the seed of the idea is there in a lot of the creator’s work, and it’s definitely something worth Haiku’s time to maybe use as design inspiration for Release 2 when the day comes…

Anyway, just thought I’d offer my thoughts on these, and if nothing else, maybe they’ll actually make it in someday in the future. Hopefully the original author won’t mind me pasting these in and commenting on his work…


I don’t like the UI changes actually… there are features I’d like Haiku to have but this isn’t what I’d want it to look like not even remotely. It’s like hey we can waste UI space on not one but two! sides of the window now!

Preventing windows from moving off screen is a big deal IMO, or at least making it so they can be easily corralled back into the desktop as well as auto tiling by dragging to edges or corners, showing birds eye view of all desktops by moving the mouse to a corner would be nice to have and is something I always do in KDE or Compiz for instance.

As far as bookmarks, I’d want something that could sync to a generic cloud file storage, either self hosted etc… or p2p to my other PC’s and devices. Functioning something like Firefox’s Sync feature… just with less requirement for dependence on any single company. As to query support (query support in the URL bar should only be via shortcut, like “g search term” for a google search, “e something to buy” for an ebay search) otherwise searches should always asssume you have supplied a URL,


Haiku already has an ability to browse SMB shares through FUSE. It wouldn’t be much of a stretch to add FTP support.

Haiku also already has the native netfs that supports queries. It would perhaps be nice if it was more obvious how to use it from a GUI.

1 Like

I was definitely a fan of the Gonx UI/UX mockups when they were shared way back.


I found an archived copy of the ‘contito!’ website where Gonx was hosted ( on the Internet Archive.


Gonx (index page):

Gonx (“see more” page):

Gonx (“in action” page):

FTP resources the author used for Gonx (links from the Gonx pages; be aware the file links may or may not work anymore):

Anyway, hope all this helps. I really hope that the original author of Gonx brings back his website for the world to freely see again. Even if not, at least it gets to live on through the Internet Archive’s Wayback Machine.

(But again, just to be clear to all, these are not mine in any way! I’m simply posting these for historical/educational purposes… and hope it’s okay with the author that I did so!)

This concept completely misunderstand the main strength of BeOS / Haiku UI: “Zoom” and “Close” buttons are located on the opposite ends of the title bar, making it more difficult to accidentally miss and close the window instead of zooming. Besides, the buttons themselves are very tiny, which makes using them difficult and troublesome, and increases the risk of missing the intended button, — risk that could be easily eliminated.

And yes, all these graphic bells and whistles of widening the title bar several pixels from the left of the window is nice to see, but really impractical. We had something like that already, in the “Enlightenment” Window Manager for Linux. Everyone tried it, since it offers a lot of customizations for title bars and looks pretty, but no-one uses it for a long time, since it is impractical.

This concept is nice looking, but unusable.


I wonder if someone could try building it and see? :slight_smile: I know that the window and tab chrome seem to be the most common criticism of Cotito’s Gonx concept, but I personally think that if the buttons were magnifiable, I’d bet his idea might just work. :wink: After all, several free desktop environment themes, Mac OS 10.0+, and Windows 95+ have their buttons in a group of three.

That is a reasonable point. A Gonx-like alternate window decorator could be coded up, but I think with the current app_server it would need to be a squared off version. It would then be fairly close to the standard decorator. But it might still be interesting to try. I assume the blue part at the top which is thicker than the sides is also draggable.

The other things I agree are interesting in the concept is the combined menu and tool bar, and the media player bookmarks. Otherwise I think it seems a bit dated.

1 Like

I still think a fully modular replicant-ified Deskbar would be interesting… where deskbar would just become a container with a + button when empty kind of like KDE plasma taken even further and less bloaty.

Then Deskbar could be whatever the user wants… with a good default profile of course.

Personally I’d probably have something like a typeahead menu + typeahead FS search + basic task list + media player replicant and Tray… but obviously some people would want something different. Being a personal desktop OS was very much what BeOS was about though.

That’s not very inline with what we are trying to do for Haiku. The DeskBar is still far from showing its full potential, and you can already extend it using replicants.

Anyway, the “sane defaults, not maximum configurability” principle should apply. I think by ow everyone agrees that typeahead search has to be added in one way or another in the menu. Not sure about the filesystem, I’d say that’s more of a Tracker job, but it would be a rather big change to how it works now. Something worth experimenting with.

Media player replicant is… up to your media player, and already possible.

As for the task list, the problem is that it is quite important in the way one uses Haiku. One thing is that we have lots of windows, for example because of Tracker spatial mode, but not only. This isn’t usually the case on other systems. So, we need a powerful tool to manage all these windows, and that’s what DeskBar should be, at its core. If you make this optional in some way, you make the system unusable.

The current app/window list is way too limited in what it allows. Ideally, application should be able to add items to their DeskBar menu, to allow easy access to some of the application functions. This could be nice for example for… a MediaPlayer, which could add your play control there. Or… for Tracker, which could add a typeahead fs search easily reachable from there. Wouldn’t it make sense? Tracker > Search. Media Player > Next. Browser > New Window. or Browser > Downloads, even if the window is currently closed.

This would be a little like the application global menu in MacOS, except easily reachable also for apps in the background. There should be some guidelines for apps to use it sparsely and not put all their functionality in there. I can imagine some replicants would be replaced entirely by functionality like this, if they have nothing else to do than show a menu (and maybe if we allow them to edit the application icon as they run, too).

As you can see, by doing this we provide some extra service to applications. We should not make it optional, because otherwise apps will be forced to provide their functionalities in some other way.

1 Like

Yes, and this way caused a lot of frustration exactly because it is so easy to miss the intended button. Note that in Windows 7+ the buttons are much larger, in Windows 10 they are 46 x 34 pixels, 6 times larger than in Windows 95, and they are still easy to miss for people with special needs who can’t control the cursor movement very well.

This would be very bad. Crucial elements of the UI, like “Close” button, should not change its size, no matter what.

Think about the criteria for magnification. On the one hand, the button can be magnified only when the cursor is placed over the tiny button. That means the user still has to carefully aim at the tiny button first, and if he missed by a pixel and hovers over a button he doesn’t intend to click, it will take now a longer movement of the mouse to move away from the button he doesn’t want to click. On the other hand, the button can be magnified when the cursor is close to it, but that will lead to windows being accidentally minimized, maximized or closed when the cursor stays in the proximity to one of the buttons but outside of the window, and the window’s button “feels” the cursor nearby and enlarges itself to be clicked.

Controls that manage the window should never change their size or position.

1 Like

In fact, that just compensates for increased pixel density of current displays. Physically, the buttons are still about the same size.

No, they are not. They just appear as the same size to the eye. But there are now much more pixels for a mouse to aim to, since mouse movement recognition does not depend on screen’s pixel density.

Consider moving a mouse vertically to a “close” button on a non-maximized window in Windows 10: you have now about 30 pixels to stop your mouse’s movement, that’s twice as much pixels to choose from, comparing to just 13 pixels in Windows 95. This eases aiming. Now, the buttons are not square, they are much wider; that adds about 46 pixels to choose from horizontally, comparing to only 15 in Windows 95.
2019-03-25_110209 win95

Yes, but your pixels are a lot smaller, and your mouse set to move more pixels for the same physical movement than it was on a 14" 640x480 pixel in 1995.

Unless, of course, you are running Windows on a 17" 1366x768 display, in that case the pixel density is indeed about the same. But if you have a 12" laptop or a 1080p display, you likely have something like 125 dpi, rather than 72 to 96 in typical Windows 95 setup.

The wider buttons do help with accidentally clicking the neighbor button, but indeed Haiku’s solution of separating the buttons completely is even better.

That’s exactly my point.

This is straight from Be Inc itself though. I have seen these title bars first hand. They are in the PowerPC version of Dano. If you skip through this videotowards the middle part, you too can see them: BeOS PowerPC (including Dano build)

1 Like

I look forward to making my own Be concept to do the explaining instead of words. :slight_smile:

It may not be inline with your ideals, but it is inline with those of BeOS which included using small modular programs to do a task as well as sane defaults… configurability is not at odds with any aspect of BeOS or Be principles. Hostility toward configurability is toxic towards personal desktop computing. It is neeedful to maintain a careful balance of software maintainability for developers while at the same time developers must not dictate unnecessary limits on what users can do. The fact that deskbar can even be dragged around the into different layouts, and the existence of replicants is evidence that Be developers were not afraid of configurability. R2 should take up that spirit and make something innovative and powerful out of it. While at the same time preserving the look and feel of BeOS as default itself should probably remain a goal of any such changes.

If anything Deskbar is a fine example of an exception to Be ideals… as it does too much all in one program. Especially for R2, Deskbar should probably be broken up into separate applets. This would also completely avoid any tussle over what goes in and what doesn’t or what is best for R2, just let the best setup win organically.

And no none of what I said is possible today, yes you can put replicants on the desktop, but I mean in the Deskbar itself… which definitely isn’t possible AFAIK. Management of replicants is also rather poor today and could use improvement.

Dunno what this thing could be called a DeskHub or RepliBar spring to mind :stuck_out_tongue:

It’s not about my ideals. What I care about here is that the OS should provide services to apps, and apps should be able to rely on these services. For example, we have made stack and tile part of the API. Applications can assume it’s there, and, for example, the Koder editor does and has no other way of managing multiple documents. So any decorator written for Haiku must provide support in some way.

Likewise for what I wrote about: I expect DeskBar to allow applications to have a menu shown here, in a way that applications can rely on it. This means DeskBar has to handle that in a non-optional way. It does not prevent customization of the appearance and exact implementation, but the feature should be there. And this does not match well with a fully customizable add on based approach.