Narrower layout of FX Settings for Particles

[gab3d]

It'd be great if the layout of the parameters in Particles FX Settings panel would allow for accommodating all in a less wide format, as it now requires. Even in a full hd screen (as the one in the screenshot), and with almost one third of the space for the panel, the Colors tab can't be shown complete (and Birth Params tab is on the limit too).

The responsible for this are some options with very long names which appear to the left of the checkbox (i.e. mainly, Pick Control Image's Color for Every Frame, Use Control Image for the Whole Lifetime and Use Columns Duration for Lifetime). Perhaps there's something that can be done with them to save some space. Not urgent, but it'd improve usability a bit.

Thanks!

[RodneyBaker]

Based on the discussion in #1207 feature requests are going to be closed here on GitHub unless there is a developer actively working on the feature. Feature requests can be discussed at the OpenToonz Google Group: https://groups.google.com/forum/#!forum/opentoonz_en

[gab3d]

@RodneyBaker what's the "feature requested" here? 🤔 ...this is a layout problem of the UI

[RodneyBaker]

@gab3d

General rationale for closing issues as a Feature Request and/or enhancement:

• When a feature is working as designed, requests against it falling short of bugs and crashes will more often than not fall into the category of feature request or enhancement.
• Most requests for enhancement suggest improvement to make a feature work more optimally. Most enhancement requests tend to get tagged with "UI", "UX Enhancement" and "Feature Request" because they deal with the user interface and optimization.
• Reports/issues containing text such as, "It'd be great if..." provide a clue as to the issue's nature and suggest an appropriate categorization.
• Feature/enhancement requests that fall into the gray area or have the stated interest of active developers will be left open.

I've been working patiently behind the scenes for awhile to raise awareness of the shortfall in current reporting related to requests for features and enhancements. The recent request to explore the possibility of a separate github repo for feature requests is definitely worth investigating. We want as many ideas for enhancing Opentoonz as possible. The more the better. In the end, most of us didn't establish the current rules, we are just doing our best to adhere to them.

Perhaps if you can restate the problem within the context of a bug report it can gain that classification.

[gab3d]

@RodneyBaker I won't restate nothing, the problem is what it is and was appropriately described, if you want to classificate it as a feature request based on that it'd be great if it could be fixed, do so.

I only see that, whereas I agree having certain rules work in favor, attaining to strictly to them sometimes play against. In this case, this kind of "minor"(admitedly) UI lacking will fall into oblivion because now "it's a feature request". which of course it isn't.

[RodneyBaker]

The issue is an important one. Others are free to open and retag as they see fit. My assessment is only an initial classification.

Aside: It's be nice to do a deep UI scrub prior to release of v1.4 as there are a lot of little things that need fixing.

[manongjohn]

I'm leaning towards feature request. Here is why...

The Fx Setting dialog was not dockable before, so it resized to what it needed to display. If you shrunk the dialog, you had this problem.

Now it is dockable (yay!) but it won't resize now. It's the same effect as opening it and then resizing manually. So no matter how we format it at, it will not fit in a space it was not intended to. So let's say we cut horizontal usage in 1/2. But someone wants it smaller and complains...do we change it again?

This can be true for other fx settings as well. I agree it looks rather ugly, but there are scrollbars to handle when it is tool big.

Technically the panel still works as design, so not really a bug, therefore it's a feature request.

Sadly, closing feature requests here is misleading and keeping them elsewhere doesn't help; Out of sight, out of mind.

[RodneyBaker]

Sadly, closing feature requests here is misleading and keeping them elsewhere doesn't help; Out of sight, out of mind.

I'm not opposed to having two 'Feature Request' tags. Then at least we could sort by the ones that have been implemented versus those that still need to be addressed.

Because there are already too many tags already though I can look at adapting current or unused tags to the purpose.

Perhaps something that mirrors the Opentoonz forum. In the OT Forum the categories are "Feature Request" and "Feature Request (Closed)"** but that doesn't quite work here because of the nature of merged PRs which will automatically close the issue. Instead we might have "Feature Request" and "Feature Request (Open)". Then developers could click on a link or tag and see all the open issues relating to requests.

** In the OT Forum everyone can retag/recategorize which is not the case here in github. This isn't to say that people actually take advantage of that capability. Most do not and I try to update them if I see the request has been implemented.

[gab3d]

@manongjohn well let's get technical to the bone, to be a "feature request" there have to be a feature requested, we're not talking about any feature here. 😉

Jokes apart, all you've said is correct and still, since we have now that wonderful possibility of docking the FX Settings panel, we should take a little more care in not designing layouts that are extremely widespread as the one shown in the screenshot. So that docking possibility could be better exploited.

Perhaps it's just that this insanely looong option name (Pick Control Image's Color for Every Frame) should go to the right of the checkbox (and not to the left), or perhaps is just indenting it to go more to the center of the panel... It's so simple really, but we should have it in mind when designing the panels layouts. As I was translating the Effects manual page into Spanish I've been going through all of the effects and this one was the most prominent I could find (and that's because I reported it). The rest of the effects are mostly good to use in that docked panel configuration. So this isn't something that will start to spread to infinity either, I guess. But I wanted to raise attention to the fact...

On the other part, if we just dismiss this kind of requests as not appropriate for being here, then there is really no other place where we can keep them for reference. 🤔

[manongjohn]

Understable.

Some things are not quite bugs and not quite actual new feature requests....can we make an "Annoyance" tag? :)

