Query Tool: Modified mark (*) appears after the filename in the tab instead of before it

[dvemil]

In the Query Tool, when a query file is modified (unsaved changes), the modified indicator (asterisk *) is shown after the filename in the tab title.
It should appear before the filename (standard behavior in most editors/IDEs).

Current behavior
filename.sql *

Expected behavior
* filename.sql
Having the modified mark before the filename is the conventional UI pattern and improves readability of the tab titles.

To Reproduce
Open the Query Tool.
Open or create a query file.
Make any change so the file becomes modified.
Observe the tab title — the * is placed after the filename.

Desktop: Windows 11
pgAdmin version: 9.16

[dev-hari-prasad]

Thanks @dvemil for raising this, especially considering the attention to detail. I think the motivation makes sense, especially since some editors do place modified indicators near the filename.

That said, I’d be a little cautious about moving it. Existing pgAdmin users are already used to the current layout, and putting the indicator before the filename would also make the filename shift every time the tab changes between saved and unsaved (which is a little bit of work for both brain and the eyes). Keeping it trailing means the filename stays anchored, which makes scanning tabs easier.

Also, there isn’t really a universal convention here. VS Code, for example, uses a dot at the end of the tab rather than a leading marker. Some applications use the trailing behaviour while others do the opposite.

If the main goal is simply to make the modified state more noticeable, I think there’s a better middle ground here. We could use a more visually distinct dot indicator, similar to VS Code, while still keeping it at the end of the tab. That would make it easier to spot unsaved files.

But even this comes at the cost of a entirely different user experience which can confuse some users and is arguably more confusing for some users. It would be good to hear a the solution from a third person who can evaluate this (preferably a mainainter).

Although I personally lean towards the current behaviour.