Regression: Right aligned header #100141

System Information
Operating system: Linux-5.4.0-122-generic-x86_64-with-glibc2.31 64 Bits
Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.129.06

Blender Version
Broken: version: 3.4.0 Alpha, 3.3
Worked: 3.2
Caused by 6243972319

Short description of error
dragging open a new editor window horizontally has the menu bar right aligned. this has the dropdown with the different editors out of view from startup.
and it overwrite the left alignment of the shrinking editor window as well.

Exact steps for others to reproduce the error

Open default file
Split viewport region vertically
editor.mp4

Added subscriber: @ToxicTuba

blender/blender-addons#101261 was marked as duplicate of this issue

#101187 was marked as duplicate of this issue

#101189 was marked as duplicate of this issue

#101181 was marked as duplicate of this issue

#101136 was marked as duplicate of this issue

#101024 was marked as duplicate of this issue

#101003 was marked as duplicate of this issue

#100933 was marked as duplicate of this issue

#100929 was marked as duplicate of this issue

#100930 was marked as duplicate of this issue

#100927 was marked as duplicate of this issue

#100221 was marked as duplicate of this issue

Added subscriber: @OmarEmaraDev

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Not sure if this is considered a bug by the module, but it seems inconvenient to me, so I will tag the module for a decision.

This actually changed in 3.3, in older versions it was left aligned, which is causing more issues for smaller screens as can be seen in #100221.

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Added subscriber: @Memento

Added subscribers: @Harley, @PratikPB2123

Introduced in 6243972319
Change doesn't look intended from commit message at least
@Harley, can you take a look?

Added subscriber: @AnthonyEdlin

@AnthonyEdlin - Any ideas?

If not I can look at this fairly soon, just buried a bit.

Previously the regions would always scroll left or up by a little bit when resizing, which was causing the outliner to scroll up when resizing the area smaller. Now they should keep the offset, and pretty sure I tested the headers when making the patch.

Just tested on 3.3 and it looks like the headers never keep left side offset when resizing, so definitely not working.

I'm gone this weekend, but I'll check it out when I'm back.

Thanks @AnthonyEdlin! There were definitely parts of your patches where we weren't entirely sure they were needed, so might have left something important out.

I'm sure you noticed, but I made a patch that only puts back enough to make this current problem go away: D15873: Fix #100141: Header Alignment of New Editors. In case that helps you figure out what I screwed up. LOL

I'm gone this weekend, but I'll check it out when I'm back.

Yes, for sure. Enjoy your weekend. This problem hasn't come close to killing anyone yet.

Added subscriber: @Ott

Added subscriber: @Leroy-Xie

Added subscriber: @bariclee951

Added subscriber: @DragonLadyMerlin

It seems to be enough to just make the headers keep x offset just like outliner. Not sure why it wasn't included in original patch.

Here is diff:
fix_headers_offset_x.diff

@AnthonyEdlin

Not sure how important it is, but your one-line fix doesn't quite restore all the old behavior. It keeps the header from moving while dragging out, but new editors get the same offset rather than being reset to left. In other words: Start with a 3D View, and resize it so that it cannot contain the entire header. Then drag its header to the right. If you then split (using corner action zone) the new area will be offset like the original.

{F13473231,width=100%}

In prior versions of Blender the new area will be at left edge. From version 3.01:

{F13473236,width=100%}

D15873: Fix #100141: Header Alignment of New Editors does seem to restore this behavior as well.

Added subscriber: @Wovchick

Added subscriber: @NICEUU

@Harley

In prior versions of Blender the new area will be at left edge.

That's not quite how it works. I'll try to explain.

There are the two relevant code sections before the original patch, first:

    if ((v2d->keeptot == V2D_KEEPTOT_STRICT) && (winx != v2d->oldwinx)) {
      /* Special exception for Outliner (and later channel-lists):

     * - The view may be moved left to avoid contents
     *   being pushed out of view when view shrinks.
     * - The keeptot code will make sure cur->xmin will not be less than tot->xmin
     *   (which cannot be allowed).
     * - width is not adjusted for changed ratios here.
     */

      if (winx < v2d->oldwinx) {
        const float temp = v2d->oldwinx - winx;

        cur->xmin -= temp;
        cur->xmax -= temp;

        /* width does not get modified, as keepaspect here is just set to make

       * sure visible area adjusts to changing view shape!
       */

      }
    }

