Open ahfakt opened 8 months ago
This patch breaks the reuse of statusbaritem.
With current API, recreating items is the only way to update positions. Is it mandatory for other functionalities, is there any reference to the created UI elements?
You can reuse statusbaritems in the same location, create missing ones, hide or delete redundant ones.
For the interface definition, it should remain the same as statusbaritem, that is, use alignment and priority.
Once an item created, you can't change position or alignment of it. Updating a task's position or offset setting will not be visible. Find updated items, recreate only them and reuse others, that is too much work. Is it worth it? Because I don't even know how to do it.
Add alignment and priority to the settings, will this solve your problem?
Currently, I have no problem. I developed a solution that gives the ability to configure each item's position individually in the status bar. If I want to see updated result immediately when I change for example position property of a task in tasks.json, UI elements must be recreated. Your first comment says this behaviour breaks reusing UI objects. Why we should try to reuse them. It's not a heavy operation. There is no reference to UI objects. Is it just a statement or really a problem to merge?
This is a feature and I don't want to break it.
Thanks for your quick comments but I don't understand what is the feature you want to preserve, is it undocumented?
No particular reason. For anything that already exists, don't break it unless necessary.
For your request, vscode-tasks are designed so that all statusbaritems are together, they are a whole. Separating them into different places can cause a lot of confusion.
When you have a lot of tasks, vscode-tasks will add a select statusbaritem, which should appear after all statusbaritems. So where should it appear now?
So statusbaritems as a whole, I think it is acceptable to modify its priority in the setting. But they should not be separated.
If a user does not set any position configuration it works just like as you describe. But if I want custom layout with just a few item this PR gives me the ability to do that. I think we need a less restrictive perspective.
Add "position" property to "statusbar" option to control where the item will be located in the status bar. There is a similar PR but this solves problem with an extra "offset" setting and flexibility to choose the side of the item(left or right).