feat(namespace): allow setting namespace when a new window is opened.

[fortime]

I don't know what actually the namespace is used for. But it seems that we can allow the client to specify the namespace for each surface.

wayland protocol:

Clients can specify a namespace that defines the purpose of the layer surface.

[Decodetalkers]

I do not think it is needed, the namespace won't be shown anywhere, and seems it is just used to find the program..

If you really want to add one, I think we need to add another field in StateUnit, and store the namespace in that place. But I still think it is not needed

[fortime]

Actually, I don't need namespace.

At first, I am working on #141 , I think it is like title in iced_winit. But it isn't . Unlike theme and style, namespace can't be updated after created. It looks like namespace is used before StateUnit is created, and there is no way for the client to provide namespace except in the NewLayerShellSettings message.

[Decodetalkers]

Actually, I don't need namespace.

At first, I am working on #141 , I think it is like title in iced_winit. But it isn't . Unlike theme and style, namespace can't be updated after created. It looks like namespace is used before StateUnit is created, and there is no way for the client to provide namespace except in the NewLayerShellSettings message.

So I think keep it as now it is will be better, since it is unchangable value, and is decided when surface is created. When you come out the idea to use this field, then I will be glad to accept this pr

[fortime]

@Decodetalkers
I found a use case in kwin. kwin uses namespace (scope in kwin) to set the window type.
the code is here: https://invent.kde.org/plasma/kwin/-/blob/v6.3.5/src/layershellv1window.cpp?ref_type=tags#L45.

Maybe we can add this in iced14.

[Decodetalkers]

@Decodetalkers
I found a use case in kwin. kwin uses namespace (scope in kwin) to set the window type.
the code is here: https://invent.kde.org/plasma/kwin/-/blob/v6.3.5/src/layershellv1window.cpp?ref_type=tags#L45.

Maybe we can add this in iced14.

Ok, I have understand this usecase, but I want some specific example.

Emm, then for example, can you tell me some unique namespace, and how does the application perform when being set to that namespace.

[fortime]

namespaces specified by kwin can be found in the same file. here is the code:

static WindowType scopeToType(const QString &scope)
{
    static const QHash<QString, WindowType> scopeToType{
        {QStringLiteral("desktop"), WindowType::Desktop},
        {QStringLiteral("dock"), WindowType::Dock},
        {QStringLiteral("crititical-notification"), WindowType::CriticalNotification},
        {QStringLiteral("notification"), WindowType::Notification},
        {QStringLiteral("tooltip"), WindowType::Tooltip},
        {QStringLiteral("on-screen-display"), WindowType::OnScreenDisplay},
        {QStringLiteral("dialog"), WindowType::Dialog},
        {QStringLiteral("splash"), WindowType::Splash},
        {QStringLiteral("utility"), WindowType::Utility},
    };
    return scopeToType.value(scope.toLower(), WindowType::Normal);
}

In kwin, different window types will have different effects. The definition of WindowType can be found here: https://invent.kde.org/plasma/kwin/-/blob/v6.3.5/src/effect/globals.h#L331. For example, if the window will be shown when Alt + Tab is pressed.

Here are some code snippets about different window types in kwin window.cpp.

bool Window::wantsTabFocus() const
{
    return (isNormalWindow() || isDialog() || isAppletPopup()) && wantsInput();
}
LayerShellV1Window
bool Window::isSpecialWindow() const
{
    // TODO
    return isDesktop() || isDock() || isSplash() || isToolbar() || isNotification() || isOnScreenDisplay() || isCriticalNotification();
}

But LayerShellV1Window overrides some methods of Window, so I'm not sure about the difference in behavior between the different namespaces.

I think here we should not focus on what namespace effects. But we should allow an application opening windows in different namespaces. The effect of a namespace depends on the implementation of a compositor.

[Decodetalkers]

Ok, can you rebase this pr, to make the flow run again?

[Decodetalkers]

yes, now you should push to master now, iced14 branch is merged now.. sorry not to tell you

[fortime]

yes, now you should push to master now, iced14 branch is merged now.. sorry not to tell you

I have rebased it on master. Can you have a review of it?

[Decodetalkers]

Maybe the first clone is not needed I think

[fortime]

done. It's weird that I remember it is a reference before. And clippy doesn't find it out.

[Decodetalkers]

Thank you