and then just after that this:

  /* Resize from center-point, unless otherwise specified. */
  if (width != curwidth) {
    if (v2d->keepofs & V2D_LOCKOFS_X) {
      cur->xmax += width - BLI_rctf_size_x(cur);
    }
    else if (v2d->keepofs & V2D_KEEPOFS_X) {
      if (v2d->align & V2D_ALIGN_NO_POS_X) {
        cur->xmin -= width - BLI_rctf_size_x(cur);
      }
      else {
        cur->xmax += width - BLI_rctf_size_x(cur);
      }
    }
    else {
      temp = BLI_rctf_cent_x(cur);
      dh = width * 0.5f;

      cur->xmin = temp - dh;
      cur->xmax = temp + dh;
    }
  }

The first section of code will scroll the header to the left by the difference of the old size and the new size, but only if the region is getting smaller. Then the second section of code, since before the patch V2D_KEEPOFS is not set, it will use the "else" clause to try and resize around the center of the region.

Here is an example with numbers. Say you have a region with a size of 204, and the cur rect xmin is 200 and the xmax is 404. This is the state with the header scrolled 200 pixels to the right. Now you resize the area 4 pixels smaller to 200. First the cur rect is moved over 4 pixels so xmin is 196 and xmax is 400, then the second section of code resizes the cur rect to the correct size based from the center, so that would be 198 to 398. This is why resizing an area smaller almost always scrolls the header. This combination of code effectively scrolls the header left by half the resize value.

You probably know that when resizing areas it is clamped, if I remember correctly, to 4 pixels so it doesn't redraw too much. So in most cases a resize of a region will be by 4, but there are some cases where the resize will be smaller or bigger, for instance if you resize a floating window 1 pixel smaller by grabbing the edge, or by restoring and maximizing a window. Try these out and you will see either no scroll because it's to small of a resize or a bunch of scrolling because the resize will be larger.

That brings us back to your example of a new area. When you create a new area it copies all the data from the area it is splitting. So using similar numbers from before, say you have a region with a size of 200 and the cur rect is 200 to 400. When the new area is created it will copy those numbers but the area will only be like 20 pixels wide at first, so it will resize down. Following the logic again it will shift over 180 so the cur rect will be 20 to 220 and then it will size down to the center, which leaves the cur rect at 110 to 130. This is clearly not reset all the way to the left.

Here is from blender 3.2:
SplitOld.mp4

Obviously if you split from a very large area or a header that isn't scrolled very far, it can scroll enough that it looks like it reset back to the left, as in your example.

So, with all that said, what is the proper fix? Is the scrolling a bug or a feature? I think there is a case to say that scrolling left on headers in some cases may be good. It tends to keep the headers scrolled left when you do any resizing, which may be ok even though it has edge cases. The problem with it is those edge cases, and it also leads to the situation where basically no one understands how the view2d code works.

The reason I choose to just remove it in the patch and use the V2D_KEEPOFS_X is because everything I just described regarding why headers and outliner scroll when resizing smaller goes away and the logic for resizing basically boils down to this line:

    cur->xmax += width - BLI_rctf_size_x(cur);

You are correct that when you make a new area it doesn't reset the header, it just copies the offset, but I would rather explicitly just reset the header when the area is duplicated then use the random scrolling that might or might not reset the header by scrolling. That would be a separate issue then. But this is just my opinion.

Either way, it should not do what it is doing now and resize from the center when shrinking the region size. With 3.3 released there are probably going to be a deluge of reports about this.

