I tried it, and although it does solve some problems with swype input, it also introduces new problems. An example is using backspace, which doesn't work anymore with your changes.

Superseded by connection multiplexer work (see KDE Invent).

Update to require sending of protocol version message, this makes future extensions easier to handle.

In D17841#383743, @sarcot wrote:

Just so you know, I initially had the payload transfer going over the existing bluetooth connection (by sending the payload transfer info followed by the payload itself), but if the payload had newline characters, then the processing got messed up (because newlines got stripped off as part of regular message processing). Also, with payloads of unknown lengths, it wouldn't be easily possible to determine the end of the payload. Therefore, I split it out to a separate connection.

Actually, wait a bit before reviewing this. It turns out that not all (Android) devices support multiple Rfcomm servers (currently used for transmitting payloads), so we'll need something for that too.

Works for me, thanks!

Hmm, possibly. I couldn't find out how to do this from the Android side though, do you have an idea how to do that?

Qt doesn't support receiving stuff via OBEX, so that wouldn't work for us :-( Also, I'm not sure that you can initiate transfers to a specific application.

Looks sensible, but I can't test this. Consider it accepted if nobody else reviews in the coming days.

Okay, looks good!

In D12670#257588, @hkaelberer wrote:

By removing this code you change behaviour: The initial idea was to not make the TextField echo immediately what has been typed, but visualize on desktop what the remote device acked via a network package. This allows for a kind of realtime confirmation of what the remote device *really* processed. Therefore the original event was not accepted and injected artificially onAckPackageReceived. This has some shortcomings, as the echoing in the TextField is incomplete with respect to the handled special keys etc.

A more complete discussion can be found in the original RR: https://git.reviewboard.kde.org/r/129727/

If one wants to keep this behaviour, IMHO the optimal solution would be to inject a real QKeyEvent to the TextField on reception of the ack-package. I played around with a thin native wrapper around QCoreApplication::postEvent() but did not succeed.

It is a design decision whether you want to stick to this echo-behaviour or simply echo immediately what was typed (what you propose here). Personally I would not have a problem with changing it, as in my everyday usage I noted that I always look on my phone when typing remotely via remotekeyboard.

In D12559#256126, @nicolasfella wrote:

In D12559#256116, @mtijink wrote:

I tested it, and there's still an issue: updates (e.g. after next/previous) aren't displayed in KCApp. I don't know on which side the issue is.

Did you apply D12528?

Sorry, thought of a couple of new things.

In D12552#255007, @nicolasfella wrote:

Turns out there are more cases to handle:

• No title available -> show nowplaying
• Title availabe, no artist/album available -> show title
• title and either album or artist -> show title and either album or artist
• title, album and artist available -> show title and artist - album
  
  Any hints on simplifying that logic is welcome

APK:

Generally looks quite good, but didn't test it yet.

What if the remote doesn't send title, artist, etc. but only nowPlaying?

I get a delay before the UI stuff appears, probably because it's still waiting for the information to display. Would it be possible to load this in advance, like is done in the MPRIS plugin?

Ah okay, makes sense!

Looks good to me!

Shouldn't this replace the layout_marginRight? Now we get margins on both sides?

In D12294#248429, @nicolasfella wrote:

In D12294#248422, @mtijink wrote:

I think we should also send the action icon. That might be hard at the moment though, because we can only send one payload.

For what would you use it?

I think we should also send the action icon. That might be hard at the moment though, because we can only send one payload.

Looks good to me!

Didn't test, so only consider it accepted if this is an automatic refactor.

I'll do some more testing with the current changes, to make sure edge cases are handled correctly.

Make some requested changes, and better error handling

Maybe the images can be combined? Or a background color? It looks a bit empty with this change.

In D12153#247734, @nicolasfella wrote:

Did you file a Qt bug?

An empty "available devices" section does make it clear that none of the devices are available at the moment (which might be unclear with only "remembered devices"). I'd suggest only hiding it there's at least one connected device.

I don't like some of the new changes. I understand this is all opinions, so we can't have everything, but I think that the following things are especially bad changes:

• The sidebar navigation should be visually distinct from the main view. In the light view, the main view is shaded and the sidebar has a drop shadow, we could do that here too. Or, if not possible, we should change the sidebar color.
• The dark-orange toolbar doesn't match the other places where the orange color is used. I'd say they should be different hues or be exactly the same color. So either bright orange or black-ish, as @nicolasfella suggested.

Doesn't solve the issue.

It would be even better if we could prompt the user to pair from the device plugin, when the user plugs the usb in for the first time.

In D12070#243282, @nicolasfella wrote:

Thanks, sadly it's too late for 1.3 :(
IMHO this should be part of a 1.3.1 release because it breaks the feature by default

APK for testing this diff:

I think it's fine either way, so whatever @nicolasfella thinks 😃

I can't test it, but it looks good.