-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
UI: Implement UI collections #2198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Brainstorming names would be a good idea too:
|
|
I want to be careful around the "layout" terminology because it can be misconstrued as a layout for the scene itself (i.e. source layouts/templates). I like "Workspaces", though I admit "Dock Layouts" may also work. Another possibility might be related to "Workflow", as I envision many people wanting to have a "Pre-production" setup and a "Live" setup, such that docks are in different places with different visibilities based on whether you're live or not. Just some brainstorming. Very cool feature (though admittedly I haven't tested it yet). |
|
I really like the 'Workflow' idea because that is what I would imagine would be the dominant use case |
|
Just want to throw it out there that Adobe calls this function "Workspace" as well in its products. |
I don't really know how I feel about this PR. I feel like this feature is going a bit too far beyond what I'd prefer. That and having three different save data collections (profiles, scenes, and now UI). It makes things more confusing for users than it already is. I feel like this moves away from my personal goal of improving UX, which makes me feel very uncomfortable. |
|
I think the feature absolutely has value, and is a feature found in many other similar creative programs. I think working out a way to simplify profiles vs. scene collections vs. workspaces is reasonable but I don't think that's a reason to deny this feature. I would argue that it improves UX by giving users a way to customize the tools available to them depending on the context of how they are using the program. It will help users simplify their UI, not make it more complex. |
|
Give me an example of how it helps simplify their UI. |
|
Nevermind, I looked at the ideas page and I suppose I can see how this would be useful in some circumstances. But I can't help but to feel uncomfortable with adding another menu to the main menu bar. The experience a new user has is one of my personal concerns. I feel like I'd rather this be a part of the docks menu, or something that's inherently linked up to profiles. It may have to be something that's profile-based anyway, because there's already a separate UI save mechanism for profiles when connecting accounts. I think making it a profile-specific thing makes more sense for that reason and streamlines the entire thing. |
|
If a new user completely ignores this menu then they will have the exact same experience that they have now. This is why I want to make sure it's named something that will be familiar to new users so that if they see the menu item, they will be more likely to understand what the feature is without having it explained to them.
Do you mean that the set of available UI collections should be tied to a profile? |
|
I mean that it makes more sense to me that a UI configuration is bundled with a profile, rather than it being a completely separate thing. That seems to make the most sense judging upon what people seem to use these dock configurations for. For example on the ideas page, they say they'd like to have it small so it's specific to recording, and that feels like it'd make more sense to just be a part of the profile in that case rather than a separate menu. Regardless of what it's named, the problem I have with it being a separate menu is that any extra thing on the main UI can intimidate the user. I already feel somewhat uncomfortable with the separation of profiles and scene collections as it is. I feel like scene collections should really have been its own dock if anything. |
|
I agree that tying it to the Profile is a fair compromise. The main downside would be the inability to have "Editing" and "Live" layouts tied to one profile, but that could be worked around by having a dummy profile with the same canvas resolution as the live one. |
|
Anyway, that's not the sole reason why I want to tie it to profiles. The other reason is as previously stated, account connections basically invoke their own profile-specific UI layout due to the fact that account connections add chat docks and things like that. So already there's going to be a conflict between having a separate one and having the existing pseudo-profile one. I think from a architectural point of view it makes more sense to just utilize the existing pseudo-profile UI layout and make it non-pseudo instead. |
|
Whatever happens, what I don't want is a one-to-one mapping of one workspace per profile, such that changing to a different workspace would require changing profiles. That would utterly defeat the whole point of the feature. |
|
Listen, the problem is that there's already a workspace associated with the profile, and it has to do with account connections. They can't easily be unlinked. Architecturally with the way it's currently designed it makes more sense for it to be stored as profile data, because technically it already is if you have an account connected. |
|
If we can't switch workspaces without switching profiles, then perhaps we should shelve this until that design flaw can finally be rectified, probably as part of the long-awaited outputs refactor. |
|
Yeah tying workspaces to profiles seems like a stifling limitation. |
|
I agree with @dodgepong and @mufunyo that tying workspaces to profiles would not be ideal. I only have a handful of profiles, and I think that it would be too cumbersome to have to create duplicate profiles for each workspace. UI layouts (workspaces) should not be dependent on what profile you've selected or what account you've linked. If that can't be done with the way profiles and accounts work now, then maybe it needs to wait until account connections are not tied to profiles or are otherwise reworked. |
|
I apologies for the neglect on this, I have 3 finals day after day so I am busy atm. If you would prefer, I can draft up a RFC with some possible solutions. I can understand why you would prefer to link it to profiles. The reason I put it in its separate tab is because I was thinking that you could have multiple different configurations setup that would be usable across different profiles. This prevents redundancy and reduces the mental overhead for the user. I understand your reservations, I just think it would be a pleasant productivity boost for users who use OBS for various different purposes and it allows them for much more flexibility. And regarding the errors and bugs, I will fix them up once I finish finals. |
|
I'd also like to throw in my support for these being separate. They could potentially be nested in the View menu to keep clutter down, but I think keeping a UI collection separate from profile is an important aspect of the feature. We had someone in the Discord who wanted to be able to save different layouts for their multiview, which might make sense to live as part of the workspace or whatever it will be called. |
… also fixed reset ui dialogue never showing
…revious default setup
Description
This adds ui collections commonly referred to as "workspaces". It allows you to create mutliple different formats and easily switch between them.
Motivation and Context
It simply allows for more flexibility when using OBS for different purposes. It implements the suggestion found here: https://ideas.obsproject.com/posts/615/ui-collections
How Has This Been Tested?
I tested it on my Linux machine but nothing else yet.
Todo
Known Bugs
Types of changes
Checklist: