UI: Sequencer/Preview jumps to cover entire preview area #88618

New Issue

tintwotin · 2021-05-27T10:11:05+02:00

tintwotin commented

2021-05-27 10:11:05 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30

Blender Version
Broken: version: 3.0.0 Alpha, branch: master (modified), commit date: 2021-05-26 18:32, hash: 2c607ec2f6
Worked: (newest version of Blender that worked as expected)

Short description of error
[Please fill out a short description of the error here]

Exact steps for others to reproduce the error

In the Sequencer Preview, select Sequencer/Preview.
Adjust regions so both Preview and Sequencer are visible.
Adjust the height of the area.
Notice that when the area height meets the region height, the Sequencer region jumps to fill the entire area.
Expected behaviour: that the sequencer region doesn't jump to cover the entire area, but is scaled with the change of the area height. Or in other words that the sequencer region height is scaled to the area height, instead of being fixed.
{F10144522,size=full}

An additional annoyance is when changing the area height:
{F10144525,size=full}

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30 **Blender Version** Broken: version: 3.0.0 Alpha, branch: master (modified), commit date: 2021-05-26 18:32, hash: `2c607ec2f6` Worked: (newest version of Blender that worked as expected) **Short description of error** [Please fill out a short description of the error here] **Exact steps for others to reproduce the error** - In the Sequencer Preview, select Sequencer/Preview. - Adjust regions so both Preview and Sequencer are visible. - Adjust the height of the area. - Notice that when the area height meets the region height, the Sequencer region jumps to fill the entire area. Expected behaviour: that the sequencer region doesn't jump to cover the entire area, but is scaled with the change of the area height. Or in other words that the sequencer region height is scaled to the area height, instead of being fixed. {[F10144522](https://archive.blender.org/developer/F10144522/sequencer-preview-jump.gif),size=full} An additional annoyance is when changing the area height: {[F10144525](https://archive.blender.org/developer/F10144525/sequencer-preview-jump2.gif),size=full}

tintwotin commented

2021-05-27 10:11:05 +02:00

Added subscriber: @tintwotin

Philipp Oeser commented

2021-05-27 11:06:29 +02:00

Added subscribers: @iss, @lichtwerk

Philipp Oeser commented

2021-05-27 11:06:29 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Philipp Oeser closed this issue

2021-05-27 11:06:29 +02:00

Philipp Oeser commented

2021-05-27 11:06:29 +02:00

Can confirm this behavior [does not seem to make a lot of sense at first sight], but I am pretty sure this would not be considered a bug.
Atm., when using the Sequencer/Preview view, you are reserving a preferred (non-dynamic) size/hight for the preview, if there is not enough space for this, the region gets tagged RGN_FLAG_TOO_SMALL in region_rect_recursive, resulting in that region to not be drawn again.

It has always been like that (of course, this is not an argument, just a note).

Raising awareness to @iss, there might be interest to improve this, but from a bug-triaging standpoint, this sounds more like a request for modified/improved behavior and not a bug in current behavior.
Closing as this bug tracker is only for bugs and errors.
For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests
For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Can confirm this behavior [does not seem to make a lot of sense at first sight], but I am pretty sure this would not be considered a bug. Atm., when using the `Sequencer/Preview` view, you are reserving a preferred (non-dynamic) size/hight for the preview, if there is not enough space for this, the region gets tagged `RGN_FLAG_TOO_SMALL` in `region_rect_recursive`, resulting in that region to not be drawn again. It has always been like that (of course, this is not an argument, just a note). Raising awareness to @iss, there might be interest to improve this, but from a bug-triaging standpoint, this sounds more like a request for modified/improved behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors. For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

tintwotin commented

2021-05-27 11:51:15 +02:00

@lichtwerk I know that this doesn't range under bug or regression, but it is poor UX offered to VSE users, properly caused by the coder implementing this behaviour, was not aware that in the VSE seq/prev, a different behaviour was needed. So I would call it an incomplete implementation. And there are numerous of those in Blender. Basically each new UI feature added to the 3D View etc. will cause inconsistency/incomplete implementations in all other editors.

They should be addressed, however rcs, devtalk or submitting patches, doesn't work for these things(I know from experience), so the only way I can see something like this to be fixed, is to add it as a https://developer.blender.org/tag/good_first_issue/ which will not burden the module owner(as much(still needs to be reviewed)), and it will let contributors know, if they invest the time to fix this, it will actually be accepted and committed.

Trouble is that if an issue like this is not listed on phab, it'll be forgotten about, and continue to be an annoyance for users for decades, so Archiving it will just ensure that it'll never be dealt with.

@lichtwerk I know that this doesn't range under bug or regression, but it is poor UX offered to VSE users, properly caused by the coder implementing this behaviour, was not aware that in the VSE seq/prev, a different behaviour was needed. So I would call it an incomplete implementation. And there are numerous of those in Blender. Basically each new UI feature added to the 3D View etc. will cause inconsistency/incomplete implementations in all other editors. They should be addressed, however rcs, devtalk or submitting patches, doesn't work for these things(I know from experience), so the only way I can see something like this to be fixed, is to add it as a https://developer.blender.org/tag/good_first_issue/ which will not burden the module owner(as much(still needs to be reviewed)), and it will let contributors know, if they invest the time to fix this, it will actually be accepted and committed. Trouble is that if an issue like this is not listed on phab, it'll be forgotten about, and continue to be an annoyance for users for decades, so Archiving it will just ensure that it'll never be dealt with.

Philipp Oeser commented

2021-05-27 12:50:05 +02:00

