[Feature Request]: Set option `Top bar menu options`

[mijuku233]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

There have been complaints about floating menu options. https://github.com/Comfy-Org/ComfyUI_frontend/pull/726#issuecomment-2375878063 https://github.com/Comfy-Org/ComfyUI_frontend/pull/933#issuecomment-2376486703

Float panels will encroach on the editable area of ​​the canvas, including the float menu options, which greatly affects the workflow editing/using experience. The top bar menu option should not be removed, it should be kept as one of the settings options.

The feature Opened workflows tabs is great! So it would be better if the top bar is only used for Opened workflows tabs and menu options.

For custom plugins, a separate sidebar should be added to place buttons for custom plugins. Instead of letting them abuse float panels or take up valuable space in the top bar.

Suddenly I realized that this is a difficult problem to solve. The top bar and side bar of the new front end can be used to place buttons for custom plug-ins, but the author of the custom plug-in still has to add floating buttons that occupy the canvas.

The impact of float panels on workflow editing/use: (I cannot edit the nodes in the red box directly. I have to move the canvas first before I can edit them.)

Changes to editable areas:

Proposed workflow

1. Go to ....
2. Press ....
3. ...

Additional information

No response

[JorgeR81]

I agree there should be an option to have the queue options in the top bar. 

---

About the custom floating panels, where they always like this ? Or did they break after the Top Bar changes ? Other custom nodes ( e.g. rgthree ) are still perfectly integrated in the Top Bar.

---

I also think only icons should be allowed in the Top Bar. With tooltips, there is no need for text. The Top Bar would look better and there would be plenty of space for custom buttons.

We could also have a separator ( e.g. vertical line ), for buttons of different custom nodes. And if we reach a point where all the buttons don't fit on a single row, the Top Bar could be displayed in 2 rows automatically.

An extra Top Bar, just for custom options, would be a waste of space, for most users. But we could have an option to "display custom options on a separeted top bar".

Custom buttons on the sidebar should only be used, if there is a good reason ( e.g. if it's necessary to navigate through many custom items ).

[yoland68]

The main reason we decided to put the "Queue Prompt" button as a centered floating widget is to avoid people having the need to go to corner of the screen to click "Queue Prompt" and some basic operation.

I think what you need is an easy navigation option ("Hand" mode) and/or an option to hide all UI temporarily when you are just operating on the graph

[mijuku233]

The main reason we decided to put the "Queue Prompt" button as a centered floating widget is to avoid people having the need to go to corner of the screen to click "Queue Prompt" and some basic operation.

I think what you need is an easy navigation option ("Hand" mode) and/or an option to hide all UI temporarily when you are just operating on the graph

For many people, Top Bar Menu Options is better, it does not encroach on the editable area of ​​the canvas, and does not waste free space in the top bar. The main reason some people complain is that the 1.3 version completely removed the Top Bar Menu Options, and we are forced to use the Floating Menu Options. It should not be removed, it should be optional, and users should not be forced to use the floating menu options.

[mijuku233]

The main reason we decided to put the "Queue Prompt" button as a centered floating widget is to avoid people having the need to go to corner of the screen to click "Queue Prompt" and some basic operation.

I think what you need is an easy navigation option ("Hand" mode) and/or an option to hide all UI temporarily when you are just operating on the graph

("Hand" mode) does not solve the problem, it only changes the position of the canvas editable area that is encroached. It is very annoying that floating panels encroach on the canvas, and after raising this issue, I deleted any plugins with floating panels.

[yoland68]

We will consider making the action bar movable to other areas, I'm adding a change to reduce bottom spacing to avoid taking much space #1020

[mijuku233]

We will consider making the action bar movable to other areas, I'm adding a change to reduce bottom spacing to avoid taking much space #1020

If the floating menu option cannot be moved outside the canvas, it won't make much difference. As long as the floating panel is still anywhere in the canvas, it will interfere with the editing/using workflow. As shown in the screenshot, if I want to modify the parameters of the ACNet node, I have to move the canvas first to see and modify the parameters of the ACNet node, which is really annoying, and the floating menu option is also difficult to find in this case. If the floating menu option is just moved to another area of ​​the canvas, it will only make the occluded object different.

[JorgeR81]

We will consider making the action bar movable to other areas, I'm adding a change to reduce bottom spacing to avoid taking much space #1020

This is a bit better, but it still can be distracting and annoying, if you have many nodes in your workflow.

I understand that the Topbar and floating queue panel, are different implementations, and can't be easily integrated.

But the new queue panel should probably be optional, until the current Topbar is converted to the same implementation.  Just use the old queue buttons, in the old Topbar, until everything is converted to the new implementation ( like the sidebar and the floating panel ).

Once all the GUI is converted to the same implementation, we can think about better configurations, both for new users ( with simple workflows ) and experienced users ( with more complex workflows ).