Affinity Suite: moving files tabs

[Pyanepsion]

The current behavior of file tab movement is highly counterintuitive and difficult to control.

Improving the ergonomics of tab handling would be particularly beneficial. Currently, in the Affinity suite, a file tab detaches as soon as it moves slightly outside the tab bar’s boundary, and when reinserted, it is always placed at the far right, regardless of the intended position.

→ The current tab management feels outdated compared to modern UI expectations.

By comparison, editors such as Notepad++ and Visual Studio Code follow a more flexible and predictable logic:

1. the user clicks and holds a tab,

2. the tab can be moved freely, without strict vertical or horizontal alignment constraints,

3. the button is released approximately where the tab should go,

4. the tab is inserted precisely at the intended position, respecting the order of existing tabs.

This behavior allows for fast, fluid, and fully controllable rearrangement, with no unexpected results.

Notepad++: moving tabs, and pinned tabs

[MikeTO]

I believe this is a known bug.

In the screenshot below, I am dragging the Pages tab from the very left to the very right of the tab group. It's impossible because even when I've dragged it as far to the right as I can go without dragging it out of the tab group, the "drop zone" gap is between the Reading Order (R) and Table of Contents (TO) tabs and not where the tab and mouse pointer are located.

[Oufti]

3 hours ago, Pyanepsion said:

Currently, in the Affinity suite, a tab detaches as soon as it moves slightly outside the tab bar’s boundary, and reinserting it always places it at the far right, regardless of the intended position.

As @MikeTO showed, I also don't exactly see the same issue as you.
For me, if i drag a tab out of its bar I can place it again, more or less to where I want. The same if I only drag it inside its bar. 
(The only problem is when there are many many panels tabs, as you can see on the left studio at the end of my video, then all places are not accessible, so I sometimes have to move the right side tabs to the left instead of placing a a single left one to the right… I believe it's related to the length of the panel name. I've never this problem with file tabs.)

BTW I'm not sure if you talked about the panels/studio tabs (as illustrated by MikeTO) or about  the file tabs (as shown in your Notepad++ example)? I illustrated both. 

Anyway, I totally agree with you that could be made better — but behaviour is not exactly the same. Could it be because you're on a Windows PC?

 

[Pyanepsion]

Just to clarify: I’m talking about file tabs, meaning the documents opened at the top of the workspace – not panel tabs like those in the Studio on the left or right.

On Windows, when I try to rearrange a file tab in the tab bar, it almost always detaches and becomes a floating window. When I reinsert it, it’s automatically placed at the far right, regardless of the position I intended.

This behavior is what I find frustrating and unintuitive, especially compared to editors like Notepad++ (video in first message) or VSCode, where tabs move exactly where you drop them.

My explanation was apparently misunderstood. I suspect it may have been due to a poor translation of my original message in French. So this time, I’ve recorded a video directly in Affinity to illustrate the issue more clearly. See at 8s and 25s.

 

 

 

[Ali]

In Publisher. if I click and drag the right-most panel (tab) directly to the left. I can move it to the left-most position. If I detach it first, I have no control over where it goes back. So, try dragging horizontally instead to re-order your tabs.

[Pyanepsion]

@Ali 🙂That’s exactly the issue — the file tab detaches too easily, even with careful horizontal dragging. The second video shows how hard it is to control. Compare it with the first video using another software — there, tab movement is smooth and predictable.

[Ali]

I don't find it hard to control at all - I have done it several times this morning to test the issue and found it perfectly smooth. In fact, I completely failed to detach the tab by accident.

I do agree, however, that detached tabs should be able to be replaced at whichever position the user chooses.

[Pyanepsion]

The issue becomes more noticeable as screen size and resolution increase, particularly on today's most common displays (24–27").

Tabs detach too easily, even when dragged carefully in a straight line — see the second video (recorded on a 5K screen).

This sensitivity makes the behaviour problematic and worth fixing.

[Ali]

Maybe being able to constrain the drag with a modifier key might be a good idea. Resolution-wise, mine is 2560 x 1600 (17") - I have a 24" external monitor, but don't have it connected at the moment to test.

[Oufti]

3 hours ago, Pyanepsion said:

On Windows, when I try to rearrange a file tab in the tab bar, it almost always detaches and becomes a floating window. When I reinsert it, it’s automatically placed at the far right, regardless of the position I intended.

Thank you @Pyanepsion. It seems to be Windows specific.

On macOS,
1) File tabs only detach when they are dragged below the ruler or above the middle of the contextual toolbar;

2) When a file tab is detached, I can replace it where I want. 

 

 

[Pyanepsion]

23 hours ago, Ali said:

Maybe being able to constrain the drag with a modifier key […]

→ Not at all! On the contrary, the solution should lie in simplification.

The perpendicular constraint should simply be removed.

The tab movement should be interpreted only along the main axis of the bar (horizontal in this case), and its position confirmed only upon release of the mouse button.

This would prevent accidental detachment while maintaining a simple, fluid, and intuitive behavior.

🙂This is, in fact, the rule followed by most modern software.

[Ali]

Well, as I can't replicate the problem on any of my monitors, I shan't comment further. Have you raised a ticket with Serif so that they can investigate? 

[CobaltDragon]

On 6/17/2025 at 11:34 PM, Pyanepsion said:

→ Not at all! On the contrary, the solution should lie in simplification.

The perpendicular constraint should simply be removed.

The tab movement should be interpreted only along the main axis of the bar (horizontal in this case), and its position confirmed only upon release of the mouse button.

This would prevent accidental detachment while maintaining a simple, fluid, and intuitive behavior.

🙂This is, in fact, the rule followed by most modern software.

I have a personal fix that I use for Designer v1 to lock tab movement horizontally. It could be adapted to all the v1+2 apps (Windows only). Below is a quick demo video. Would this be useful?

[Pyanepsion]

That sounds promising. Would you mind explaining how you did it?

[CobaltDragon]

8 hours ago, Pyanepsion said:

That sounds promising. Would you mind explaining how you did it?

Certainly. I wrote a utility for myself that constrains mouse movement to the horizontal axis when dragging the file tabs, thus preventing accidental detachment. I could adapt and spin out my personal code into a small standalone application if you or others are interested. What do you think?