Hide section

[tokejepsen]

This PR is an attempt at being able to hide sections of items in the UI. This is just the basic working version, so everything is up for discussion.

Its implemented similar to how the toggling works, by having a item.isHidden property in the model. I'm thinking that this will allow us to implement a way to customize which sections are shown on launch, which could address https://github.com/pyblish/pyblish-qml/issues/189

[tokejepsen]

I see I have #273 in here as well. Maybe we could merge that first, instead of having to reopen a PR.

[BigRoy]

The behavior to click the header and toggle all instances underneath it? Is that still doable? If so, how does one do that now? You seem to do it in the GIF but I'm not sure how.

[BigRoy]

Also, I think it's looking good. But with the headers being able to collapse I must say when they are collapsed it's confusing if one of the stages gave errors, because you wouldn't see it. As such the headers must likely become much more informative to in a way allow showing such data? Or would it always show warned/errored plug-ins?

[tokejepsen]

You seem to do it in the GIF but I'm not sure how.

Yup, you can still do that. The clickable area is the labels boundary. Just the first solution I could think off, so suggestions for better alternatives are welcome.

Or would it always show warned/errored plug-ins?

Yeah, I was thinking we could colour the label depending on the succcess/failed state. Similar to how the instance items checkbox colouring works.

[BigRoy]

Yup, you can still do that. The clickable area is the labels boundary. Just the first solution I could think off, so suggestions for better alternatives are welcome.

Ah, I see. Maybe CTRL + click makes more sense to maybe toggle all.

Yeah, I was thinking we could colour the label depending on the succcess/failed state. Similar to how the instance items checkbox colouring works.

Could be a good start yes.

[tokejepsen]

Forgot to show processing:

[mottosso]

Wow! This is amazing! There was a request a while back about optionally hiding collectors, as they didn't provide much value to the artist. Maybe some sections could be collapsed per default somehow? Maybe just hardcode the collectors.

[mottosso]

Ah, you linked to it, it's https://github.com/pyblish/pyblish-qml/issues/189 :) Perfect.

[tokejepsen]

Maybe some sections could be collapsed per default somehow?

I was thinking we could query for a hidden data member/attribute, similar to how you can set the publish state of an instance. This would makes it very flexible and allow us to hide any section and even let the user customize which section should be hidden.

[BigRoy]

I was thinking we could query for a hidden data member/attribute, similar to how you can set the publish state of an instance. This would makes it very flexible and allow us to hide any section and even let the user customize which section should be hidden.

Actually, it's not similar - because this would be for the complete section not per instance or per plugin. We've never stored data for a grouped section before I believe?

The idea itself though sounds like a good direction.

[davidlatwe]

Ah, I see. Maybe CTRL + click makes more sense to maybe toggle all.

Just interesting in this :) Maybe make the v arrow mark into a circular and rotatable checkbox for toggle all ? Providing both hide/show and all on/off visual hint.

[tokejepsen]

Maybe make the v arrow mark into a circular and rotatable checkbox for toggle all ?

That is an interesting idea :) Never seen something like that before. Slightly worry would be that user aren't familiar with it. Have you got a reference for this from somewhere?

[tokejepsen]

We've never stored data for a grouped section before I believe?

Actually when I think about this some more, it might become too confusing to have some plugins/instance hidden within a section because there is no indication for hidden items.

Maybe its better to expose a public list of sections labels to hide on startup.

import pyblish_qml import settings

settings.HiddenSections = ["Collect"]

[BigRoy]

Maybe make the v arrow mark into a circular and rotatable checkbox for toggle all ?

That is an interesting idea :) Never seen something like that before. Slightly worry would be that user aren't familiar with it. Have you got a reference for this from somewhere?

Also not sure how clear that would be for plug-ins, because there are often only a few which can be toggled. So there would always be a remainder that is enabled - what would it then show? :)

[tokejepsen]

what would it then show?

Good point, that might become confusing.

We could also just rethink where/how to hide a section. I initially thought of have just the arrow > be clickable, but that seemed like a very small area to hit with the cursor.

[davidlatwe]

Slightly worry would be that user aren't familiar with it.

Yeah, it might :( . Most case I know they always separate the function of tree collapsing and toggling, and visualize both. Currently only have one persist visual item (v arrow mark) in there to give the collapsible hint, and the toggle all is implicit. Maybe should add one more indicator for keeping those options visualize ? Or just leave it as is ? ~Since at least me personally not often need to toggle them all : /~ sorry, Instances needed.

[davidlatwe]

We could also just rethink where/how to hide a section.

Yes, right. Maybe use + and - for collapsing ? For differentiate from go to perspective

[tokejepsen]

For differentiate from go to perspective

Good point as well.

Here is an option for separating the collapsing and toggling:

[BigRoy]

Here is an option for separating the collapsing and toggling:

Nice!

This already makes much more sense to me - but yes, the arrow area feels a bit large now; especially in width.

[tokejepsen]

This is starting to feel right :)

[davidlatwe]

This might be another issue. For showing the plugin's toggle status if the section is collapsed, how about something like github's modification indicator or deadline's progress bar ? Darker color would be the can not toggle, mid-gray would be off, white for on, and turn in to progress bar when processing.

