[stefanodangelo]

The top bar's tab buttons are now rendered from one list, navItems, instead of hand-written markup. Same tabs, order and conditions, so there is no visual change. A feature adds its tab by adding one entry to the list.

This is the first commit of the earlier navigation-rail work, trimmed as discussed; the grouped top bar will follow as a separate PR.

[stefanodangelo]

I've got a few questions about this PR:

• On a phone I used a top strip. Would you prefer a drawer or a bottom bar?
• When the rail is collapsed the language select is hidden, because the names don't fit. Is that fine, or should I show a short code instead?

[decay71]

Thanks, this is clean work and it ran without problems on our side in mock mode.

Before we go further I would like to understand the idea behind putting the navigation on the left. Do you have that many tabs planned (preview, history, queue, favorites and so on), or do you think the left side is better for other reasons?

From my side the width is the critical resource. The dashboard puts the ACE cards, the four toolhead cards and the wiring next to each other, and in head mode with several ACEs it gets tight already. With the rail open, at 1024 px the fourth toolhead card drops into a second row, while the current top bar keeps all four in one row. In return we gain only about 50 px of height.

If more tabs are coming, I would rather group them: for example one "Print" tab in the top bar, and inside it a second row of tabs for preview, history, queue and so on. That keeps the top bar short however many features we add, and it works on touch screens without hover menus.

What I would take right away is the first commit: rendering the tabs from one railItems list is a good change on its own, and it fits a grouped menu as well. What do you think?

On the printer it only shows up as the Fluidd camera tile (?panel=1), where the rail is not rendered anyway.

[stefanodangelo]

Thanks for the feedback!

To answer your question: yes, more tabs are coming (history, queue, favorites and a control tab), and that is why I put the navigation on the left. I didn't weigh the width cost enough, so that's a good call. I reproduced your 1024 px and indeed you're right - your grouped idea seems like a good solution for what I had planned.

I'd keep four entries in the top bar: Loadout (today's Dashboard, which I find a bit confusing because), Print Hub, Spools and Config. Print Hub is the group, and opening it shows a second row of tabs: Control, History, Queue, Favorites. This screenshot shows the Loadout page at 1024 px with all four toolhead cards on one row.

This other screenshot is instead a mock-up of Print Hub → Control.

Note: The Control tab will have the camera, the console and the print controls that already exist in the printer's own Fluidd/Moonraker interface. It only routes them into the multiACE page, so everything is in one place and you don't switch between two interfaces. It doesn't replace anything in Fluidd.

As a plan: I'll trim this PR to its first commit, which renders the tabs from one list. I'll rename the list from railItems to navItems, since it no longer has anything to do with a rail, and add an optional group key so a tab can say which group it sits under. I'll update the title and description to match. It changes nothing visually, so you can take it right away. The grouped bar then follows as a separate PR, and the Print Hub entry only appears once its first sub-tab exists, so there is never an empty entry. I'll keep the rail commits on a side branch in case they're useful later.
How does this sound?

[decay71]

Sounds good, go ahead with trimming this PR to the first commit and the separate grouped-bar PR.
One question: your sentence about renaming Dashboard to Loadout got cut off after "because" :). What do you find confusing about "Dashboard"? It has been called that from the start and the README and guides use the name, so I would only rename it with a good reason.

[stefanodangelo]

Pardon, I didn't notice that. Anyway it is a bit confusing because it's a bit generic and it sounds like a tab containing a report of some sort, but maybe that's just me. I can always park that and/or do it later.

[decay71]

No problem, I see your point, but I would keep "Dashboard". It is the overview of ACEs and heads and has been called that from the start, and the README and guides use it. Let's park the rename and leave it out of the trimmed PR and the grouped-bar PR.