If anything, I guess it's an "Enhancement." which I guess falls under Feature Requests?

[konero]

Just leave feature requests open, someone get the Bountysource thing going again.

Somebody go take a look at how Synfig handles themselves, because OpenToonz tags is looking like a bit of a mess and learn from it.

You want people coming here, then study project management.

[RodneyBaker]

Feature Requests Leaving features open certainly gets my vote. However, we need to hear more from the decision makers who felt it necessary to close them. Theirs was/is a legitimate concern as they are the ones that have to wade through everything.

Tags Tags are easily reorganized. Perhaps we can start an issue titled "(Development) Current Opentoonz github repo tags" and use as a place to define and refine our tagging. Keep in mind also that when the decision was made close feature requests there were very few tags. Distinguishing one issue from another was more difficult. Aside: The current tags were an initial step to move in a direction closer to that seen in Synfig and in other project management as we moved into v1.3 release. It's prime time to refresh them again moving into v1.4.

The OT community is still young and we have a lot of skill and experience. The more involved the better.

[artisteacher]

It's too bad that there's not a "feature request" tab to keep things better organized. Putting feature requests with the issues can make it look like there are even more bugs than there actually are.

[RodneyBaker]

Opening as something to review and decide whether it can make v1.4 release or should be pushed to 2020 development cycle.

[artisteacher]

When docked it would be really nice to have a more responsive FX Settings window with only vertical scrolling. On a related note, is there a reason that the FX settings window is not listed in the Windows menu?

[manongjohn]

On a related note, is there a reason that the FX settings window is not listed in the Windows menu?

I think I had planned on changing it from "Edit FX..." to "FX Editor" and add it to the Windows menu but must have slipped my mind. I believe the PR to reorg the menus was still open at the time so I might have been waiting to see which one went in first before I made the change as I would add it in whichever was going in last.

[manongjohn]

I modified the label in a file to add a return in the middle of it so it looks like this now:

Is that any better?

Btw, you can do this to if you edit config\current.txt and look for entries starting with <item>"STD_particlesFx. and modify them as you want, then restart OT to pick up the change.

So I changed this

"STD_particlesFx.pick_color_for_every_frame" "Pick Control Image's Color for Every Frame"

to this

"STD_particlesFx.pick_color_for_every_frame" "Pick Control Image's Color for Every Frame"

I can certainly put in a PR to update any lengthy strings and add returns in strategic places so it can narrow the required area a bit. Would that be enough? I can provide a sample current.txtfile you can test it with. If you want to play with it and send me one that works as a default, I'm good with that too.

The question still remains, how much narrower do you want the panel to be but still allow to see all the settings without having to scroll horizontally. I'm sure that will be very subjective? Note, the narrower the panel, the narrower some of the controls in that panel will become so we can only narrow so much.

[gab3d]

This would certainly be an improvement 👍

To me a size like this one would be more than adequate:

[gab3d]

@artisteacher I think originally the FX Settings panel was not in the Windows menu because, as it wasn't dockable, it was more of a popup dialog that you opened by double clicking an effect node to tweak something, and then close again.

Currently it has much more sense to be able to access it from the Windows menu.

[gab3d]

...on the "feature request" side of things 🤓 I'd love to see this panel evolve into a general "properties panel" for whatever is selected in the scene, be it:

• an effect (to show effect settings)
• a level (to show the level settings)
• a camera (to show camera settings)
• the xsheet node (to show scene settings)
• an output node (to show the output settings)
• etc.

much in the way software like Natron, Nuke, Maya, Cinema 4D, etc. UIs work (to that respect).

[manongjohn]

I played around with the labels a bit and can get it in such a way that you can narrow the panel to the absolute minimum width allowed and all but 1 tab can fit without horizontal scrolling.

The problem is the Colors tab width is based on the Birth/Fade-In/Fade-Out Color controls + the widest label. The color controls are at the minimum width now and it doesn't shift portions of the controls to the next line down if it can't fit in the visible area. Something like that will likely require a bit of coding, I think.

[gab3d]

@manongjohn

I modified the label in a file to add a return in the middle of it so it looks like this now:

Is that any better?

This one hasn't been applied in any PR, no? It'd have been a simple but effective improvement over the current layout. 🤔

[RodneyBaker]

Adjusting the layout of FX dialogues is pretty straightforwarard so we shuld look at updating the dialogues of any rogue FX dialogue boxes, assuming this is still a problem.

Alternatively, we should be able to supply a downloadable set of dialogues to meet requirements.