Dash to Panel: putting the GNOME dash inside the top bar

What joining the dash to the panel actually changes

The problem this extension addresses is a layout decision baked into GNOME. By default the dash is a separate dock overlaid at the edge of the screen, and the main panel at the top holds the clock, the system tray and the window list. Two separate bars to look at.

Dash to Panel moves the dash into the main panel so that application launchers and the system tray are combined into a single panel, which the description compares to what KDE Plasma and Windows 7 and later offer. The stated consequence is that a separate dock is no longer needed for easy access to running and favorited applications. The reason this is not a trivial reposition is in the Compatibility section: the extension manipulates the GNOME main panel directly, which means it is moving actors around inside another extension's territory rather than drawing its own widget.

That has a compatibility consequence in the useful direction too. Because it works inside the top bar rather than beside it, most other extensions that operate on the top bar should still be compatible. Two extensions fighting over the same panel is the failure mode to watch for, not an extension fighting a dock.

The project is JavaScript, GPL-2.0 licensed, on a master branch, not archived, last pushed on 2026-09-15. It has 4,455 stars and 336 open issues, which is a high open-issue count for an extension of this size and worth keeping in mind when you hit one.

The settings surface is where the work went

Once the dash is in the panel, the interesting question is what the panel can do, and the feature list answers it in detail rather than generically. The README frames it as just about every aspect of the panel being customizable, from positioning and scaling panel elements through running indicators, multi-monitor display, window previews and intellihide.

Running indicators get the most attention, which is a reasonable signal about what people notice daily. Six named styles are shown: Metro, Ciliora and Dashes as the named sets, and Squares or Segmented, Dashes, and Dots or Solid as the variants. The point of the feature is stated plainly: set position, style, weight and color so focused and unfocused applications are easy to tell apart at a glance. That is a real usability problem with a dock that has twenty icons on it, and it is the kind of thing a theme cannot fix.

Three more features carry most of the remaining weight. Live previews on hover give a window preview when you hover the launcher icon of an open application. Launch by Number lets you optionally start favorite applications from the keyboard, which is closer to Windows behavior than anything GNOME does natively. Panel intellihide hides and reveals the panel according to your own preferences, so the bar can get out of the way during full-screen work.

The additional features table then lists eight smaller ones, all marked implemented: a Show Desktop button, isolating running apps by workspace and by monitor, custom click behaviors such as launching a new window or cycling open windows or minimizing, integrating the native GNOME appMenu into the right-click secondary menu, multi-monitor support, dynamic transparency, ungrouping application windows, and export and import of settings. That last one is underrated, because a panel this configurable is not worth much if you cannot move it to a new machine.

The FAQ is really a list of what it refuses to do

The most informative part of the README is its FAQ, because every answer is a pointer to another extension. That is a project drawing a boundary around itself, and it saves a user a lot of wasted configuration.

Wanting the bottom-left notification drawer embedded in the panel like a system tray? Top Icons Plus, or AppIndicator Support. Wanting a traditional start menu? Arc Menu. Wanting to disable the hot corner? No Topleft Hot Corner. Wanting notifications somewhere other than top center? Notification Banner Reloaded. Each of those is a link to a separate extensions.gnome.org page.

Only two answers stay inside the project. Window minimize and maximize buttons are not a Dash to Panel setting at all; the answer says to turn on `Windows > Titlebar Buttons > Minimize & Maximize` in the Tweak Tool application, which is a stock GNOME preference. And resetting the extension to defaults is a single command:

dconf reset -f /org/gnome/shell/extensions/dash-to-panel/

That reset command is the single most useful line in the README for anyone who has over-configured the panel and cannot get it back. There is a comparable wiki page for the ordinary case of customizing the panel.

The themes section is short and specific: the extension works with most popular GNOME Shell themes, and two have explicitly added custom styles for it, Ciliora Tertia and Ciliora Secunda, plus Plano. That is a small list, which tells you the default appearance is meant to be correct on its own rather than dependent on a matching theme.

Installing from the extensions site or building from source

The README gives one installation route and defers the other. For the most recent official release, the instruction is to visit Dash-to-Panel at GNOME Extensions, which is extension number 1160 on that site. That page handles version matching against your GNOME release and delivers updates through the extensions app.

