[] Save for this setup only.

or

[X] Use for all setups with this display.

Doesn't D16703 fix it as well?

+1

Sorry, grumpy warning...

A surprisingly small amount of code for a nice feature. Code looks good to me except for one minor thing. This works great in my testing now. I say let's ship it, especially because it won't result in any UI changes at all for people who don't use tags.

@scarlettclark since I'm a passionate Pythoneer, but have no clue about Ruby (I can read most of it, but like with PHP, I try to avoid it as good as I can), I guess we could team up to port your stuff to Python?

In D16789#358969, @davidedmundson wrote:

I'm not loving the name, the goal of this patchset is to move all of the wayland logic out of the platform.

initWaylandOutput/initXdgOutput are now handled in setEnabled so can be private to AbstractOutput.
We should aim for the same with outputdevice.

I'd rather this was just "AbstractOutput::init()"

Code otherwise is fine

I'm not loving the name, the goal of this patchset is to move all of the wayland logic out of the platform.

Abandoned, already fixed by https://phabricator.kde.org/D16862

Note you have changed the indentation of the modified lines. Make sure indentation isn't changed (unless it's required specificly).

@TheAssassin yes, I was using them for non KDE applications as well.
@ everyone - I guess what I am saying here is I am more than happy to use my existing tools ( ruby ) and help with appimages. I just simply don't have the time to learn python right now. Not to say this is never going to happen, just not now.
Cheers,
Scarlett

In D15479#358797, @vonreth wrote:

thx, we where using the patch since ages on binary-factory, https://cgit.kde.org/craft-blueprints-kde.git/commit/?id=b84b9f3fd64594bb5e7959472a58309d54ee06fa

Through pushing this patch, i have discovered there is no easily discoverable documentation regarding when Frameworks are updated for unstable builds. According to https://build.kde.org/job/Plasma/job/discover/job/kf5-qt5%20SUSEQt5.11/68/console KF 5.53 is found, but the version being found does not include the patch pushed to KNewStuff yesterday (D16665). I did think there was some reasonable timing for updating Frameworks for other CI builds, and so left it overnight. However, this turns out not to be long enough. Am i simply unable to find this documentation (and wrong in thinking that https://community.kde.org/Policies would be the right place), or is such documentation simply not available? It would be terribly handy to know. I did ask on #kde-devel on freenode, but nobody there seemed to know either.

• Merge branch 'master' into arcpatch-D7700

When user changes properties in KCM, he might either decide to change data for the current configuration only or set it as new "default" for this output on every configuration, which does not overwrite with configuration-specific values. How should this be communicated to the user and how should he switch around for his current config operation?

This will have some conflict with D16463. Remember to update this if that lands first.

@scarlettclark I can provide assistance of course, just let us know what we can help you with. I'd offer to collaborate on developing the scripts for craft or whatever system you use, they might come in handy for non-KDE projects as well. Also, it's always good to see how people use our tools, as we then get an impression how we can improve them.

In D16851#358914, @laysrodrigues wrote:

I don't think that a pointer is necessary... so why?

I think your right. This was done for some reasons related to multi machine but after some more thought this change could be cause more problems. I'm going to drop this diff.

No action, so maybe I created this in the wrong way?

Sorry last year was madness for me,
With that said, I have more time now.
I failed miserably with craft even getting anything to build, much less integration with the appimage stuff. Python hates me.
I have resurrected my work from BS appimages. I am more than happy to use it on binary factory to produce appimages relatively easily , and will even help with the scripts. I am very close to ready should it be decided this is an acceptable solution.
Cheers, Scarlett

follow mart suggestion

• rename menuHidden to visible

Me neither. Can you rebase this on current master?

Maybe we should look into the non Linux backends too...

I don't think that a pointer is necessary... so why?