The shadows look now better than in the first revision. Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

Fix tested and issues are gone.

Qt 5.11.1

Plasmashell background is black and its surfaces are misplaced with this commit.

The patch to KWayland D12388 for arbitrary color curve manipulation has a problem from the start: Wayland protocol messages can only be max 4KB. Sending an array of 256 16bit colors is this. But what if a hardware supports finer curves?

For 5.52.

• Remove rects call
• Respect buffer scale
• Test damage against scaled surface

• Update version number
• Do code duplication instead of pointers
• Add comment about code duplication

Rebase on master.

On the other side does it sometimes make sense to specify a port manually even if KWin could take the next free one? I would say yes if I have a client to test against, which I can provide with a socket argument (I don't need to query which free socket actually was taken by KWin). So in the end we want to have both methods anyway.

Is there a real reason against it besides "not necessary"? Maybe that we can't remove the manual override again without breaking some API promise once we have the grand solution of automatically taking the next free Wayland socket?

In T9780#162277, @ngraham wrote:

There is a much simpler alternative: whether borders are shown or not, when touch input is used to make contact with the screen near a screen edge, make the drag resize areas outside the window as big as the titlebar currently is (it's more or less the bare minimum size for comfortable touch). That way we don't have to answer any of the above questions and it'll behave just like people expect, with the finger basically being a virtual cursor.

Please add the context. Either by using arc or by supplying git diff the -U99999parameter

Optimization can mean many things. That's why I asked. The "+1" should then go in a separate patch.

Is this a pure code cleanup, or also includes some logic change?

@zzag Do you wait for another review by @davidedmundson ?

One idea I had was to start a resize only when two opposing corners are dragged (from the quadrants of their outer most area). But this wouldn't work with windows adjacent to a screen border. Related would be to start a resize when one finger lasts in the window to resize (or its window bar) and a second finger is used for resize somewhere around the window..

I created a task for brainstorming a distinct window touch resize interaction pattern: T9780

Imo this patch can go in as it is, but before that I would like to see a patch to have the disk with the root file system getting specially marked (icon, color or text) for the case that several block devices are mounted at the same time.

No, I don't remember. But I don't think it's really a problem. I have used no window borders setting now for several months and never felt annoyed with the resize area over other windows.

Whoops, yea. My fault. I think it's fine to replace the name, since Qt/GTK use the correct one and normally apps use these libs instead of setting such properties directly.

In D15353#323028, @zzag wrote:

In D15353#322991, @aacid wrote:

I'm not a KWindowSystem developer so take this with a grain of salt, but maybe it makes sense to still support the old name in case someone is really using it and add the new one as a synonym?

Well, no, _NET_WM_WINDOW_TYPE_COMBOBOX is a KWindowSystem's specific implementation thing/typo, it's not used widely. GTK+ and Qt set _NET_WM_WINDOW_TYPE_COMBO. So, I think we shouldn't add a new synonym.

Rebase on master.

Rebase on master.

Rebase on master.

Rebase on master.

Rebase on master.

If there are more items than space available in the list a line is drawn already now to indicate that there are more items to come by scrolling down. Does this not conflict with the new line?

Rebase on InputDeviceHandler focus tracking rework.

• Fix id setting and cancel touch drags
• Reapply position of first touch on drag

Do not forget id equals 0 check and add assert.

Some more explanation:

In T9467#160448, @paulb wrote:

This task is not about a general post mortem of Akademy, but more about Promo's activities at Akademy. Can we please restrict the conversation to that?

In D15502#328074, @anthonyfieroni wrote:

Yeah, i see they are in sync but if someone sends adjustment events who contain not a *real* mouse position like these https://phabricator.kde.org/source/plasma-workspace/browse/master/shell/panelview.cpp$839 Is this can be a problem>

In D15502#327512, @anthonyfieroni wrote:

I saw one potential problem, you can clarify if it's relevant. If event is someone that resend with different position that current one, as i can see input()->globalPointer() will result in current position which can be different from event position, do you think?

I wrote a blog post about stuff I liked at Akademy and what I think could be improved. Short summary of what I think could be improved:

In D15512#326091, @fvogt wrote:

I'm against this - kwin_wayland should just pick the next available socket if wayland-0 is not available. That's also what Xorg does and is IMO the expected behaviour.

Also removes an unnecessary second call to SeatInterface::setPointerPos.

In D7038#134955, @graesslin wrote:

I like that refactoring 👍 - though processAt might not be the best fitting name. Don't have a good name idea, maybe findChildSurfaceAt?

In D15135#325448, @davidedmundson wrote:

That's over complicating something that really doesn't need it.
XdgShellInterface in frameworks will raise an error if serials are super wrong.

Looking at the code this patch is based on the changes in D15135. Please add it as parent revision.

It's missing still a cleanup in case the client is broken as in not responding to any configure events or with the wrong serials and the vector would grow limitless. But we can do this in a second patch.

The decision to dismiss popups when a click is registered on a different surface of the same client is responsibility of the client. To fix Plasma in this regard one would need to do this somewhere in Plasma shell or frameworks therefore and not in KWin. But there a fix is badly needed for sure.

A surface represents the last configure that was acked.