I feel your pain, but this is more of a problem of properly monitoring RCS / devtalk / Patch tracker and letting that be part of daily module business, than tracking requests here.
Tracking these here would actually mean tracking feature requests / requests for improved behavior here on phab.
This is of course an option (and it would have advantages), but it has been decided against (one of the reasons always being the limited resources to review these).

I also know you have a history of contributions and not all have ended up being committed or even reviewed, lets try to somehow improve on this (instead of going the way of opening up phab for requests) first, OK?
So if you have a patch for this, you can add me as reviewer/subscriber and I will try my best to get this closer to being committed.

I feel your pain, but this is more of a problem of properly monitoring RCS / devtalk / Patch tracker and letting that be part of daily module business, than tracking requests here. Tracking these here would actually mean tracking feature requests / requests for improved behavior here on phab. This is of course an option (and it would have advantages), but it has been decided against (one of the reasons always being the limited resources to review these). I also know you have a history of contributions and not all have ended up being committed or even reviewed, lets try to somehow improve on this (instead of going the way of opening up phab for requests) first, OK? So if you have a patch for this, you can add me as reviewer/subscriber and I will try my best to get this closer to being committed.

tintwotin commented

2021-05-27 14:17:06 +02:00

It's not really my pain, but the pain of users suffering from bad UX(this report, is just a tiny example of that).
I'll try to stick to not submitting any more patches, as I really should not waste anymore time on this, and apparently this includes pointing out unfinished implementations, UX quirks etc. too.
I'm not getting paid to take on responsibilities like that. It's not my job. Gonna let the responsible, be responsible...

It's not really my pain, but the pain of users suffering from bad UX(this report, is just a tiny example of that). I'll try to stick to not submitting any more patches, as I really should not waste anymore time on this, and apparently this includes pointing out unfinished implementations, UX quirks etc. too. I'm not getting paid to take on responsibilities like that. It's not my job. Gonna let the responsible, be responsible...

Richard Antalik commented

2021-05-27 14:38:23 +02:00

Changed status from 'Archived' to: 'Confirmed'

Richard Antalik reopened this issue

2021-05-27 14:38:23 +02:00

Richard Antalik commented

2021-05-27 14:38:23 +02:00

Sounds like reasonable request, I assume this would be relatively easy to fix with layout callback function.

Technically this is feature request, and shouldn't be tracked here, but such simple issues I don't mind being reported.

Sounds like reasonable request, I assume this would be relatively easy to fix with layout callback function. Technically this is feature request, and shouldn't be tracked here, but such simple issues I don't mind being reported.

tintwotin commented

2021-05-27 15:54:34 +02:00

As mentioned above, I think you guys should use "Good first issue" for things like this one eg. incomplete implementations, inconsistencies and UX quirks and of course easy bugs and regressions.
One way to think of this, is a way to list these things(like the Quick Hacks list), which otherwise would be forgotten, another way to think of this is a way to do much needed onboarding in an organized way.

As mentioned above, I think you guys should use "Good first issue" for things like this one eg. incomplete implementations, inconsistencies and UX quirks and of course easy bugs and regressions. One way to think of this, is a way to list these things(like the Quick Hacks list), which otherwise would be forgotten, another way to think of this is a way to do much needed onboarding in an organized way.

Philipp Oeser commented

2021-05-27 15:59:23 +02:00

In #88618#1167167, @tintwotin wrote:
As mentioned above, I think you guys should use "Good first issue" for things like this one eg. incomplete implementations, inconsistencies and UX quirks and of course easy bugs and regressions.
One way to think of this, is a way to list these things(like the Quick Hacks list), which otherwise would be forgotten, another way to think of this is a way to do much needed onboarding in an organized way.

+1

> In #88618#1167167, @tintwotin wrote: > As mentioned above, I think you guys should use "Good first issue" for things like this one eg. incomplete implementations, inconsistencies and UX quirks and of course easy bugs and regressions. > One way to think of this, is a way to list these things(like the Quick Hacks list), which otherwise would be forgotten, another way to think of this is a way to do much needed onboarding in an organized way. +1

Richard Antalik commented

2021-05-31 15:53:29 +02:00

I was looking into this, and it turns out that it is not possible to fix this with ARegionType->layout() function. This is because function can not tell if change is occuring to region only or whole area.

Changing to known issue since this requires more changes and possibly design to be approved.

I was looking into this, and it turns out that it is not possible to fix this with `ARegionType->layout()` function. This is because function can not tell if change is occuring to region only or whole area. Changing to known issue since this requires more changes and possibly design to be approved.

tintwotin commented

2021-06-04 15:33:29 +02:00

Removed subscriber: @tintwotin

tintwotin commented

2021-10-26 08:52:39 +02:00

Changed status from 'Confirmed' to: 'Archived'

tintwotin closed this issue

2021-10-26 08:52:39 +02:00

tintwotin commented

2021-10-26 08:52:39 +02:00

As I do not have anymore time or motivation for a continued investment in the Blender project, I'm giving up on this report for now.

Philipp Oeser commented

2021-10-26 09:14:16 +02:00

Changed status from 'Archived' to: 'Confirmed'

Philipp Oeser reopened this issue

2021-10-26 09:14:16 +02:00

Philipp Oeser commented

2021-10-26 09:14:16 +02:00

Sorry to hear (thx again reporting). In my opinion we should not sweep this under the carpet (esp. since this already been confirmed), there is still a chance to get this fixed in the future and others might be affected by this issue as well.
Feel free to unsubscribe though.

Sorry to hear (thx again reporting). In my opinion we should not sweep this under the carpet (esp. since this already been confirmed), there is still a chance to get this fixed in the future and others might be affected by this issue as well. Feel free to unsubscribe though.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI: Sequencer/Preview jumps to cover entire preview area #88618