An alternative I could imagine would be to suppress OSDs entirely when viewing full-screen window content, much like how non-critical notifications are suppressed in this case.

I tried not to move it down too far or else it would interfere with subtitles in videos.

The problem with this patch is that the proposed placement area is based on personal preferences of one person. Have you considered placing OSDs somewhere else so they interfere with screen contents less? e.g. in screen corners, etc?

In D29263#659354, @zzag wrote:

I tried not to move it down too far or else it would interfere with subtitles in videos.

The problem with this patch is that the proposed placement area is based on personal preferences of one person. Have you considered placing OSDs somewhere else so they interfere with screen contents less? e.g. in screen corners, etc?

I believe @filipf is working on that. One complication is that both the current and proposed OSD designs only looks good horizontally centered, but the placement is done in KWin which has no knowledge of the visual style. @filipf told me that an ugly hack was needed to override the positioning from the plasma theme, so maybe that's an area for improvement, so that Plasma themes can determine for themselves where they'd like the OSD positioned based on its visual design.

Which OSDs do you intend to change and which ones do you intend to remain as is?

In D29263#659424, @davidedmundson wrote:

Which OSDs do you intend to change and which ones do you intend to remain as is?

This patch is a proposal to make D20569 work better. So the answer would be "all of them" if D20569 lands.

I think the OSD QML should be able to govern its relative screen position. This way one could make a look and feel package where the OSD is a vertical bar in a corner, for instance, like some other popular OS does it. Right now everyone's forced into the same spot.

If we want to change "all of them " we need patches in kscreen (2) and a patch in kwin's osd.

It sucks that it's so fragmented.

I don't think we should care about the KScreen OSD positioning in this discussion. It's a dialog you have to interact with, whereas the volume OSD is just feedback for something you've just pressed and like to be somethign you do while watching a video and so on

In D29263#659557, @broulik wrote:

I don't think we should care about the KScreen OSD positioning in this discussion. It's a dialog you have to interact with, whereas the volume OSD is just feedback for something you've just pressed and like to be somethign you do while watching a video and so on

Yeah.

If we can control positioning from QML in the plasma theme, I'll happily abandon this. Conceptually that seems more appropriate anyway since that design of the OSD itself largely determines which area of the screen is appropriate for it to appear in. A vertical OSD will be more at home in a corner, a horizontal one will be more at home near the top or bottom, etc.

With the smaller appearance, I'm feeling a bit like it just floats there... for no reason... it gives me the impression than there's no visual connection with anything. It's a bit like it's in a random position, maybe because it's not vertically centered. Could be fine anyway, but I was wondering if there's another place where it would better fit. Maybe top left? Can it avoid panels?

Ping. I think this is a mild improvement

In D29263#673009, @niccolove wrote:

With the smaller appearance, I'm feeling a bit like it just floats there... for no reason... it gives me the impression than there's no visual connection with anything.

Well, that's the truth! :)

I was wondering if there's another place where it would better fit. Maybe top left? Can it avoid panels?

Various folks suggested making it a notification, and then it would show up in the same position as the rest of the notifications in the stack. That might work, though IIRC the suggestion didn't prove very popular.

If we put it in the corner, I feel like a vertical OSD would be better; in fact IMO the optimal positioning inherently depends on the shape of the OSD. However right now we don't have customizable OSDs so all we can really do is make the KWin-determined positioning match the size and shape of the default one. In the long term, I would support making the OSDs changeable via GHNS, as David suggested in D20569--and even better, the GHNS OSD theme would be able to specify a preferred location which KWin would honor. That would be really nice.

However that's a very significant undertaking and not doing this because we want that will just kill this forever while we wait (as it did last time @broulik tried).

I'm feeling pretty lukewarm about this idea. It's maybe slightly better in some situations, but with the smaller size, I think it'll also be easier to miss if it's not in the center. Since the OSD is smaller, being exactly in the center isn't such a huge problem either. Although, I suppose it would still get in the way of crosshairs if the user was playing a shooter game.

In D29263#673015, @ndavis wrote:

I'm feeling pretty lukewarm about this idea. It's maybe slightly better in some situations, but with the smaller size, I think it'll also be easier to miss if it's not in the center. Since the OSD is smaller, being exactly in the center isn't such a huge problem either. Although, I suppose it would still get in the way of crosshairs if the user was playing a shooter game.

That's the problem that's being at least (supposedly, hopefully) being improved on here. There are other things also typically right in the center of the screen: actors' mouths when watching a movie or a video, for example.

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Non-Breeze OSDs will be affected? If so, that seems bad.

How do you think about putting it horizontally centered at the top of the screen? Maybe even avoiding panels, if possible?
I'd be fine both with "floating a bit under the panel" and "merged with screen/panel top" like krunner.

I don't think it's a problem to change this even for non-breeze themes.

It might be best not to change anything about the position until we can come up with a significantly better solution.

In D29263#673062, @niccolove wrote:

How do you think about putting it horizontally centered at the top of the screen? Maybe even avoiding panels, if possible?
I'd be fine both with "floating a bit under the panel" and "merged with screen/panel top" like krunner.

I don't think it's a problem to change this even for non-breeze themes.

That seems like it could be a sensible solution, yeah.

However @ndavis might be right that we should come up with a way for themes to override the positioning first--especially if we do that. A square OSD will look kind of weird jammed up at the top of the screen.

I don't think this patch in its current form will cause problems for 3rd-party themes, though. The new position is not much farther down than the current one. It's a pretty small change.

I'm a bit confused. Aren't we changing the size for third party global themes as well? Do all global themes set their size?

In D29263#673135, @niccolove wrote:

I'm a bit confused. Aren't we changing the size for third party global themes as well? Do all global themes set their size?

That depends on whether or not the global theme has its own OSD qml files. You will find that some do, while others don't. So yes, there will still be square OSDs out there.

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Personally I would be fine with it.
It changes the default for the best.

It will change all themes yes, but all had the same issue.
Having a setting for themes to choose an OSD placement is an orthogonal matter and a preexistant issue IMO.

And users will really enjoy this with D20569 landed already.

As a side note, a missing feature of this API would be to be able to select the screen to display the Osd on, so that KScreen could share the same code path and theming.
And maybe another to prevent osd to a specified screen, i.e presentation windows like libreoffice impress.

@davidedmundson ?

LGTM :)

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Speaking for myself, I'm not. I don't like 0.37 because it's not based on anything. Why not 0.39 or 0.4242?

In D29263#673249, @zzag wrote:

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Speaking for myself, I'm not. I don't like 0.37 because it's not based on anything. Why not 0.39 or 0.4242?

The existing magic number is also totally random, and does not even match what it says it will do (it results in an OSD position about 45% up, not in the bottom third as it claims.

Do you have a suggestion?

In D29263#673250, @ngraham wrote:

The existing magic number is also totally random, and does not even match

I wouldn't say that fractions such as 1/2, 1/4, 1/3, 2/3 and so on are that random.

what it says it will do (it results in an OSD position about 45% up, not in the bottom third as it claims.

The placement area and the screen area are different.

Do you have a suggestion?

area.top() + 2 * area.height() / 3 - c->height() / 2?