starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

BUG? Microsoft Outlook, "Reminders Window" #468

New Issue
Closed
opened 2026-01-05 14:50:55 +01:00 by adam · 8 comments
adam commented 2026-01-05 14:50:55 +01:00
Owner
Copy Link

Originally created by @ComputerCulture on GitHub (Sep 7, 2024).

Hi @LGUG2Z

Microsoft Outlook Reminders Window shows up on all work spacers when changing to a new workspace, yet the main UI will stay on the work space it was open on.
Is this a bug? or how can it be implemented so the small reminders window in outlook remains on the same work space as the main UI

Thank you...

Originally created by @ComputerCulture on GitHub (Sep 7, 2024). Hi @LGUG2Z Microsoft Outlook Reminders Window shows up on all work spacers when changing to a new workspace, yet the main UI will stay on the work space it was open on. Is this a bug? or how can it be implemented so the small reminders window in outlook remains on the same work space as the main UI Thank you...
adam added the bug label 2026-01-05 14:50:55 +01:00
adam closed this issue 2026-01-05 14:50:55 +01:00
adam commented 2026-01-05 14:50:55 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 7, 2024):

Can you share an image of this? I don't use Outlook so I can't visualize what you're describing.

Generally, popups or windows that are ignored are completely ignored by komorebi, so they will appear wherever the operating system tells them to appear and komorebi will never try to do anything with them.

@LGUG2Z commented on GitHub (Sep 7, 2024): Can you share an image of this? I don't use Outlook so I can't visualize what you're describing. Generally, popups or windows that are ignored are _completely ignored_ by komorebi, so they will appear wherever the operating system tells them to appear and komorebi will never try to do anything with them.
adam commented 2026-01-05 14:50:55 +01:00
Author
Owner
Copy Link

@ComputerCulture commented on GitHub (Sep 8, 2024):

Hi @LGUG2Z

Thank you for your reply, i have attached an image of Microsoft Outlook the main UI and the
"Reminders Window"
I have tried other tiling window managers and also windows virtual desktop and the reminders window will not show up on other work spacers
Outlook Reminders Window