For a development version from source, the README points to an Installation wiki page rather than spelling out the steps. What the repository shows about the build is in the Makefile and the metadata, and it is a conventional GNOME Shell extension layout. The UUID is `[email protected]`, which matters because that string is both the install path under the user's extensions directory and the dconf key prefix you reset.

The Makefile distinguishes a local install from a system install by whether DESTDIR is set, putting a local build under the home directory's extensions folder and a system build under the share directory. Schemas are compiled with a standard tool:

glib-compile-schemas ./schemas/

Translations are handled with gettext: the Makefile extracts strings from the JavaScript source with xgettext, processes the GTK UI files with intltool-extract, and merges translations with msgmerge. The po/ directory and the schemas/ directory in the tree are those two systems. There is no runtime dependency to install, which is why package.json only has devDependencies, and the single script in it is a lint pass that runs prettier over the source and then eslint with fix:

"lint": "prettier 'src/**/*.js' --write && eslint 'src/**/*.js' --fix"

There is no test script in package.json at all, which is normal for GNOME Shell extensions and means there is no automated check that the extension loads before you install it.

The GNOME release treadmill in three tags

The releases show what maintaining a GNOME Shell extension actually costs, because GNOME breaks its extension API with each new major version and the extension has to follow.

v72, published on 2025-10-13, is labelled GNOME 49 maintenance and is the most informative of the three because it is a list of bug fixes rather than a support announcement. Six fixes are listed: a panel gradient overridden by opacity, the panel disappearing with fullscreen apps, vertical panel window preview sizing, an undefined actorData error when using intellihide, the window preview menu hiding after the first click, and a missing confirmation dialog when exiting a text editor with unsaved changes. Every one of those is a symptom of the same thing, which is that the extension manipulates GNOME's internal actors and those internals change.

v73 followed on 2026-04-01 with GNOME 50 support, credited to lufog. v74 came on 2026-09-15 with GNOME 51 support, and it is the release that matches the repository's last push date. The gaps between those dates, roughly five and a half months then five and a half months again, tell you the cadence: you are waiting on GNOME to ship, then on an extension maintainer to adapt.

So the compatibility question for anyone installing this is narrow and answerable. Check your GNOME major version against the newest tag. On a release with 336 open issues, an extension that does not list your version is a support queue rather than a taskbar.

Where the code came from, and who maintains it

The Credits section is unusually candid for an extension, and it explains a lot about the codebase.

Significant portions of the code were derived from Dash-to-Dock, which is the natural ancestor: Dash to Panel is in effect the dash-to-dock behavior relocated into the top panel. The README says the extension also leverages work done for the ZorinOS Taskbar, specifically to show window previews and allow the Dash-to-Dock dash to be embedded in the GNOME main panel. Code to set the anchor position was taken from gnome-shell-extension-bottompanel by Thoma5, and the pattern for moving panel contents is based on Frippery Move Clock by R M Yorston. Ideas for recursing child actors and assigning inline styles are credited further along in the file.

That chain matters if you are trying to understand or modify the code, because the pieces came from projects solving adjacent problems and the file is a mix of techniques rather than one coherent design.

Maintenance is two people, jderose9 and charlesg99, which is the same pair behind the UUID in the Makefile. They also ask for help directly: any issue labelled help wanted or good first issue is offered up on the Contributing wiki page. For a project this old with this many open issues, that is the practical route to getting a specific fix, and it is also how a new contributor would start.

The GPL-2.0 license is the standard choice for a GNOME Shell extension and matters in one specific way: it requires derivative works to stay GPL-2.0, and the attribution obligations mean the credit chain above has to travel with the code.

Editorial conclusion

Dash to Panel solves one problem completely: GNOME separates the dash and the top bar, and most people coming from Windows or KDE want them joined. Once the dash lives in the panel, the running indicator styles, hover previews, launch-by-number and intellihide are what make it feel like a real taskbar rather than a rearranged one. What it will not do is give you a start menu, a hidden top bar or somewhere else to put notifications, and the project is direct about that by naming a companion extension for each. The practical check before installing is your GNOME major version against the release list: v74 added GNOME 51 support on 2026-09-15, and a mismatch on a release with 336 open issues means chasing fixes you did not ask for.

Frequently asked questions

Official sources

1. home-sweet-gnome/dash-to-panel on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases