What is TrayBrowser

Why cannot this web page / application / interface / game / etc. just run as normal windowed application and sit in system tray, at my beck and call? Why does it need a browser, why do I have to switch tabs, keep another window open on taskbar, etc.? Yes, 'make it an application' can be useful but it is still a browser with its browser functions excessive for the application, and it does not sit in the system tray at all, so I need to toggle it, minimize it and more. Why couldn't they just make a normal tray-based application out of it instead of web client?

Why can't I make my web application be just a windowed one easily? So that it loads from server, but works on the user desktop as normally as any other desktop application does? Why can't I make browsers sit in the system tray with an icon for it? Why do I have to learn another whole large nodejs framework for it, learn its complex API and redesign all my web application for its split and asynchronous application model? Why do I have to compile from monstrous nodejs bulk, manage and update it separately from its web representation? Why do I have to build my own native application from scratch if I don't want to use this framework?

TrayBrowser solves both.

You can load almost any web page into TrayBrowser and make it sit in the system tray, at your beck and call. If the page does not do anything nasty like opening additional tabs and popups, it will work properly under TrayBrowser just out of the box. Want to have your favorite forum there? Yes. Webmail? Probably yes. Some online game? It also should work, with a little setting to use your GPU enabled. Some online handbook? Yes. Anything else? Just try. It will most probably just run. For very simple use, you can just pass URL and some parameters from the command line, avoiding the need to write configuration file at all.

With a minimal set of mostly optional settings, it loads your web application into embedded browser and makes it sit in the system tray, available to user anytime, presented like almost any normal tray-based application. With a just a minimal set of optional, mostly synchronous and simple API calls plus few optional events, you can resize its window as you see fit, show and hide it when required, and do more handy things, erasing the difference between web and native application. Of course it's not a panacea, it keeps things simple and does not give you in-depth access to the system like the one existing framework does, but it's enough for web-native applications to cross that desktop line and still be relying on just browser to do their job.

TrayBrowser does not need web application to be redesigned. At all. Most of the time, single tabbed applications will run in TrayBrowser much like they would under normal browser. You do not even need to use any API calls and finetune most of the settings, actually you may be okay with just setting window size and supplying your application URL to run, relying on the other sensible defaults provided.

TrayBrowser is more than just a tray browser

- Resizing window from inside JS code to make sure it stays aligned with the interface needs? Yes, and it will also correct size according to screen scaling, defeating this usual issue of rightmost and bottommost document lines not being visible. It will also inform JS code about the actual size.

- Non-standard tray positions in Windows? Yes. TrayBrowser does its best to detect where tray icons really are and snaps to their supposed location. TrayBrowser window can also be snapped to edges instead of tray or just centered. Staying on top of other windows? Yes. Auto-hiding to tray when user clicks elsewhere? Yes, and by default.

- Normal OS-like windows. Yes, window does not need to be borderless. It may have normal OS UI title bar and borders, no problem. It may have close button, with an option of handling it inside application JS code. It may have minimize and maximize buttons, automatic or also handled by application JS code.

- Borderless windows. You want to draw all the application UI in browser including title bar and borders with your elements? Sure. But what about dragging such window by title bar? TrayBrowser supports custom drag region you may designate via its JS API to make sure movable but borderless window can be dragged.

- How about windows being movable and not tied to tray ? Yes. Show on taskbar? Maximize? Yes. Minimize to taskbar? Yes. Can window with normal OS borders be resizeable by user like a normal OS window? Also yes! Getting some event when window gets resized to adjust UI? Absolutely.

- Fullscreen and kiosk modes that are not user-controllable. Sure, TrayBrowser can do that. Either full desktop or the whole monitor. Additionally, there is multi-monitor kiosk mode which allows browser to occupy the whole desktop. All monitors included. No more struggling with browser kiosk mode settings, it is as simple as just running TrayBrowser.

- So, is there real multi-monitor support? Yes, and it is done to be more or less seamless. Tray-tied applications will show on the monitor tray icon is clicked on, and switch monitors on another click elsewhere. Movable windows remember position or monitor to start on between TrayBrowser restarts. TrayBrowser won't allow window to size beyond monitor. TrayBrowser will (optionally) clamp window to monitor edges when it's moved, not allowing user to position window between monitors or out of monitor deliberately. Also there is native scaling support, so you size window in browser dots and not screen pixels, to make sure document size matches. Scaling is adhered to, even if different monitors have different scaling, fixed sized windows wil resize according to the active monitor scaling in order to maintain browser size. If you are doing something tricky (i.e. some game that does not need browser to scale it), scaling support behavior optionally can be attuned a little or ignored completely, displaying content at real monitor pixel size.

- Changing window title? Yes. Tray icon hint? Yes. Adding elements to tray icon menu? Yes. Even hiding tray icon and making non-tray application window that i.e. exits on normal close button press? Not a tray browser already, but yes, this is absolutely possible. Native tray icon notifications? Sure thing.

- What about browser functions? Right-click menu is disabled by default and you can handle right clicks from the application in a normal JS way. Drag-and-drop is supported. User-initiated refresh can be enabled or disabled. Browser search function can be enabled or disabled. Cut-copy-paste can be enabled or disabled. Printing option, also with auto-print without waiting for user to click on Print button in browser. Download function can be disabled. Even whole TrayBrowser API can be disabled to make sure loaded page cannot use any TrayBrowser JS API. Certificate errors can also optionally be ignored (useful for some legacy applications). Running native browser debugging interface to debug application? Can be enabled optionally. Changing User-Agent header contents? Yes, definitely. Enabling browser GPU acceleration support for putting online web-based game into fullscreen or kiosk mode? Yes, this can also be enabled, but to keep power usage sane, it is disabled by default. Websockets, audio and video support? Yes (although codec set is free from patented ones). Everything that CEF/Chromium embedded browser can normally provide is technically there.

- Command line control? Yes. On start, command line (except TrayBrowser own settings set via one if allowed) is passed to the application. Besides showing on being started for second time, TrayBrowser allows you to send command line arguments passed to the running instance, and thus make already running application perform some actions depending on the arguments passed to the executable.

- Possibility to separate browser storage between different applications and place them into the user profile / home directory under directory with name related to the application? Totally. Can we clear cookies and cache on start / exit? Yes, although it takes some little but noticeable machine time to do so.

- Customizability and branding? Custom application and tray icon can be loaded. Settings and icon can be embedded inside the TrayBrowser executable or provided in separate configuration files, and even at multiple levels of such. Texts (including default error page) can be changed. Etc.

- Cross-platform support? Yes. Windows support is polished. Linux and MacOS support is at a bit lower level and Linux will probably require you to compile TrayBrowser for your distribution yourself, but most of the things TrayBrowser can do work the same way under all platforms.

- So how complex is to configure and use all this? Not complex at all. Just a bunch of simple and mostly optional settings, extremely simple synchronous JS API, optional to use, and a minor set of events to optionally handle from the web application. That's all it takes to cross the desktop application boundary. And again, all is optional, there is totally nothing mandatory to set and use except the application / web page URL.

- The last but not least, TrayBrowser supports working with multiple windows. Yes, you can use multiple independent windows in your application, opening and closing them when necessary, like native applications do. Sending arbitrary text messages between application windows is also possible with the simple TrayBrowser JS API.

- And there is still more. Check configuration parameters (settings) and API reference to see what else TrayBrowser can do.

- So, is this all free and opensource, available for me to take and use for my purposes? Surely so. TrayBrowser own source code is licensed under permissive 3-clause BSD license and is made publicly available. TrayBrowser binaries are freely available for download, reuse and redistribution. Integrated components, including browser and other libraries, have opened source as well and allow redistribution by their respective licenses. So it all is as open as it can be.

Download

[to be written]

Quick start

[to be written]

Moving forward

[to be written]

For web application developers

[to be written]

Under the hood

[to be written]

Version 3.0 already? Yes. This is indeed a third generation of TrayBrowser, with each major version denoting significant platform change. It's just the first two were never published openly. The very first one, the very proof of concept and the idea, was written in 2010 for internal ISP purposes, but was Windows-only and based on embedded IE browser. The second one was based on Electron but had a lot of quirks and thus was not viable to publish as well. None of them supported multiple windows and this much options even closely. Also, both previous versions were not ready to be open sourced due to different surrounding reasons. This one is a full and thorough rewrite, designed to be totally usable and fully open source.

Licensing and branding

[to be written]

Extending TrayBrowser

[to be written]

Support

[to be written]

Patches, feature requests and suggestions

[to be written]

Thanks and greetings

[to be written]

[add more]