@ComputerCulture commented on GitHub (Sep 8, 2024): Hi @LGUG2Z Thank you for your reply, i have attached an image of Microsoft Outlook the main UI and the "Reminders Window" I have tried other tiling window managers and also windows virtual desktop and the reminders window will not show up on other work spacers ![Outlook Reminders Window](https://github.com/user-attachments/assets/6a001f53-8e58-4de2-980e-51fba4f2847f)
adam commented 2026-01-05 14:50:55 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (Sep 20, 2024):

That window is always set to float with a rule on application-specific-configuration. That is needed otherwise komorebi would try to tile that window, which is probably not what you want for a reminders window. The downside of having it set to float is that komorebi ignores it, so it won't hide it when you change workspace.

@LGUG2Z Maybe we could change this behaviour and instead of ignoring the windows we could add them to the floating_windows of the workspace. This way the windows would still be tied to that workspace and be properly hidden when changing workspaces. I know you've previously mentioned adding an ignored-rules to separate the windows one wants to be floating from the ones that need to be ignored and this issue is a case that would be fixed by that...

@alex-ds13 commented on GitHub (Sep 20, 2024): That window is always set to float with a rule on `application-specific-configuration`. That is needed otherwise komorebi would try to tile that window, which is probably not what you want for a reminders window. The downside of having it set to float is that komorebi ignores it, so it won't hide it when you change workspace. @LGUG2Z Maybe we could change this behaviour and instead of ignoring the windows we could add them to the `floating_windows` of the workspace. This way the windows would still be tied to that workspace and be properly hidden when changing workspaces. I know you've previously mentioned adding an `ignored-rules` to separate the windows one wants to be floating from the ones that need to be ignored and this issue is a case that would be fixed by that...
adam commented 2026-01-05 14:50:56 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (Oct 11, 2024):

You can now fix this with the latest version on master doing this:

    "manage_rules": [
        [
            {
                "kind": "Exe",
                "id": "OUTLOOK.EXE",
                "matching_strategy": "Equals"
            },
            {
                "kind": "Class",
                "id": "#32770",
                "matching_strategy": "Equals"
            }
        ]
    ],
    "floating_applications": [
        [
            {
                "kind": "Exe",
                "id": "OUTLOOK.EXE",
                "matching_strategy": "Equals"
            },
            {
                "kind": "Class",
                "id": "#32770",
                "matching_strategy": "Equals"
            }
        ]
    ],

Then if you want it to always be on the same workspace you can add a workspace_rule for that specific workspace, like this:

    "monitors": [
        {
            "workspaces": [
                {
                    "name": "1",
                    "layout": "BSP",
                    "workspace_rules": [
                        [
                            {
                                "kind": "Exe",
                                "id": "OUTLOOK.EXE",
                                "matching_strategy": "Equals"
                            },
                            {
                                "kind": "Class",
                                "id": "#32770",
                                "matching_strategy": "Equals"
                            }
                        ]
                    ]
                },
                {
                    "name": "2",
                    "layout": "VerticalStack"
                }
            ]
        }
    ],

This will force that reminders window to always show on workspace 1.

@LGUG2Z If you think this is an acceptable solution to this problem maybe you can close this issue. I couldn't find another way of bypassing application-specific-configuration rules, besides force managing the window and then setting it to floating_windows as well. There might be some rules on application-specific-configuration that could be changed from ignore_rules to floating_windows, but I guess those might show up naturally once the users start to use this and realize that there are other windows they would prefer have floating, instead of ignored and start asking for it...

@alex-ds13 commented on GitHub (Oct 11, 2024): You can now fix this with the latest version on master doing this: ```jsonc "manage_rules": [ [ { "kind": "Exe", "id": "OUTLOOK.EXE", "matching_strategy": "Equals" }, { "kind": "Class", "id": "#32770", "matching_strategy": "Equals" } ] ], "floating_applications": [ [ { "kind": "Exe", "id": "OUTLOOK.EXE", "matching_strategy": "Equals" }, { "kind": "Class", "id": "#32770", "matching_strategy": "Equals" } ] ], ``` Then if you want it to always be on the same workspace you can add a `workspace_rule` for that specific workspace, like this: ```jsonc "monitors": [ { "workspaces": [ { "name": "1", "layout": "BSP", "workspace_rules": [ [ { "kind": "Exe", "id": "OUTLOOK.EXE", "matching_strategy": "Equals" }, { "kind": "Class", "id": "#32770", "matching_strategy": "Equals" } ] ] }, { "name": "2", "layout": "VerticalStack" } ] } ], ``` This will force that reminders window to always show on workspace 1. @LGUG2Z If you think this is an acceptable solution to this problem maybe you can close this issue. I couldn't find another way of bypassing `application-specific-configuration` rules, besides force managing the window and then setting it to `floating_windows` as well. There might be some rules on `application-specific-configuration` that could be changed from `ignore_rules` to `floating_windows`, but I guess those might show up naturally once the users start to use this and realize that there are other windows they would prefer have floating, instead of ignored and start asking for it...
adam commented 2026-01-05 14:50:56 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 11, 2024):

Then if you want it to always be on the same workspace you can add a workspace_rule for that specific workspace, like this:

I don't think this is implemented for floating applications yet 🤔

@LGUG2Z commented on GitHub (Oct 11, 2024): > Then if you want it to always be on the same workspace you can add a workspace_rule for that specific workspace, like this: I don't think this is implemented for floating applications yet 🤔
adam commented 2026-01-05 14:50:56 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (Oct 11, 2024):

Then if you want it to always be on the same workspace you can add a workspace_rule for that specific workspace, like this:

I don't think this is implemented for floating applications yet 🤔

Oh right! Didn't think of that... I can look into adding that. But can't do it in time for this Saturday's nightly release...

@alex-ds13 commented on GitHub (Oct 11, 2024): > > Then if you want it to always be on the same workspace you can add a workspace_rule for that specific workspace, like this: > > I don't think this is implemented for floating applications yet 🤔 Oh right! Didn't think of that... I can look into adding that. But can't do it in time for this Saturday's nightly release...
adam commented 2026-01-05 14:50:56 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 11, 2024):

Workspace rules are always lagging behind since the start of the project 🙃 they only recently got full support for all matchers 😅

@LGUG2Z commented on GitHub (Oct 11, 2024): Workspace rules are always lagging behind since the start of the project 🙃 they only recently got full support for all matchers 😅
adam commented 2026-01-05 14:50:56 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (Dec 26, 2024):

@LGUG2Z This issue should have been close with the merge of #1060. I must not have linked it properly... I think you can close it now!

@alex-ds13 commented on GitHub (Dec 26, 2024): @LGUG2Z This issue should have been close with the merge of #1060. I must not have linked it properly... I think you can close it now!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#468
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?