maybe won't need number on it, just use color as a simple visual hint.

[tokejepsen]

maybe won't need number on it, just use color as a simple visual hint.

I'm going to try and adhere to the current color scheme and processing indicator. That being when processing the section label will highlight (blink), and on success color the label (and/or the icon) green, on warning=orange and failed=red.

Progress bar is a different issue all together :)

[tokejepsen]

I've hardcoded the "Collect" section to be collapsed. While trying to update the UI from the controller and looking into what is required from getting the colours working when processing, it seems to me that we'll need to have a dedicated "section" in the model.

I'll return to this on Monday, but if anyone has any ideas please chime in.

[mottosso]

This is really great work!

it seems to me that we'll need to have a dedicated "section" in the model.

On playing with this, I noticed that the icon sometimes got confused as to whether a section was expanded or not, also the sections that appear twice, like MyFamily is doubly confused. So yes, I think you're right, we need some way of keeping track of state outside of the GUI.

I made some cosmetics suggestions, let me know what you think.

• Section backdrop
• Plus == Minus, so that you click plus for "Expand please", and minus for "Contract please". Rather than them being an indicator of whether it is expanded or not. Not sure which is more intuitive, just wanted to offer an alternative.

[mottosso]

A hint of depth. :) Similar to the other "3d" effects.

[tokejepsen]

I made some cosmetics suggestions

Awesome! All helps the visual clarity, thanks :)

[tokejepsen]

Struggling a bit to figure out how to assign a section an item in the model to reference values from.

If anyone has some ideas, please let me know.

[tokejepsen]

Think I have got a working solution for having sections in the model. Still need to see how it handles changing colour on processing.

If anyone has any feedback on the code, please rip it apart cause I'm unsure about it.

[tokejepsen]

Alright, another version to review :)

Personally I think we may be suffering from information overload now, but could also just be because I'm used to the old amount of information. Maybe colouring the show/hide button is better?

[davidlatwe]

Maybe this would help ? Just tweak a little bit, shrink down the label and tint the border

[tokejepsen]

Thats nice @davidlatwe :) I could run with that. Anyone else have an opinion on this?

@davidlatwe guessing you that as code?

[davidlatwe]

Yes, it does :D But I think I am not able to add into this PR, maybe I push to my fork for you to see the changes.

[tokejepsen]

But I think I am not able to add into this PR, maybe I push to my fork for you to see the changes.

Yeah, if you push the changes to your fork and PR to my hide_section branch, then I can just merge it.

[davidlatwe]

Okay, it's done :)

[BigRoy]

Woot, that last one is sweet! Does it also turn orange on only warnings? Taking over the highest level of status?

Maybe even green if it's fully complete? (So you know it has processed?) Or might be too much visual clutter.

Awesome stuff.

[tokejepsen]

Woot, that last one is sweet! Does it also turn orange on only warnings? Taking over the highest level of status?

It does indeed :) Same as how the checkboxes work.

Maybe even green if it's fully complete? (So you know it has processed?) Or might be too much visual clutter.

I'll try it tomorrow :)

[davidlatwe]

Does it also turn orange on only warnings?

warning support :D

Maybe in the future the --demo mode need to add a scenario that has warning and success but no errors

[davidlatwe]

Add some warning case to family "failure" and "B"

I thought this should be in another PR, so I committed this one on a new branch based on master branch. Let me know if you want this, should be easy to merge :)

[mottosso]

This makes me want to find something to publish with failures and warnings all over the place. So pretty. :) Great work guys.

[tokejepsen]

Let me know if you want this, should be easy to merge

Sure, lets just get this in as well :)

[tokejepsen]

This is with colouring the succeeded sections green:

What do we think?

[mottosso]

What do we think?

It's definitely a lot, I'll need to look at it a few times to tell whether it feels off because it's new or because it's too much.

[mottosso]

Could you post a full-sized gif of it, to get the full experience?

[davidlatwe]

Maybe dim out a little successColor from #77AE24 to like #687F5E would help ?

[tokejepsen]

Could you post a full-sized gif of it, to get the full experience?

Maybe dim out a little successColor from #77AE24 to like #687F5E would help?

Think if we are going that dark with the green, we might as well just keep it grey like before.

[mottosso]

Ok, I think I've got it.

I think the added green obscures the more important color, red. If nothing is red, I think I would read that as "No problem".

Now with so much green, the same information appears twice, loudly - "No problem, ALL GOOD!". Let's keep green to a minimal, like it was, but keep the red. Screaming more loudly on error - e.g. "SOMETHING BAD!" - is a good thing. :)

[tokejepsen]

Agree :)

[tokejepsen]

Any other thoughts on this?

Think we are ready for a merge else.

[mottosso]

I'm all out. If everyone else is happy, merge at will!

[BigRoy]

I personally feel the dimmed out green for success could be useful as indication, because if it's collapsed there would otherwise not be any way to "know" whether something would've been processed or not. For example, on reset... the Collectors would already be green - (red in the example because it has a failing one).

But for now I think the gray one is a good start that feels less cluttered - let's see if we ever end up missing it.

Let's merge.