@Harley > In prior versions of Blender the new area will be at left edge. That's not quite how it works. I'll try to explain. There are the two relevant code sections before the original patch, first: ``` if ((v2d->keeptot == V2D_KEEPTOT_STRICT) && (winx != v2d->oldwinx)) { /* Special exception for Outliner (and later channel-lists): ``` * - The view may be moved left to avoid contents * being pushed out of view when view shrinks. * - The keeptot code will make sure cur->xmin will not be less than tot->xmin * (which cannot be allowed). * - width is not adjusted for changed ratios here. */ ``` if (winx < v2d->oldwinx) { const float temp = v2d->oldwinx - winx; ``` ``` cur->xmin -= temp; cur->xmax -= temp; ``` ``` /* width does not get modified, as keepaspect here is just set to make ``` * sure visible area adjusts to changing view shape! */ ``` } } ``` and then just after that this: ``` /* Resize from center-point, unless otherwise specified. */ if (width != curwidth) { if (v2d->keepofs & V2D_LOCKOFS_X) { cur->xmax += width - BLI_rctf_size_x(cur); } else if (v2d->keepofs & V2D_KEEPOFS_X) { if (v2d->align & V2D_ALIGN_NO_POS_X) { cur->xmin -= width - BLI_rctf_size_x(cur); } else { cur->xmax += width - BLI_rctf_size_x(cur); } } else { temp = BLI_rctf_cent_x(cur); dh = width * 0.5f; ``` ``` cur->xmin = temp - dh; cur->xmax = temp + dh; } } ``` The first section of code will scroll the header to the left by the difference of the old size and the new size, but only if the region is getting smaller. Then the second section of code, since before the patch V2D_KEEPOFS is not set, it will use the "else" clause to try and resize around the center of the region. Here is an example with numbers. Say you have a region with a size of 204, and the cur rect xmin is 200 and the xmax is 404. This is the state with the header scrolled 200 pixels to the right. Now you resize the area 4 pixels smaller to 200. First the cur rect is moved over 4 pixels so xmin is 196 and xmax is 400, then the second section of code resizes the cur rect to the correct size based from the center, so that would be 198 to 398. This is why resizing an area smaller almost always scrolls the header. This combination of code effectively scrolls the header left by half the resize value. You probably know that when resizing areas it is clamped, if I remember correctly, to 4 pixels so it doesn't redraw too much. So in most cases a resize of a region will be by 4, but there are some cases where the resize will be smaller or bigger, for instance if you resize a floating window 1 pixel smaller by grabbing the edge, or by restoring and maximizing a window. Try these out and you will see either no scroll because it's to small of a resize or a bunch of scrolling because the resize will be larger. That brings us back to your example of a new area. When you create a new area it copies all the data from the area it is splitting. So using similar numbers from before, say you have a region with a size of 200 and the cur rect is 200 to 400. When the new area is created it will copy those numbers but the area will only be like 20 pixels wide at first, so it will resize down. Following the logic again it will shift over 180 so the cur rect will be 20 to 220 and then it will size down to the center, which leaves the cur rect at 110 to 130. This is clearly not reset all the way to the left. Here is from blender 3.2: [SplitOld.mp4](https://archive.blender.org/developer/F13487343/SplitOld.mp4) Obviously if you split from a very large area or a header that isn't scrolled very far, it can scroll enough that it looks like it reset back to the left, as in your example. So, with all that said, what is the proper fix? Is the scrolling a bug or a feature? I think there is a case to say that scrolling left on headers in some cases may be good. It tends to keep the headers scrolled left when you do any resizing, which may be ok even though it has edge cases. The problem with it is those edge cases, and it also leads to the situation where basically no one understands how the view2d code works. The reason I choose to just remove it in the patch and use the V2D_KEEPOFS_X is because everything I just described regarding why headers and outliner scroll when resizing smaller goes away and the logic for resizing basically boils down to this line: ``` cur->xmax += width - BLI_rctf_size_x(cur); ``` You are correct that when you make a new area it doesn't reset the header, it just copies the offset, but I would rather explicitly just reset the header when the area is duplicated then use the random scrolling that might or might not reset the header by scrolling. That would be a separate issue then. But this is just my opinion. Either way, it should not do what it is doing now and resize from the center when shrinking the region size. With 3.3 released there are probably going to be a deluge of reports about this.

Added subscriber: @ideasman42

@AnthonyEdlin - ...leads to the situation where basically no one understands how the view2d code works.

Yes, any chance to simplify this is worth trying for.

With 3.3 released there are probably going to be a deluge of reports about this.

Yes, we are getting one or two complaints per day now I think.

...I would rather explicitly just reset the header when the area is duplicated...

Like this? Not sure if there might be unintended consequence of resetting the view in ED_area_data_copy...

diff --git a/source/blender/editors/interface/view2d.cc b/source/blender/editors/interface/view2d.cc
index bb459f227f97..ca9b455db95d 100644
--- a/source/blender/editors/interface/view2d.cc
+++ b/source/blender/editors/interface/view2d.cc
@@ -269,61 +269,61 @@ void UI_view2d_region_reinit(View2D *v2d, short type, int winx, int winy)
       v2d->keeptot = V2D_KEEPTOT_STRICT;
       v2d->keepofs = (V2D_KEEPOFS_X | V2D_KEEPOFS_Y);
       tot_changed = do_init;
 
       /* scroller settings are currently not set here... that is left for regions... */
       break;
     }
     /* 'header' regions - zoom, aspect ratio,
      * alignment, and panning restrictions are set here */
     case V2D_COMMONVIEW_HEADER: {
       /* zoom + aspect ratio are locked */
       v2d->keepzoom = (V2D_LOCKZOOM_X | V2D_LOCKZOOM_Y | V2D_LIMITZOOM | V2D_KEEPASPECT);
       v2d->minzoom = v2d->maxzoom = 1.0f;
 
       if (do_init) {
         v2d->tot.xmin = 0.0f;
         v2d->tot.xmax = winx;
         v2d->tot.ymin = 0.0f;
         v2d->tot.ymax = winy;
         v2d->cur = v2d->tot;
 
         v2d->min[0] = v2d->max[0] = (float)(winx - 1);
         v2d->min[1] = v2d->max[1] = (float)(winy - 1);
       }
       /* tot rect has strictly regulated placement, and must only occur in +/+ quadrant */
       v2d->align = (V2D_ALIGN_NO_NEG_X | V2D_ALIGN_NO_NEG_Y);
       v2d->keeptot = V2D_KEEPTOT_STRICT;
       tot_changed = do_init;
 
       /* panning in y-axis is prohibited */
-      v2d->keepofs = V2D_LOCKOFS_Y;
+      v2d->keepofs = (V2D_KEEPOFS_X | V2D_LOCKOFS_Y);
 
       /* absolutely no scrollers allowed */
       v2d->scroll = 0;
       break;
     }
     /* panels view, with horizontal/vertical align */
     case V2D_COMMONVIEW_PANELS_UI: {
 
       /* for now, aspect ratio should be maintained,
        * and zoom is clamped within sane default limits */
       v2d->keepzoom = (V2D_KEEPASPECT | V2D_LIMITZOOM | V2D_KEEPZOOM);
       v2d->minzoom = 0.5f;
       v2d->maxzoom = 2.0f;
 
       v2d->align = (V2D_ALIGN_NO_NEG_X | V2D_ALIGN_NO_POS_Y);
       v2d->keeptot = V2D_KEEPTOT_BOUNDS;
 
       /* NOTE: scroll is being flipped in #ED_region_panels() drawing. */
       v2d->scroll |= (V2D_SCROLL_HORIZONTAL_HIDE | V2D_SCROLL_VERTICAL_HIDE);
 
       if (do_init) {
         const float panelzoom = (style) ? style->panelzoom : 1.0f;
 
         v2d->tot.xmin = 0.0f;
         v2d->tot.xmax = winx;
 
         v2d->tot.ymax = 0.0f;
         v2d->tot.ymin = -winy;
 
         v2d->cur.xmin = 0.0f;
diff --git a/source/blender/editors/screen/area.c b/source/blender/editors/screen/area.c
index 4e99e384f9f5..bbaf0aef91f5 100644
--- a/source/blender/editors/screen/area.c
+++ b/source/blender/editors/screen/area.c
@@ -2120,60 +2120,61 @@ void ED_region_toggle_hidden(bContext *C, ARegion *region)
 
 void ED_area_data_copy(ScrArea *area_dst, ScrArea *area_src, const bool do_free)
 {
   const char spacetype = area_dst->spacetype;
   const short flag_copy = HEADER_NO_PULLDOWN;
 
   area_dst->spacetype = area_src->spacetype;
   area_dst->type = area_src->type;
 
   area_dst->flag = (area_dst->flag & ~flag_copy) | (area_src->flag & flag_copy);
 
   /* area */
   if (do_free) {
     BKE_spacedata_freelist(&area_dst->spacedata);
   }
   BKE_spacedata_copylist(&area_dst->spacedata, &area_src->spacedata);
 
   /* NOTE: SPACE_EMPTY is possible on new screens. */
 
   /* regions */
   if (do_free) {
     SpaceType *st = BKE_spacetype_from_id(spacetype);
     LISTBASE_FOREACH (ARegion *, region, &area_dst->regionbase) {
       BKE_area_region_free(st, region);
     }
     BLI_freelistN(&area_dst->regionbase);
   }
   SpaceType *st = BKE_spacetype_from_id(area_src->spacetype);
   LISTBASE_FOREACH (ARegion *, region, &area_src->regionbase) {
     ARegion *newar = BKE_area_region_copy(st, region);
+    UI_view2d_curRect_reset(&newar->v2d);
     BLI_addtail(&area_dst->regionbase, newar);
   }
 }
 
 void ED_area_data_swap(ScrArea *area_dst, ScrArea *area_src)
 {
   SWAP(char, area_dst->spacetype, area_src->spacetype);
   SWAP(SpaceType *, area_dst->type, area_src->type);
 
   SWAP(ListBase, area_dst->spacedata, area_src->spacedata);
   SWAP(ListBase, area_dst->regionbase, area_src->regionbase);
 }
 
 /* -------------------------------------------------------------------- */
 /** \name Region Alignment Syncing for Space Switching
  * \{ */
 
 /**
  * Store the alignment & other info per region type
  * (use as a region-type aligned array).
  *
  * \note Currently this is only done for headers,
  * we might want to do this with the tool-bar in the future too.
  */
 struct RegionTypeAlignInfo {
   struct {
     /**
      * Values match #ARegion.alignment without flags (see #RGN_ALIGN_ENUM_FROM_MASK).
      * store all so we can sync alignment without adding extra checks.
      */

Any thoughts @ideasman42?

> @AnthonyEdlin - ...leads to the situation where basically no one understands how the view2d code works. Yes, any chance to simplify this is worth trying for. > With 3.3 released there are probably going to be a deluge of reports about this. Yes, we are getting one or two complaints *per day* now I think. > ...I would rather explicitly just reset the header when the area is duplicated... Like this? Not sure if there might be unintended consequence of resetting the view in ED_area_data_copy... ``` diff --git a/source/blender/editors/interface/view2d.cc b/source/blender/editors/interface/view2d.cc index bb459f227f97..ca9b455db95d 100644 --- a/source/blender/editors/interface/view2d.cc +++ b/source/blender/editors/interface/view2d.cc @@ -269,61 +269,61 @@ void UI_view2d_region_reinit(View2D *v2d, short type, int winx, int winy) v2d->keeptot = V2D_KEEPTOT_STRICT; v2d->keepofs = (V2D_KEEPOFS_X | V2D_KEEPOFS_Y); tot_changed = do_init; /* scroller settings are currently not set here... that is left for regions... */ break; } /* 'header' regions - zoom, aspect ratio, * alignment, and panning restrictions are set here */ case V2D_COMMONVIEW_HEADER: { /* zoom + aspect ratio are locked */ v2d->keepzoom = (V2D_LOCKZOOM_X | V2D_LOCKZOOM_Y | V2D_LIMITZOOM | V2D_KEEPASPECT); v2d->minzoom = v2d->maxzoom = 1.0f; if (do_init) { v2d->tot.xmin = 0.0f; v2d->tot.xmax = winx; v2d->tot.ymin = 0.0f; v2d->tot.ymax = winy; v2d->cur = v2d->tot; v2d->min[0] = v2d->max[0] = (float)(winx - 1); v2d->min[1] = v2d->max[1] = (float)(winy - 1); } /* tot rect has strictly regulated placement, and must only occur in +/+ quadrant */ v2d->align = (V2D_ALIGN_NO_NEG_X | V2D_ALIGN_NO_NEG_Y); v2d->keeptot = V2D_KEEPTOT_STRICT; tot_changed = do_init; /* panning in y-axis is prohibited */ - v2d->keepofs = V2D_LOCKOFS_Y; + v2d->keepofs = (V2D_KEEPOFS_X | V2D_LOCKOFS_Y); /* absolutely no scrollers allowed */ v2d->scroll = 0; break; } /* panels view, with horizontal/vertical align */ case V2D_COMMONVIEW_PANELS_UI: { /* for now, aspect ratio should be maintained, * and zoom is clamped within sane default limits */ v2d->keepzoom = (V2D_KEEPASPECT | V2D_LIMITZOOM | V2D_KEEPZOOM); v2d->minzoom = 0.5f; v2d->maxzoom = 2.0f; v2d->align = (V2D_ALIGN_NO_NEG_X | V2D_ALIGN_NO_POS_Y); v2d->keeptot = V2D_KEEPTOT_BOUNDS; /* NOTE: scroll is being flipped in #ED_region_panels() drawing. */ v2d->scroll |= (V2D_SCROLL_HORIZONTAL_HIDE | V2D_SCROLL_VERTICAL_HIDE); if (do_init) { const float panelzoom = (style) ? style->panelzoom : 1.0f; v2d->tot.xmin = 0.0f; v2d->tot.xmax = winx; v2d->tot.ymax = 0.0f; v2d->tot.ymin = -winy; v2d->cur.xmin = 0.0f; diff --git a/source/blender/editors/screen/area.c b/source/blender/editors/screen/area.c index 4e99e384f9f5..bbaf0aef91f5 100644 --- a/source/blender/editors/screen/area.c +++ b/source/blender/editors/screen/area.c @@ -2120,60 +2120,61 @@ void ED_region_toggle_hidden(bContext *C, ARegion *region) void ED_area_data_copy(ScrArea *area_dst, ScrArea *area_src, const bool do_free) { const char spacetype = area_dst->spacetype; const short flag_copy = HEADER_NO_PULLDOWN; area_dst->spacetype = area_src->spacetype; area_dst->type = area_src->type; area_dst->flag = (area_dst->flag & ~flag_copy) | (area_src->flag & flag_copy); /* area */ if (do_free) { BKE_spacedata_freelist(&area_dst->spacedata); } BKE_spacedata_copylist(&area_dst->spacedata, &area_src->spacedata); /* NOTE: SPACE_EMPTY is possible on new screens. */ /* regions */ if (do_free) { SpaceType *st = BKE_spacetype_from_id(spacetype); LISTBASE_FOREACH (ARegion *, region, &area_dst->regionbase) { BKE_area_region_free(st, region); } BLI_freelistN(&area_dst->regionbase); } SpaceType *st = BKE_spacetype_from_id(area_src->spacetype); LISTBASE_FOREACH (ARegion *, region, &area_src->regionbase) { ARegion *newar = BKE_area_region_copy(st, region); + UI_view2d_curRect_reset(&newar->v2d); BLI_addtail(&area_dst->regionbase, newar); } } void ED_area_data_swap(ScrArea *area_dst, ScrArea *area_src) { SWAP(char, area_dst->spacetype, area_src->spacetype); SWAP(SpaceType *, area_dst->type, area_src->type); SWAP(ListBase, area_dst->spacedata, area_src->spacedata); SWAP(ListBase, area_dst->regionbase, area_src->regionbase); } /* -------------------------------------------------------------------- */ /** \name Region Alignment Syncing for Space Switching * \{ */ /** * Store the alignment & other info per region type * (use as a region-type aligned array). * * \note Currently this is only done for headers, * we might want to do this with the tool-bar in the future too. */ struct RegionTypeAlignInfo { struct { /** * Values match #ARegion.alignment without flags (see #RGN_ALIGN_ENUM_FROM_MASK). * store all so we can sync alignment without adding extra checks. */ ``` Any thoughts @ideasman42?

@AnthonyEdlin

I updated D15873: Fix #100141: Header Alignment of New Editors to add that V2D_KEEPOFS_X and to reset the views of the new area - but doing so inside area_split so it can't affect anything else.

One thing I have not been able to confirm fixed - because I haven't been able to recreate the issue - is complaints like #100933 (3.3.0 Menu Bars Partly Hidden On Small Monitor) where the initial layout has the main menu scrolled over when the monitor is very small.

@Harley

I'm sure resetting all regions in ED_area_data_copy must screw up graph views and VSE views at least. At very least want to just reset header regions, and preferably just when splitting for now.

I did it with this diff, but haven't tested it extensively:

fix_headers_offset_x_with_header_reset.diff

@AnthonyEdlin - want to just reset header regions, and preferably just when splitting for now.

Good point. I updated D15873: Fix #100141: Header Alignment of New Editors to only reset headers.

Hi, I'm not a developer, I just want to say something, not only the newly split editor. All editors have this type of problem when they are zoomed out. When the header is full, it will be center aligned. Older versions always keep left-aligned.

20220915_11.48_721.mp4

@Leroy-Xie ....I just want to say something, not only the newly split editor...

Yes, test D15873: Fix #100141: Header Alignment of New Editors to confirm.

Added subscribers: @blender.girl, @Aliderees, @greninjakdkd

Added subscriber: @RP-3

Added subscriber: @ellie553

Added subscribers: @Akadyan, @ThomasDinges

Closed as duplicate of #101187

Changed status from 'Duplicate' to: 'Confirmed'

Argh, sorry merged the wrong way.

Added subscriber: @Sorataemin

Added subscribers: @SME73, @deadpin

This issue was referenced by 4b0243dae4

This issue was referenced by c172522060

Changed status from 'Confirmed' to: 'Resolved'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: Right aligned header #100141