1.1

[chrisgoringe]

Quite a bit has changed since I asked what the priorities were for 1.1...

I'd like to make the dot releases relatively small over the coming iterations; I'm thinking to do one major thing (and maybe a couple of minor ones) in each release

Looking at the list, major options for 1.1 might be:

A. custom scrollbar (#204)
B. multiple controller instances (#123)
C. bypass (#72, #89)
D. links with workflow (#100, #109)
E. better group choice (#168, #189)
F. widget selection (#143)

Minor things would include #106, #141, #157, #170, #171, #182, #184, #185, #190, #193, #196

My first inclination for 1.1 is to do #204 (because it solves other issues!), #184, #185 and #190.

[JorgeR81]

Yeah, I actually completely agree with your order, also for future versions :

---

1.1

• MAJOR - custom scrollbar
  Resize by dragging edges (was: Replace scroll bar with custom one) #204
• minor - [ feature ] Support Power Lora Loader (rgthree) node #106
• minor - Font size setting #141

Can you also squeeze this last one in ?
The Power Lora Loader (rgthree) also uses this darker text when a lora is toggled "off".

• minor - [ Aesthetics ] make "false" text darker, in the boolean widget  #202 - ( EXTRA )

---

1.2

• MAJOR - multiple controller instances
  [ feature ] multiple controller instances #123
• minor - [ feature ] Drag and drop a node from the Controller to the canvas to clone it #157
• minor - [Bug+minor visual] Right sidebar position: Graph Canvas Menu over the window and bluebar on the wrong side #170

EDIT: I just added another feature that should probably have more priority than the 2 minor features here.

• NEW - [ feature ] Open the MaskEditor from the Controller  #214

---

1.3

• MAJOR - bypass
  Display bypassed nodes in controller (with visual hint) #72
  Toggle _group_ bypass #89
• minor - [Bug] Controller window stays open when opening sidebar windows using shortcuts #171
• minor - Changing menu bar from left to right requires page reload #182

---

1.4

• MAJOR - links with workflow
  When clicking a group in the workflow, select it in the controller #100,
  Highlight node in workflow when you hover over the controller version and vica versa #109
• minor - If slider value changed by changing min/max, widget not updated #184
• minor - rename control_after... if set to before #185

---

1.5

• MAJOR - better group choice
  Replace group select with multi pick #168
  [Feature Request] Group color labeling #189
• minor - [Feature Request] Multiple nodes options #190
• minor - [ bug ] Controller is closed when switching workflows  #193

---

1.6

• MAJOR - widget selection
  Select which widgets to show or hide #143
• minor - Custom text areas show through the controller #196

[JorgeR81]

I thought you would want to add multiple instances ( #123 ) in a later version.
But it's probably easier to do this while there are less features, right ?

---

Also, multiple instances can be used to replace another feature ( not included in this roadmap ):

• [ feature ] Add toggle button to replace the node graph canvas, with Image Preview #127

The user would just have to:

• Add the final Image Preview, to its own group
• Select that group in one of the instances
• Make that instance wider to fill the rest of the screen

[JorgeR81]

I just added another feature that should probably have more priority than some of the minor features here.

• [ feature ] Open the MaskEditor from the Controller  #214

[chrisgoringe]

Questions on multiple instances...

Do you think it is better:

• to have two instances available, one on each side (left/right) or
• to have two (or more) available, all on the same side

If we have multiple instances, should they open and close (pop out and pop away) independantly, or all together?

If we have multiple instances, should they scroll independantly, or all together? (independantly makes more sense somehow, but obv. requires multiple scrollbars...)

[LukeG89]

The floating scrollbar design ( #204 (comment) ) would not work with the controller windows.
This is because we would want to snap windows together.

Well, when you switch tabs, a different scrollbar is shown, so both floating/integrated scrollbars could work.

So, we could have a framed bar design, that matches the group label design.

But I like this design!

[JorgeR81]

Well, when you switch tabs, a different scrollbar is shown, so both floating/integrated scrollbars could work.

I mean, if we want to have two independent windows "snapped" to each other.
Even with tabs, you may also want to do that.

---

[LukeG89]

I mean, if we want to have two independent windows "snapped" to each other.
Even with tabs, you may also want to do that.

Yeah, that makes sense!
Besides, I would still prefer the new design over the floating one.

[chrisgoringe]

Wow. How much did I miss by sleeping? Timezones, eh? (I'm in Sydney, Australia, btw)

I want to peel apart related threads here...

Windows, tabs etc

I love the idea of a tabbed controller. It's a UI that everyone is familiar with from browsers, and I would take that as the design idiom (so single scrollbar, resize effects all tabs, drag tabs in and out by their title etc.). The integrated scrollbar also looks like a good solution. Probably also want to shape the tabs...

I think collapse and close would work on a per-window basis as well, using the _ and X icons like in the mockup. Again, consistent with the way windows work in Windows / MacOS.

Groups etc

I'm undecided on the single v. multi group per tab. While multi gives some additional flexibility, I feel like the simplicity of single is probably better. If you want to see two things together, you can have two windows. If we stayed with single, then the title of the tab would be the name of the group. When you click '+' you would get a drop-down list of available groups to choose from.

Membership

I'm not convinced by the idea of being able to drag nodes into, or between, controllers. It seems to me that groups are a well established Comfy thing that people use, and once you allow individual nodes to be added or removed it adds a huge degree of complexity, both for the code and for the user experience. I drag a node into a tab labelled for a group, then close that tab, then open a new one for the same group. Is the added node there? If I remove a node from a group in the workflow, then add it back manually, what happens?

These things are answerable, but I don't see the value add justifying the complexity. You can always add a node to a group if you want it to appear (remember, if you have two groups of the same name, the controller treats them as one, so you don't need to break your workflow layout).

The basic concept that the controller is a view of the workflow drives my thinking here. It gives a conceptual coherence IMO.

So, as has been suggested somewhere in this conversation, I'm also tempted to remove the 'show in all groups' option once we have multiple windows.

Anyway... 1.1 is about being able to move a controller around, so I'll push ahead with that. I suspect that multiple windows will come next, and by then the plan will be clearer!

[JorgeR81]

I'm undecided on the single v. multi group per tab. While multi gives some additional flexibility, I feel like the simplicity of single is probably better.

The basic concept that the controller is a view of the workflow drives my thinking here. It gives a conceptual coherence IMO.

Yeah, having one group per tab would be easier to understand, and it would be the most used configuration, anyways.

---

When you click '+' you would get a drop-down list of available groups to choose from.

I like this design.
We should also have a tab for nodes with no group. 

---

I'm not convinced by the idea of being able to drag nodes into, or between, controllers.

If we have one group per tab, we don't need to use drag and drop to add nodes.
They will just be added automatically to their own group tab, if available.

---

I'm also tempted to remove the 'show in all groups' option once we have multiple windows.

Agreed.
But we should keep advanced controls. I would like to toggle them, per tab / group.

[chrisgoringe]

I've created two new milestones, 1.1 and 1.1 stretch - the latter for things I'll add if time allows or if they seem easy or if I get bored with the things in 1.1.

[JorgeR81]

I'm making a new post in this discussion, so that you can reply here. The other is too long now.

Since we're going to go with one group per tab, then group color labels is no longer necessary ( #189 )
So the color can be in the group tabs.

This mockup is mostly to share an idea on how that could be done.
We would want all tabs to be colored. But the selected tab must stand out.

I also included the new icons.
They probably look better on the left, to differentiate them from the window buttons.

---

[JorgeR81]

I'd like to give the tabs the slightly curved effect as well

Yeah, I think the curvy tabs would look good.
This is just to help visualize the color scheme. It's easier to draw a square tab :)

---

We could also extend the color in all borders.

This could be an user option.

It may help differentiate windows at a glance, you have multiple windows in the canvas.

[LukeG89]

We could also extend the color in all borders.

Maybe that would be too much, like in my first Color labeling concept (#160 (comment))

[JorgeR81]

Maybe that would be too much, like in my first Color labeling concept (#160 (comment))

What do you mean ?
I don't see the difference. You also had color in the whole border.

[LukeG89]

I mean there is too much color, as in my first concept. This is why I opted for colored bars.

[JorgeR81]

I mean there is too much color,

Yeah, that's why I thought about having it as an user option.

[chrisgoringe]

I like that. I don’t think this sort of thing merits a user option 😀

…

On Mon, 28 Oct 2024 at 7:07 PM, JorgeR81 ***@***.***> wrote: I'd like to give the tabs the slightly curved effect as well Yeah, I think the curvy tabs would look good. This is just to help visualize the color scheme. It's easier to draw a square tab :) ------------------------------ We could also extend the color in all borders. This could be an user option. tabs168.png (view on web) <https://github.com/user-attachments/assets/43673ed5-a6f3-4561-8dc6-5a3f54a53165> — Reply to this email directly, view it on GitHub <#210 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBLMA36IOV3W4HFPUCRZ4DZ5XPCLAVCNFSM6AAAAABQSCXDXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMBXGE4TGOI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[JorgeR81]

I don’t think this sort of thing merits a user option

Yeah, you're right.
If you don't like the colors, you will probably use "black" groups anyways.