I used a hidden line edit, connected to KConfig parameter preferredFramebufferPlugin, and manually filled dropdown combobox (not automatically connected to KConfig) with texts that can be found in config parameter: "xcb", "qt". This allows to keep compatibility with old config format and the code that loads the preferred plugin (it expects a string). I tried to use directly connected combobox, but in that case the string that is saved into config looks like: preferredFramebufferPlugin=1, kconfig saves selected index. And we need a string (preferredFramebufferPlugin=xcb).

Icon change for settings tab is questionable, and could be done in another revision, but I couldn't resist...

What can be improved:

1. do not hardcode possible list of choices in combobox, but instead find actual available plugins as it is done in code that loads plugins: https://cgit.kde.org/krfb.git/tree/krfb/framebuffermanager.cpp#n66
2. if preferred plugin has changed, inform user that krfb needs to be restarted to apply changes
3. or, apply the change immediately: force restart of InvitationsRfbServer (will this break existing connections?..)

Not sure, what to do.

Also, code needs to be prepared to expect "x11" as preferredFramebufferPlugin and probably automatically change this setting to "xcb" early at program startup, before initialization of rfb server and loading plugins.

In D6319#118331, @alexeymin wrote:

What can be improved:

1. do not hardcode possible list of choices in combobox, but instead find actual available plugins as it is done in code that loads plugins: https://cgit.kde.org/krfb.git/tree/krfb/framebuffermanager.cpp#n66

Yes

2. if preferred plugin has changed, inform user that krfb needs to be restarted to apply changes

Yes

3. or, apply the change immediately: force restart of InvitationsRfbServer (will this break existing connections?..)

Seems too aggressive, people may lose data, not something we want to be resposinble

In D6319#118408, @aacid wrote:

Yes

Yes

ok

In D6319, @alexeymin wrote:

code needs to be prepared to expect "x11" as preferredFramebufferPlugin and probably automatically change this setting to "xcb"

I assume no answer to this as a third "yes" ;) and will continue work, thx

Does what i said make any sense?

Yes, I agree. Lambda works too, and the code looks cleaner.

Why this change?

This is not related, but I can explain: network-workgroup vs network-wired:

Looks good, i'll wait to see if you want to get an exception to commit it to Applications/17.08, otherwise i'll commit to master.

Actually you don't really need this to be static, just capture it in the lamba as a copy, i.e [this, prevFramebufferPlugin]

No, I've tested that, and it works only for the first time config dialog is shown, the first time lambda is created. If don't make prevFramebufferPlugin static, and capture it by copy, lambda remembers only the initial value of prevFramebufferPlugin, at the moment when QObject connection to lambda is done, and does not see updates to its value. So, on the second dialog show it can behave incorrectly. To make lambda see the updates, we need to capture by reference, and so prevFramebufferPlugin has to be static, to prevent it going out of scope.

In D6319#131658, @alexeymin wrote:

Actually you don't really need this to be static, just capture it in the lamba as a copy, i.e [this, prevFramebufferPlugin]

No, I've tested that, and it works only for the first time config dialog is shown, the first time lambda is created. If don't make prevFramebufferPlugin static, and capture it by copy, lambda remembers only the initial value of prevFramebufferPlugin, at the moment when QObject connection to lambda is done, and does not see updates to its value. So, on the second dialog show it can behave incorrectly. To make lambda see the updates, we need to capture by reference, and so prevFramebufferPlugin has to be static, to prevent it going out of scope.

Actually you are right that the static is needed, but you're explanation in your comment is wrong.

The real reason the static is needed is that only one KConfigDialog is created, the rest of the times the function to show the dialog is called, the

if (KConfigDialog::showDialog("settings")) {
    return;
}

returns early, so you need the static to update the value of the varaible that will be used inside the lambda of the "first/old" dialog, not because the variable goes away.