D29781: Fix importing key-direction from *.ovpn files
ouwerkerk abandoned this revision. ouwerkerk added a comment. With the move to gitlab/invent.kde.org it seems better to abandon this in favour of a straightforward MR using the new shiny :) See: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/1 REPOSITORY R116 Plasma Network Management Applet REVISION DETAIL https://phabricator.kde.org/D29781 To: ouwerkerk, jgrulich Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29781: Fix importing key-direction from *.ovpn files
ouwerkerk created this revision. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. Herald added a reviewer: jgrulich. ouwerkerk requested review of this revision. REVISION SUMMARY It is possible for key-direction to be specified *after* . Previously the code always expected it to be defined before, with this change *.ovpn files that define it after should also be imported correctly. REPOSITORY R116 Plasma Network Management Applet BRANCH fix-ovpn-import-of-key-direction REVISION DETAIL https://phabricator.kde.org/D29781 AFFECTED FILES vpn/openvpn/openvpn.cpp To: ouwerkerk, jgrulich Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote: > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> Am I the only person that just has all the repos on the same folder? I > >> thought it was the common thing to do :? > > > > I do too > > Same here. kdesrc-build's default settings do this, > No, that is not the default. By default the hierarchy is mirrored. > and download all > repos into ~/kde/src without any of the levels of hierarchy. > But it is sufficiently common that there is a dedicated setting for it: `ignore-kde-structure`. Kinda does what it says on the tin ;) > This would > seem to require unique repo names, no? > Yes, it does. Also whether the hierarchy is preserved locally or not, kdesrc-build currently requires that the leaf names ($repo.git) be unique. It cannot fully and consistently distinguish between a maui/dialer and a plasma-mobile/dialer because at certain points in Perl we map to/from module names which are mapped onto those leaf names (i.e. both would be considered "dialer" and it would be anybody's guess at this point what you'd get if you did a `kdesrc-build dialer`). Might be fixable, but is definitely not trivial and would require people to help review and test. Also would require some "cleverness" to preserve the ability to refer to modules by their leaf names when possible (i.e. continuing to be able to do `kdesrc-build kate`), otherwise kdesrc-build becomes a *lot* less user friendly all of a sudden. Regards, - Johan
D28730: Couple of 'trivial' fixes for broken code
This revision was automatically updated to reflect the committed changes. Closed by commit R169:57c63e7ceeb9: Couple of 'trivial' fixes for broken code (authored by ouwerkerk). REPOSITORY R169 Kirigami CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28730?vs=79789&id=80413 REVISION DETAIL https://phabricator.kde.org/D28730 AFFECTED FILES src/controls/private/ActionButton.qml src/controls/templates/SwipeListItem.qml To: ouwerkerk, #kirigami, cblack Cc: cblack, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, ahiemstra, davidedmundson, mart
Re: Update on Status of Gitlab Migration
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > > > > We may need to do on-the-fly conversion of the kde: repo paths if they > > won't be expressible as 'kde:foo' in the future, but we should have the > > information needed to do this in kdesrc-build to make this happen > > on-the-fly. > > > > Yes, this should be fairly straight forward: we could do a `git remote > set-url` based on what the repo metadata tells us before updating a > local clone. In fact: we could build this right now and sell it as > "automagically recover your upstream". :) > > I might try to hack something up tomorrow or monday for that. > A basic version of this is now available via: https://invent.kde.org/kde/kdesrc-build/-/merge_requests/27 With this feature sysadmin should now be free to change the repopath value in the metadata YAML and kdesrc-build will reconfigure the remote URL appropriately automatically. This works as long as the same `kde:$path` expression works for both fetch and push, i.e. the layout on the anongit.kde.org network must match with the layout of git.kde.org/invent.kde.org. If necessary a simple path prefix change could still work with a minor update to the pushInsteadOf mapping, e.g. when repos on invent are mapped to kde/ instead of /. You can also experiment with setting invent.kde.org as the push URL by setting x-invent-kde-push-urls to true in your rc file. The effect should be visible through git remote -vv afterwards. (Disable the setting and re-run again afterwards because this will obviously break your push URLs as long as the Gitlab migration hasn't completed yet). Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote: > > On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk > wrote: > > > > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk > > wrote: > > > > > > Yes the only reason why a cleanup script might be needed is if the > > > logical path used to express the repo in dependency information > > > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets > > > remapped to `frameworks/kf5/foo` or something like that. In that case > > > unless you use the flat repository layout, kdesrc-build would try to > > > clone a new `frameworks/kf5/foo` repo, leaving your old > > > `frameworks/kf5foo` to consume some wasted disk space. > > > > > > > This is obviously a poor example, but the same problem occurs if > > something moves from playground to extragear. Basically if the > > `projectpath` YAML key changes. > > I had been considering adding the Gitlab Project ID number to the YAML > metadata files as a way of allowing us to track projects through their > whole lifetime. > That would be very nice, because then `kdesrc-build` could implement an `arc patch` type feature in a more straightforward fashion. So people could type things like `kdesrc-build juk!55` as a shorthand for checkout remote HEAD of whatever branch MR 55 is for `juk`. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > Yes the only reason why a cleanup script might be needed is if the > logical path used to express the repo in dependency information > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets > remapped to `frameworks/kf5/foo` or something like that. In that case > unless you use the flat repository layout, kdesrc-build would try to > clone a new `frameworks/kf5/foo` repo, leaving your old > `frameworks/kf5foo` to consume some wasted disk space. > This is obviously a poor example, but the same problem occurs if something moves from playground to extragear. Basically if the `projectpath` YAML key changes. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote: > > On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > > > > > A cleanup script could be handy. I think kdesrc-build will > > automatically pick up new repo paths from metadata and that should > > work transparently, but the old clones may get left behind as well. > > People who use the kdesrc-build option to ignore KDE repo structure > > shouldn't be affected at all. > > (...) > > All of the kde: repositories use the kde:foo syntax, where the 'foo' > comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML > files. > Yes the only reason why a cleanup script might be needed is if the logical path used to express the repo in dependency information changes at the same time. E.g. suppose a `frameworks/kf5foo` gets remapped to `frameworks/kf5/foo` or something like that. In that case unless you use the flat repository layout, kdesrc-build would try to clone a new `frameworks/kf5/foo` repo, leaving your old `frameworks/kf5foo` to consume some wasted disk space. > > We may need to do on-the-fly conversion of the kde: repo paths if they > won't be expressible as 'kde:foo' in the future, but we should have the > information needed to do this in kdesrc-build to make this happen > on-the-fly. > Yes, this should be fairly straight forward: we could do a `git remote set-url` based on what the repo metadata tells us before updating a local clone. In fact: we could build this right now and sell it as "automagically recover your upstream". :) I might try to hack something up tomorrow or monday for that. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez wrote: > > How would it work during the "grace period"? Keeping an outdated read-only > mirror on the old URL? I have done some research into redirecting or > remapping from the old URL to the new one so we can keep it working for a > longer period of time, and it's harder than it seems... It can be done but I > need to be convinced that it's actually necessary / worth the effort. > My idea was that when the button is pushed people could update their kdesrc-build once, run it once and continue to work as if nothing happened. If a grace period is not feasible from a sysadmin perspective, then things could still work if at the same time that git.kde.org is decommissioned a pre-prepared MR/commit is merged into kdesrc-build that fixes it. At the very least the code that sets the pushInsteadOf mapping in the user's ~/.gitconfig would become outdated and needs to be fixed at that point. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote: > > Yes, the hostname git.kde.org will be fully retired as part of this > transition. > > From my understanding kdesrc-build will automatically pick this up > once we update sysadmin/repo-metadata to show the new repository > paths. > This is something we'll confirm with mpyne though to ensure we can > make the cutover as smooth as possible. > Just to be clear, my understanding based on reading the `Updated/Git.pm` module is that KDE repo paths are abstracted via ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`. Currently the code manipulates the user's ~/.gitconfig to bind the correct mappings to the `kde:` prefix (this happens even before cloning sysadmin repos for metadata). So if my understanding of the code is correct, the entire switch over is transparent provided that kdesrc-build is updated beforehand to set the updated value for `pushInsteadOf`. We already have the same mechanism in place in kdesrc-build for ensuring that people use https://anongit.kde.org instead of git://anongit.kde.org when cloning/fetching. > > Depending on how things look we may also make available a script that > will update the configuration of a repository to reflect both the > change in hostname as well as the change in path. > A cleanup script could be handy. I think kdesrc-build will automatically pick up new repo paths from metadata and that should work transparently, but the old clones may get left behind as well. People who use the kdesrc-build option to ignore KDE repo structure shouldn't be affected at all. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > Should anyone have any questions on the above, please let us know. > Does the migration also mean that `git.kde.org` push URL will be retired and would need to be remapped to `invent.kde.org`? In that case, it would be good to have a grace period after the initial migration to Gitlab so kdesrc-build (etc.) could be updated before the cut off date to perform this migration automatically for the user. I expect such a grace period would not need to last very long because the feature would be trivial to implement. Regards, - Johan
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > To help assist with this, it would be appreciated if all holders of a > KDE Developer account could please login on our Gitlab instance (at > https://invent.kde.org/) and ensure they are listed as a 'Developer' > of the KDE group. You can do this by checking the 'Groups' tab of your > Profile on Gitlab. > This is a more direct URL that goes straight to the members page of the KDE group: https://invent.kde.org/groups/kde/-/group_members If you are logged in on invent.kde.org you should be able to use the search box to find yourself (by identity.kde.org name, in my case). Regards, - Johan
D28730: Couple of 'trivial' fixes for broken code
ouwerkerk created this revision. Herald added a project: Kirigami. Herald added a subscriber: plasma-devel. ouwerkerk requested review of this revision. REVISION SUMMARY Issues were found by running code with QT_QUICK_CONTROLS_MOBILE=1 - `Units` does not exist in SwipeListItem due to how Kirigami is imported - ActionButton (private) is trying to call `hasOwnProperty()` on `null` REPOSITORY R169 Kirigami BRANCH fixes-for-qt_quick_controls_mobile REVISION DETAIL https://phabricator.kde.org/D28730 AFFECTED FILES src/controls/private/ActionButton.qml src/controls/templates/SwipeListItem.qml To: ouwerkerk Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, ahiemstra, davidedmundson, mart
D28316: Add useful input method hints to password field by default
This revision was automatically updated to reflect the committed changes. Closed by commit R169:c9bbe6dea5a1: Add useful input method hints to password field by default (authored by ouwerkerk). REPOSITORY R169 Kirigami CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28316?vs=78579&id=78582 REVISION DETAIL https://phabricator.kde.org/D28316 AFFECTED FILES src/controls/PasswordField.qml To: ouwerkerk, #kirigami, ngraham Cc: ngraham, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson, mart
D28316: Add useful input method hints to password field by default
ouwerkerk created this revision. Herald added a project: Kirigami. Herald added a subscriber: plasma-devel. ouwerkerk requested review of this revision. REVISION SUMMARY Hint that input methods should treat the password as sensitive and avoid applying "auto-correct" features as well. REPOSITORY R169 Kirigami BRANCH fix-password-field-input-hints REVISION DETAIL https://phabricator.kde.org/D28316 AFFECTED FILES src/controls/PasswordField.qml To: ouwerkerk Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, ahiemstra, davidedmundson, mart
Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)
On Sun, Mar 22, 2020 at 3:20 AM Ben Cooksley wrote: > > We already do have a repository of artifacts :) > You can find the public view of this at > https://build-artifacts.kde.org/production/ > > > We already use Virtual Machines for both FreeBSD and Windows. > > The main problem here is that there is no way of dynamically > provisioning full VMs without building an entire Openstack type > system, which is just too much overhead for the number of builders we > have. > First of all, thanks for your patience in explaining to me what must be obvious to you. I really appreciate it. > > Shouldn't this kind of experimentation be done on developers systems > rather than the CI system? > Please do remember that CI resources are not infinite and at times can > be quite constrained. > > My main query here though is what would be achieved by allowing this > sort of thing that the existing system does not allow for? > (Ignoring the fact we don't cover feature branches - something which > is in the long term pipeline) > Pure experimentation should definitely be done on developers' systems. But changes to your CI cannot be fully validated on your own machine beforehand: you need to verify that it works on the actual CI builders. Ideally without breaking the CI for anyone else. So the main gain here is that projects can improve, evaluate and mature their CI efforts independently. Examples of things we currently don't have but some projects might benefit from are: licensing compliance checking (reuse), dependency scanning (e.g.: snyk) and mutation testing (e.g.: stryker). I'm not saying that this couldn't be achieved today with a lot of help and guidance from the sysadmins. But I think this does impose a lot of overhead, especially while such changes are still experimental and do not fully work yet in CI or need tweaking for prettier output or whatever. In fact, your reply to my other question kind of indicates as much: > > > > Possibly projects would also submit custom images for consideration to > > that registry. > > This isn't something that is terribly easy to do within our existing > Jenkins setup - but is theoretically possible. It requires quite a bit > of provisioning work on the Jenkins side. > > The CI scripts would also need some adapting to make this sort of > setup efficient to operate with them if you were to use them (and you > probably do want to use them for running tests). > A good portion of this adapting will done as part of moving the CI > system to Gitlab. Does this mean that we will be encouraged to configure `image` settings in .gitlab-ci.yml? If so, that basically gives me what I really wanted here. All the actual images I might ever need could be submitted for review via MR to a repository on invent as and when I would need them. > > Note however that images based upon Fedora or anything that shares > it's lineage (including CentOS and it's derivates) is strictly > prohibited and won't be accepted for inclusion. > Personally I'm more inclined towards using Debian myself, but out of interest what is the reason for banning Fedora and CentOS images? Does this still apply when the move to Gitlab CI is completed? Regards, - Johan
CI talk (Was: re: Manner in which kde-gtk-config development is conducted)
On Sat, Mar 21, 2020 at 10:27 PM Ben Cooksley wrote: > > On Sun, Mar 22, 2020 at 3:27 AM Johan Ouwerkerk > wrote: > > > > On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley wrote: > > > > > > Comments welcome. Please note that simply fixing the dependency > > > breakage in this case is not enough to resolve this - there are > > > underlying issues which need to be addressed here. > > > > > > Regards, > > > Ben Cooksley > > > KDE Sysadmin > > > > I cannot comment as to whether or not this is a pattern of behaviour > > or just a few isolated instances. From a technical perspective I feel > > there are two (additional) underlying issues worth addressing here: > > > > 1. This could be prevented for the most part by having CI run before, > > and not after the fact. I.e. prior to merging code. > > This will happen once we are on Gitlab. > > > 2. Different projects have different CI needs, and it would help if a > > project could safely manage their CI environment "on their own" as > > much as possible. The current system requires a lot of daunting > > (possibly otherwise unnecessary) complexity purely to manage the fact > > that a builder image will be used not just for one project but for > > perhaps the whole of KDE. > > The global builder image doesn't cause too many issues fortunately and > isn't the problem here. Our current setup actually has the flexibility > to use different images - we're just constrained in terms of setting > this up by Jenkins as there is a bunch of tooling needed to provision > jobs. > > A good proportion of the current "complexity" is due to our use of > Jenkins. The remainder is due to needing to provide the most recent > version of a given KDE project as a dependency, along with the > infrastructure for tests to execute successfully (which is quite a bit > more than just 'make test') > > The need to use the most recent version of a KDE project means either: > a) You have to have all of those projects use the same image as well; or > b) You have a special job to build all of those projects that don't > use the same image (which is what the 'Dependency Build' jobs do); or > c) You incorporate the project within the base system itself > > Option (c) is not possible on Windows or FreeBSD as those platforms do > not support dynamic provisioning of images - meaning that all KDE > projects have to share the same machines and therefore must be > provided via our mechanisms (options a and b above). > > In the case of Plasma, baking in say Frameworks to the image would > mean a full image rebuild everytime you needed something new in a > Framework. Please note that kwindowsystem and plasma-framework are > both Frameworks. Suffice to say, that won't work - you would be > rebuilding that image multiple times a week at a minimum. > > The only way to manage the build environment for something like Plasma > is to do it on a Product level, taking all of it's member projects > into account. This is what we do currently - while the actual Docker > image may happen to be shared with Frameworks and Applications, that > isn't required and could be seperated within our existing > architecture. > Or use option (d): a repository of artifacts which you push to/pull from. The problem I see with that right now is: we would need "package management" and our projects use mostly plain CMake which by itself doesn't understand this concept. So the standard tooling for our projects can only check for declared dependencies, but cannot try to install them locally. As I understand it, that is effectively what a good chunk of the CI tooling sort of replicates anyway: a custom built package management solution for KDE CI. Out of interest, apart from the amount of work it might take what would be the main blocker for using VMs and things like Vagrant boxes for FreeBSD as the next best thing to containers? I'd ask the same for Windows, but I imagine the answer is licensing costs. > > That isn't CI. That is CD - as it results in an artifact for use on > developers/testers/end user systems. > In the sense that if you were to push to a package repository it entails a deployment. But building binaries by itself obviously isn't, even if you expose these as downloadable artifacts. > > The infrastructure for Android builds has grown organically, and I > suspect we are at a point where we do need to take a step back and ask > ourselves if there is a better way of doing this that is more > maintainable. The dependencies bit in particular definitely needs > work. > Agreed. And I understand that there
Re: Manner in which kde-gtk-config development is conducted
On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley wrote: > > Comments welcome. Please note that simply fixing the dependency > breakage in this case is not enough to resolve this - there are > underlying issues which need to be addressed here. > > Regards, > Ben Cooksley > KDE Sysadmin I cannot comment as to whether or not this is a pattern of behaviour or just a few isolated instances. From a technical perspective I feel there are two (additional) underlying issues worth addressing here: 1. This could be prevented for the most part by having CI run before, and not after the fact. I.e. prior to merging code. 2. Different projects have different CI needs, and it would help if a project could safely manage their CI environment "on their own" as much as possible. The current system requires a lot of daunting (possibly otherwise unnecessary) complexity purely to manage the fact that a builder image will be used not just for one project but for perhaps the whole of KDE. As for running the CI beforehand: by this I mean that it is relatively easy to 'break the build' one way or another and for this not to be caught during review, especially if a change is complex and has been in development for a while with many revisions. Certainly this is a particularly severe case of breaking the build, but the same should also apply to e.g. tests that start to fail. On the day job I find that it is absolutely routine for commits to be pushed to feature branches for review which don't even pass the CI sanity check. This is not because people are lazy, but because of the perennial pitfall of "works on my machine" (local config vs. remote), and sometimes because people want to get early review on code structure for example. I think it would help massively for CI to be run on feature branches prior to merging as a pre-requirement for merging. This should be automatic and not require any special care on the part of reviewers, and the result of the CI should be immediately visible as part of the review tooling (workflow UI/UX). After that it is mostly a process of unlearning to commit to master directly. This should be fairly easy to implement for invent.kde.org, in the sense that Gitlab offers such CI as a feature out of the box and it is fully integrated with the MR workflow. Regarding your point about changing dependencies and the need for communication to manage the CI environment, to the extent that this breaks the build this could be simplified if it were easier to manage the build environment yourself (from a project perspective). This brings to my second point: I think it would be desirable for projects to be able to cater for their CI needs on their own as much as (safely) possible. I understand why you would want to avoid proliferation of too many CI setups but as the same time having a single image that contains everything + kitchen sink also leads to problems. In particular it becomes hard to ensure the image and versions of tooling or pre-installed libraries are compatible with every project, to keep this up to date and to ensure that this all remains consistent with the CI aims of a particular project. For instance a KF5 framework might want to validate that they can build and pass tests against *both* an ancient version of Qt (for stability promises) and the most recent Qt release as well (and possibly even Qt from master to get a heads up of forwards compatibility issues). A Plasma Mobile app might have rather different CI needs: it matters that both 64 and 32 bit builds are produced, both as Android apps and flatpaks. A project might want to validate that it builds against both master versions of KF5 frameworks and those more typically found on a typical distro. This sort of per-project complexity is hard to deal with in one big builder image, but something we ideally would be able to pull off for all our projects as a matter of routine. I think we already run into the complexity problems pretty hard with the current CI setup in that sense: taking binary factory as an example, it is quite obvious that the JSON blob encoding dependency information for Android apps is something that came out of a need for "yet another" layer of abstraction to manage CI needs of many different projects, and that this is hard to grasp, comprehend fully let alone maintain: there is an ever-growing list of ad-hoc helper scripts needed to keep the JSON blob manageable, and even so it is not very easy to follow if a project has to pull in multiple dependencies. For comparison I would ask: how many people understand how all of the following actually work: - The various instructions in Docker files - The related resources copied into the images, in particular the shell scripts - The Python scripts that do much of the heavy lifting - The Jenkins groovy DSL scripts that actually make this work on Jenkins - The repository metadata, and dependency information files - The various data files that encode crucial config data/build step
D24193: Bump QtQuick.Controls dependency to 2.12 (from Qt 5.12).
ouwerkerk abandoned this revision. ouwerkerk added a comment. Cleanup. REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D24193 To: ouwerkerk, mart, #plasma, ngraham Cc: ngraham, anthonyfieroni, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson, mart, hein
D26344: Fix building plasma-desktop without X11 cursor development headers
ouwerkerk abandoned this revision. ouwerkerk added a comment. Superseded by: https://phabricator.kde.org/D26367 REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D26344 To: ouwerkerk, #plasma, davidedmundson Cc: davidedmundson, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26367: Make the lookandfeel KCM build without XCursor support
This revision was automatically updated to reflect the committed changes. Closed by commit R119:1c43e1b4f7b1: Make the lookandfeel KCM build without XCursor support (authored by ouwerkerk). REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D26367?vs=72617&id=72619 REVISION DETAIL https://phabricator.kde.org/D26367 AFFECTED FILES kcms/lookandfeel/CMakeLists.txt kcms/lookandfeel/autotests/CMakeLists.txt kcms/lookandfeel/config-kcm.h.cmake kcms/lookandfeel/kcm.cpp To: ouwerkerk, davidedmundson, #plasma Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26367: Make the lookandfeel KCM build without XCursor support
ouwerkerk created this revision. ouwerkerk added a reviewer: davidedmundson. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. ouwerkerk requested review of this revision. REVISION SUMMARY With this change the lookandfeel KCM can be built without X11 cursor development headers. In the case the KCM is built without XCursor support, it will not be able to reload the cursor dynamically at runtime but it will still be able to configure cursor themes. TEST PLAN plasma-desktop builds using kdesrc-build with and without X11 cursor development headers present. REPOSITORY R119 Plasma Desktop BRANCH lookandfeel-without-cursors REVISION DETAIL https://phabricator.kde.org/D26367 AFFECTED FILES kcms/lookandfeel/CMakeLists.txt kcms/lookandfeel/autotests/CMakeLists.txt kcms/lookandfeel/config-kcm.h.cmake kcms/lookandfeel/kcm.cpp To: ouwerkerk, davidedmundson Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26354: Introduce ActionRow widget
ouwerkerk added a comment. Are we certain about naming here: `SwipeAction.isDelete`? Maybe `SwipeAction.remove` or `SwipeAction.removeFromList` ? It doesn't necessarily have to be a real "delete" action that is backing this, maybe all you want to convey with the name of this setting is that the list entry will be removed from the UI if enabled? REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D26354 To: cblack, #vdg, #kirigami Cc: ouwerkerk, ngraham, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, ahiemstra, davidedmundson, mart, hein
D26344: Fix building plasma-desktop without X11 cursor development headers
ouwerkerk added a comment. Right now the KCM CmakeListst does stuff like: set(kcm_lookandfeel_SRCS kcmmain.cpp kcm.cpp ../krdb/krdb.cpp ../cursortheme/xcursor/cursortheme.cpp ../cursortheme/xcursor/xcursortheme.cpp ) And the main `kcm.cpp` simply includes cursor deps without `#ifdef`. It's not impossible to rework that so all the cursor related setters/getters are effectively hidden behind `#ifdef` however, so the question becomes: do we want that? I.e. do we genuinely want to use the lookandfeel KCM on platforms without mouse cursors? Otherwise it is a lot less work to go for the easy solution of making X11 cursor dependencies mandatory if we want to ensure the lookandfeel KCM is always built. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D26344 To: ouwerkerk, #plasma, davidedmundson Cc: davidedmundson, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26344: Fix building plasma-desktop without X11 cursor development headers
ouwerkerk updated this revision to Diff 72544. ouwerkerk added a comment. Fixed commit message typo REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D26344?vs=72542&id=72544 BRANCH fix-build-without-cursors REVISION DETAIL https://phabricator.kde.org/D26344 AFFECTED FILES kcms/CMakeLists.txt To: ouwerkerk, #plasma Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26344: Fix building plasma-desktop without X11 cursor development headers
ouwerkerk created this revision. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. ouwerkerk requested review of this revision. REVISION SUMMARY The lookandfeel KCM has a hard dependency on xcursor code of the cursor KCM. This change updates the CMake code to reflect this hard dependency and avoid build failures when the X11 cursor headers are unavailable. TEST PLAN Compiling plasma-desktop with kdesrc-build works again without XCB cursor headers REPOSITORY R119 Plasma Desktop BRANCH fix-build-without-cursors REVISION DETAIL https://phabricator.kde.org/D26344 AFFECTED FILES kcms/CMakeLists.txt To: ouwerkerk Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D26304: [PageRow] Disable swipe forwards/backwards gesture by default
ouwerkerk added a comment. This completely alters one of the core propositions of how a Kirigami UX works. I may be mistaken, but if I understand it correctly drawers are supposed to be accessible via buttons. If gestures conflict, why remove page row navigation by gesture rather than drawer gestures? REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D26304 To: cblack, #vdg, #kirigami Cc: ouwerkerk, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, ahiemstra, davidedmundson, mart, hein
D24321: [KCM] Scale more grossly with the slider, but more finely with a semi-hidden spinbox
ouwerkerk added a comment. Also side note, as a non-native English speaker I find "grossly" to be a bit of an odd adjective to use here -- "coarsely" would be more familiar: as in fine/coarse grained. Perhaps something to keep in mind when this lands and you start blogging about it :) REPOSITORY R104 KScreen REVISION DETAIL https://phabricator.kde.org/D24321 To: ngraham, #vdg, #plasma, romangg Cc: ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D24321: [KCM] Scale more grossly with the slider, but more finely with a semi-hidden spinbox
ouwerkerk added a comment. Ideally you would also warn if the reciprocal times the horizontal, vertical resolution yields a non-integer output, not just if some value is chosen which cannot be represented in floating point exactly. E.g. on a 4K (3840 × 2160) a scaling factor of 1.5 is fine because the horizontal resolution scales down to effectively 3840 × 2 ÷ 3 = 2160 and the vertical resolution scales down to 2160 × 2 ÷ 3 = 1440. This means that the scaled renders will fit the physical display exactly. REPOSITORY R104 KScreen REVISION DETAIL https://phabricator.kde.org/D24321 To: ngraham, #vdg, #plasma, romangg Cc: ouwerkerk, GB_2, ndavis, cullmann, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D24193: Bump QtQuick.Controls dependency to 2.12 (from Qt 5.12).
ouwerkerk added a comment. And if so, sure I can 'fix' this by downgrading to QQC 2.4 instead but in that case: is this 'safe'? I.e. does this introduce bugs/regressions? REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D24193 To: ouwerkerk, mart, #plasma Cc: anthonyfieroni, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, davidedmundson, mart, hein
D24193: Bump QtQuick.Controls dependency to 2.12 (from Qt 5.12).
ouwerkerk added a comment. If Kirigami is supposed to depend on Qt 5.11, then *why* were these old imports there in the first place? They cannot work with Qt 5.11, because then the max QQC version is 2.4 Maybe I am misunderstanding something here? Are you saying the old Kirigami code effectively broke its own policy on depending on (newer) Qt versions? REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D24193 To: ouwerkerk, mart, #plasma Cc: anthonyfieroni, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, davidedmundson, mart, hein
D24193: Bump QtQuick.Controls dependency to 2.12 (from Qt 5.12).
ouwerkerk created this revision. Herald added a project: Kirigami. Herald added a subscriber: plasma-devel. ouwerkerk requested review of this revision. REVISION SUMMARY It is a bad idea to depend on non-existent versions: we should more clearly mark our intended QQC dependency version (ie. Qt 5.12 at a minimum) by refering to an actual release. While technically correct, non-existent dependency versions such as 2.5 and 2.7 are confusing and causing people to mistakenly propose downstream patches to fix imagined 'typos', cf.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940966 REPOSITORY R169 Kirigami BRANCH bump-qcc2-to-qt-5.12 REVISION DETAIL https://phabricator.kde.org/D24193 AFFECTED FILES src/controls/AbstractApplicationHeader.qml src/controls/Action.qml src/controls/ActionToolBar.qml src/controls/ListSectionHeader.qml src/controls/templates/SwipeListItem.qml To: ouwerkerk Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, davidedmundson, mart, hein
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/ --- (Updated Feb. 8, 2017, 4:02 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: plasma-workspace Description --- Previously the taskmanager library contained a special case logic for windows of KDE-4 KCM modules (only). These modules were recognised by finding wmClass=Kcmshell4. This logic is extended to cover kcmshell5 windows as well, meaning that KCMs written for Plasma 5 are properly recognised now. The net benefit is that these KCMs are displayed in the task manager with their proper KCM program icons. This patch can be pulled from the kcmshell5-task-url-fixes branch at: g...@github.com:cmacq2/plasma-workspace.git Diffs - libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e Diff: https://git.reviewboard.kde.org/r/126016/diff/ Testing --- Built with kdesrc-build, and tested using: `plasmawindowed org.kde.plasma.icontasks`. I checked the change works as expected by running `which kcmshell5` style as well as `kcmshell5 style`: the icon of the window matches that in system settings (as expected). Thanks, Johan Ouwerkerk
Re: Noto fonts screw my system, please stop forcing fonts upon me!
> > So the noto fonts are not to blame, just the noto package is. > That does match with what i said and a couple of people said in here, i just > didn't expect it to end up this way. > - I've said: "just having the fonts installed cripples chrome" > - Some in here: "The fonts are fine and the best choice there is" > > I'm quite happy i know that now. This means that i can fiddle with > fontconfig settings and just blacklist those that are installed by the noto > package, but are not the noto fonts. > And that means i can drop my fork! > > KDE - plasma - should most certainly clarify what it means by noto and > inform distribution packagers of that. You seemingly expect that noto is > just the noto fonts, that is apparently not the case As it currently > stands, installing the font package breaks (read cripples it, it's still > readable) chrome rendering on archlinux. Archlinux itself is not at fault > here, they do exactly what one expects, the noto package from the official > site gets installed as is. Period. The package just installs fonts that mess > things up (Arimo, Cousine, and Timos) that need to be blacklisted and aren't > by default. > From the perspective of the upstream: KDE doesn't really care what fonts you have installed. KDE just needs something sane to integrate visually with their design, hence choice for Noto as default. At that point it becomes the case that as far as KDE is concerned there's (by default) a dependency on "something which will provide you the Noto fonts". How exactly those are packaged up is really the distribution's problem/business to sort out. For example on Debian the KDE packages pull in fonts-noto-hinted by default which contains just Noto files. Moreover it is not KDE's responsiblity to set a packaging policy for these fonts as they are an upstream. It would be rather like KDE deciding how X libs ought to be packaged up. (Where in the case of Debian there's about 3 'X' packages in total and a minimal X server can be installed without /usr/bin/X being provided by default). So it's really down to "how much work/effort is the distro willing to invest towards proper packaging and integration". In the case of Arch it's not as much as Debian because the user is expected to sort things out/configure the system themselves, and a correspondingly greater effort is spent in maintaining their excellent wiki instead. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126373: change the taskbar color from blue to gray
> On Dec. 20, 2015, 8:45 p.m., Eike Hein wrote: > > General PSA: I will soon push a fixed-up version of tasks.svgz to the repo > > that cleans up all the random margins and inconsistent corner styles in it > > that currently mess up alignments inside and outside of task buttons as > > well as corner appearance. Whatever the outcome of this, it needs to be > > rebased against those fixes first. > > Uri Herrera wrote: > The margins are not random. I literally had to use kruler and kmag to > properly align that. I even used a layered file with a red rectangle in it > because that area consists of a deadzone. I pointed that out when I made the > reveiw request originally. > > Eike Hein wrote: > The inside margins are currently inconsistent at the top and bottom > causing the icon to be vertically misaligned. The outside margins are > inconsistent as well - I think it's trying to position the button well inside > the panel, but this is an incorrect approach to the problem (the optical > imbalance with consistent margins is caused by how the panel inside margins > function, which is something we need to address in the theming system - my > approach to fix it was rejected, I'll be trying again though). The outside > margins and the corners (top ones rounded, bottom ones not) subtly break > things when the panel is anywhere but the bottom. > > I'm working on a series of changes to make the panel and Task Manager > finally pixel-perfect - fix the theme, fix the panel controller when > resizing, fix the panel default size, and fix something in FrameSVG/the panel > containment. > > Johan Ouwerkerk wrote: > In any case, the top version (new draft?) has markedly better alignment > of the text with icons... The other two versions seem vertically imbalanced > (more margin on the bottom than at the top). > Ideally, the icon is vertically aligned with the baseline of the text > such that ascenders and descenders extend equally far beyond the > corresponding border of the icon, hough this may be rather tricky when > considering languages with different baseline conventions (hanging or > variable or none). > > Eike Hein wrote: > The top version on the screenshot still shows all of the problems I'm > currently fixing FWIW. > > Eike Hein wrote: > I've now pushed the cleaned up tasks.svgz to git master. This fixes: > > * Fix inconsistent inside margins causing vertical misalignment inside > Task Buttons. > * Fix inconsistent outside margins causing incorrect alignment inside > panel. > * Fix outside margins and button corner appearance in locations other > than South. > * Align button frames with things like the pager edges. > * Fix a few instances of incorrect color scheme application. > * Remove many unused elements. > > This is what this gets us: http://i.imgur.com/7KaeJH5.png > > This took *hours* to fix. If anyone breaks these margins I will *eat* > them. Please base future changes on this version of the file! Much better! Appreciated. Perhaps a test application that sets window name in a variety of scripts might be useful to check how it performs on various scripts...? - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126373/#review89779 --- On Dec. 16, 2015, 7:23 p.m., andreas kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126373/ > --- > > (Updated Dec. 16, 2015, 7:23 p.m.) > > > Review request for Plasma, Marco Martin and Uri Herrera. > > > Repository: plasma-framework > > > Description > --- > > Problem > === > with the new taskbar we look that the look and feel is consistent between > plasma and the applications therefore Uri change the selected application > taskbar button to a blue background. The problem is that the blue background > couldn't be the same blue than e.g. in the dolphin sidebar cause when you > select an element in the sidebar the text color change from "black" to white > which isn't possible in the system tray and than the contrast isn't that good > in the panel for selected application (gray text on blue background). In > addition the blue is very visible. see screenshot before. > > Solution > > I like that we use the same color language
Re: Plasma Mobile package deb source repository
Thanks! I was starting to worry I'd be using a gross hack involving kdesrc-build to compile everything, fix up the installed paths and call it packaging. Being able to 'borrow' actual packaging code is much more appealing. :) On Mon, Dec 21, 2015 at 11:53 AM, Harald Sitter wrote: > On Fri, Dec 18, 2015 at 7:12 PM, Johan Ouwerkerk > wrote: >> Does anybody know where I can find the sources (Debian control files >> etc.) for the packaging of the reference image for Plasma Mobile? > > http://anonscm.debian.org/cgit/?q=pkg-kde > > partially overridden by > https://github.com/plasma-phone-packaging/ > > (kubuntu_unstable branches respectively) > > HS > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126373: change the taskbar color from blue to gray
> On Dec. 20, 2015, 8:45 p.m., Eike Hein wrote: > > General PSA: I will soon push a fixed-up version of tasks.svgz to the repo > > that cleans up all the random margins and inconsistent corner styles in it > > that currently mess up alignments inside and outside of task buttons as > > well as corner appearance. Whatever the outcome of this, it needs to be > > rebased against those fixes first. > > Uri Herrera wrote: > The margins are not random. I literally had to use kruler and kmag to > properly align that. I even used a layered file with a red rectangle in it > because that area consists of a deadzone. I pointed that out when I made the > reveiw request originally. > > Eike Hein wrote: > The inside margins are currently inconsistent at the top and bottom > causing the icon to be vertically misaligned. The outside margins are > inconsistent as well - I think it's trying to position the button well inside > the panel, but this is an incorrect approach to the problem (the optical > imbalance with consistent margins is caused by how the panel inside margins > function, which is something we need to address in the theming system - my > approach to fix it was rejected, I'll be trying again though). The outside > margins and the corners (top ones rounded, bottom ones not) subtly break > things when the panel is anywhere but the bottom. > > I'm working on a series of changes to make the panel and Task Manager > finally pixel-perfect - fix the theme, fix the panel controller when > resizing, fix the panel default size, and fix something in FrameSVG/the panel > containment. In any case, the top version (new draft?) has markedly better alignment of the text with icons... The other two versions seem vertically imbalanced (more margin on the bottom than at the top). Ideally, the icon is vertically aligned with the baseline of the text such that ascenders and descenders extend equally far beyond the corresponding border of the icon, hough this may be rather tricky when considering languages with different baseline conventions (hanging or variable or none). - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126373/#review89779 --- On Dec. 16, 2015, 7:23 p.m., andreas kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126373/ > --- > > (Updated Dec. 16, 2015, 7:23 p.m.) > > > Review request for Plasma, Marco Martin and Uri Herrera. > > > Repository: plasma-framework > > > Description > --- > > Problem > === > with the new taskbar we look that the look and feel is consistent between > plasma and the applications therefore Uri change the selected application > taskbar button to a blue background. The problem is that the blue background > couldn't be the same blue than e.g. in the dolphin sidebar cause when you > select an element in the sidebar the text color change from "black" to white > which isn't possible in the system tray and than the contrast isn't that good > in the panel for selected application (gray text on blue background). In > addition the blue is very visible. see screenshot before. > > Solution > > I like that we use the same color language but when you look at the dolphin > toolbar on top selected elements (e.g. preview in the screenshot) are gray so > I change the blue color for the selected application to gray and change > minimized app to no border. > > what do you think? > > > Diffs > - > > src/desktoptheme/breeze/widgets/tasks.svgz 086558b > > Diff: https://git.reviewboard.kde.org/r/126373/diff/ > > > Testing > --- > > I will test the new taskbar and hope someone else can test it too before we > may ship it. > > > File Attachments > > > taskbar style old > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png > taskbar style new > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png > new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/ > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz > taskbar old and new > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fafdc5e8-bd92-43bd-8006-71088af6fdf4__taskbar.png > tasks new blue boarder in difference to the original one > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/46755f5c-9c95-4e13-b5c6-4966496a5056__tasks.svgz > new draft, origin, old draft > > https://git.reviewboard.kde.org/media/uploa
Plasma Mobile package deb source repository
Does anybody know where I can find the sources (Debian control files etc.) for the packaging of the reference image for Plasma Mobile? My goal is to put together a bootable image of Plasma Mobile for aarch64, based on a plain Debian aarch64 base + added Plasma Mobile packages on top. I am rather hoping that the reference image doesn't use the xutils/createpackage scripts (for obvious reasons), and hoping to avoid (re)doing lots of potentially tedious and tricky packaging work myself. Specifically I'm looking for something similar to the anonscm.debian.org repository, containing the Plasma Mobile deb source files if they are available. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126381: kwayland backend for libkscreen
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126381/#review89681
---
backends/kwayland/waylandconfig.cpp (line 58)
<https://git.reviewboard.kde.org/r/126381/#comment61420>
Shouldn't m_syncLoop and be captured by reference?
`[m_thread,m_connection,&m_syncLoop] {...}`
backends/kwayland/waylandconfig.cpp (line 90)
<https://git.reviewboard.kde.org/r/126381/#comment61421>
Idem? Capture list should be...? `[m_thread,m_connection,&m_syncLoop] {...}`
- Johan Ouwerkerk
On Dec. 17, 2015, 6:53 p.m., Sebastian Kügler wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126381/
> ---
>
> (Updated Dec. 17, 2015, 6:53 p.m.)
>
>
> Review request for Plasma, Solid, Daniel Vrátil, and Martin Gräßlin.
>
>
> Repository: libkscreen
>
>
> Description
> ---
>
> This adds a kwayland backend to libkscreen.
>
> This backend uses KWayland's OutputManagement protocol for enlisting and
> configuring devices.
>
> Enlisting outputs
>
> KScreen's outputs are created from KWayland::Client::OutputDevice objects,
> they copy the data into kscreen's Outputs, and update these objects. A list
> of outputs is requested from the client Registry object.
>
> Configuring outputs
>
> The backend asks the global OutputManagement interface for an
> OutputConfiguration
> object, then sets the changes per outputdevice on this object, and asks the
> compositor to apply() this configuration.
>
> For this to work, the compositor should support the Wayland
> org_kde_kwin_outputdevice
> and org_kde_kwin_outputmanagement protocols, for example through
> KWayland::Server classes OutputDevice, OutputManagmenent and
> OuputConfiguration.
>
> General working
>
> WaylandBackend creates a global static internal config, available through
> WaylandBackend::internalConfig(). WaylandConfig binds to the wl_registry
> callbacks and catches org_kde_kwin_outputdevice creation and destruction.
> It passes org_kde_kwin_outputdevice creation and removal on to
> WB::internalConfig() to handle its internal data representation as
> WaylandOutput.
> WaylandOutput binds to org_kde_kwin_outputdevice's callback, and gets notified
> of geometry and modes, including changes. WaylandOutput administrates the
> internal representation of these objects, and invokes the global notifier,
> which then runs the pointers it holds through the updateK* methods in
> Wayland{Screen,Output,...}.
>
> KScreen:{Screen,Output,Edid,Mode} objects are created from the internal
> representation as requested (usually triggered by the creation of a
> KScreen::Config object through KScreen::Config::current()). As with other
> backends, the objects which are handed out to the lib's user are expected
> to be deleted by the user, the backend only takes ownership of its internal
> data representation objects.
>
>
> Diffs
> -
>
> CMakeLists.txt efac5ce
> autotests/CMakeLists.txt 07b7bbc
> autotests/configs/default.json 3ac3e19
> autotests/testconfigserializer.cpp 1af3069
> autotests/testkwaylandbackend.cpp PRE-CREATION
> autotests/testkwaylandconfig.cpp PRE-CREATION
> backends/CMakeLists.txt ff5d751
> backends/kwayland/CMakeLists.txt PRE-CREATION
> backends/kwayland/README.md PRE-CREATION
> backends/kwayland/waylandbackend.h PRE-CREATION
> backends/kwayland/waylandbackend.cpp PRE-CREATION
> backends/kwayland/waylandconfig.h PRE-CREATION
> backends/kwayland/waylandconfig.cpp PRE-CREATION
> backends/kwayland/waylandoutput.h PRE-CREATION
> backends/kwayland/waylandoutput.cpp PRE-CREATION
> backends/kwayland/waylandscreen.h PRE-CREATION
> backends/kwayland/waylandscreen.cpp PRE-CREATION
> src/backendmanager.cpp 89ae31e
> src/config.cpp e8b8a8f
> src/screen.h 4cd1e82
> tests/CMakeLists.txt d5e41d5
> tests/kwayland/CMakeLists.txt PRE-CREATION
> tests/kwayland/main.cpp PRE-CREATION
> tests/kwayland/waylandconfigreader.h PRE-CREATION
> tests/kwayland/waylandconfigreader.cpp PRE-CREATION
> tests/kwayland/waylandtestserver.h PRE-CREATION
> tests/kwayland/waylandtestserver.cpp PRE-CREATION
>
> Diff: https://git.reviewboard.kde.org/r/126381/diff/
>
>
> Testing
> ---
>
> The patch contains a test server, which is used for the autotests.
>
> The test server uses KWayland's server
Re: Noto fonts screw my system, please stop forcing fonts upon me!
> It is a very hard forced dependency on that font.
At build time, yes. At run time, you can simply reconfigure your
preferences in System Settings, uninstall both Oxygen and Noto
completely (with package manager) and still continue to use Plasma.
On Thu, Dec 17, 2015 at 11:09 PM, Mark Gaiser wrote:
>
>
> On Thu, Dec 17, 2015 at 10:09 PM, Eike Hein wrote:
>>
>>
>> Hi Mark,
>>
>> I think you might not be entirely clear on what we're doing.
>
>
> Perhaps.
>
>>
>>
>> It's not a forced dependency/font, it's a default font setting
>> which compells distro packagers to pull the font packages in as
>> dependency. However you can change the font in System Settings
>> to your liking.
>
>
> No, that is just not the case. The CMake line for frameworkintegration
> states:
> feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)
> message("** frameworkintegration uses Noto Sans
> (https://www.google.com/get/noto/) and Oxygen Mono
> (http://download.kde.org/stable/plasma/5.4.0/oxygen-fonts-5.4.0.tar.xz)
> fonts, ensure these are installed for use at runtime")
>
> It is a very hard forced dependency on that font.
>
>>
>> As for why Noto: It's designed for screens (both low and high
>> ppi), very high-quality and has very broad character set support,
>> enabling a high aesthetic standard consistently across a wide
>> variety of locales for the first time on Linux. In particular
>> in scenarios of mixed character set text this is a huge impro-
>> vement on the earlier situation (where glyph substitution often
>> puts typefaces that don't fit next to each other). It's also
>> under active ongoing development and has significant resources
>> behind it, and some of the leading type foundries around the
>> planet.
>
>
> What you say might be true and might be the goal of that font.
> But it is unusable for me at this moment and i'm not going to make bug
> reports about that.
>
> It is the google font (noto) with the google browser (chromium) that mainly
> screws things up completely.
>
> It's either heavily bugged or not ready to be used.
> Either case should be sufficient reason to not use it in Plasma 5.
>
>>
>>
>> As for your link to the website wrt/ line spacing, please
>> note that the style sheet of that website forces a line height
>> of 1.71429 (1.0 being normal), i.e. the line height there isn't
>> representative of normal text layout using Noto.
>
>
> You are wrong.
> The line height might be what you said, but what you see isn't a font
> rendered by chrome. The link i gave earlier
> (https://www.google.com/get/noto/#sans-lgc) shows the fonts rendered in a
> SVG image. The css line height has nothing to do with that. So what you see
> in that image is how it will look if you use that font. And that is just
> completely useless for desktop usage. It's fine to use that font in for
> example designs made in gimp or photoshop.. But not as desktop font!
>
>>
>>
>>
>> > Best regards,
>> > Mark
>>
>> Cheers,
>> Eike
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
> On Nov. 11, 2015, 7:14 a.m., Martin Gräßlin wrote: > > personal comment from X world: this is horrible, horrible ;-) What we > > should try is to make the desktop file available to the window. With KF > > 5.16 we will have all that's needed available. Let's try to improve this in > > Plasma 5.5 and scratch the code completely. > > Eike Hein wrote: > +1, I want to get rid of hacks, not pile on them > > Johan Ouwerkerk wrote: > > With KF 5.16 we will have all that's needed available. Let's try to > improve this in Plasma 5.5 and scratch the code completely. > > Great and I agree that the code is not great --all those wasted service > lookups and subtly broken caching of the answer-- but: where is this > alternative code that fixes everything? ;) Right now, I think this change > amounts to a trivial fix (just one forgotten case in the if-clause) to an > existing 'feature'/workaround that has a fairly immediate benefit (something > works again) and little cost: it's hardly a new one. > > Martin Gräßlin wrote: > yeah sure, this was not meant as a "blocking" comment. I think the change > should go in, but leave the decision to Eike. > > I btw. already started working on the improvement by proposing a new > addition to the NETWM spec and implementing it in KWindowSystem. > > Johan Ouwerkerk wrote: > Eike: what's your verdict? To ship or not to ship? > > (In the case of shipping it: please note that I do not have commit access > (just a KDE identity account) so please pull these changes because I cannot > commit them.) Now that my developer account has been approved (that took a few weeks), let's revisit this: @Eike: should I push to master or not? - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/#review88236 --- On Nov. 10, 2015, 6:54 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126016/ > --- > > (Updated Nov. 10, 2015, 6:54 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > --- > > Previously the taskmanager library contained a special case logic for windows > of KDE-4 KCM modules (only). > These modules were recognised by finding wmClass=Kcmshell4. > This logic is extended to cover kcmshell5 windows as well, meaning that KCMs > written for Plasma 5 are properly recognised now. > The net benefit is that these KCMs are displayed in the task manager with > their proper KCM program icons. > > This patch can be pulled from the kcmshell5-task-url-fixes branch at: > g...@github.com:cmacq2/plasma-workspace.git > > > Diffs > - > > libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e > > Diff: https://git.reviewboard.kde.org/r/126016/diff/ > > > Testing > --- > > Built with kdesrc-build, and tested using: `plasmawindowed > org.kde.plasma.icontasks`. > I checked the change works as expected by running `which kcmshell5` style as > well as `kcmshell5 style`: the icon of the window matches that in system > settings (as expected). > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126014: fix: kcms/input and kcms/touchpad should not be built if XInput is not present.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126014/ --- (Updated Nov. 25, 2015, 2:17 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit 0bd4f5d4777d1aa5978a67ee90bd8a963a245687 by Sebastian Kügler to branch Plasma/5.5. Repository: plasma-desktop Description --- Previously the presence of evdev headers would enable the kcms/input KCM module, and the presence of synaptics driver headers would enable the touchpad module. However, both KCMs unconditionally depend on XInput in some way in a (sub) CMakelists.txt file and deliberately break the build if it is not present or not properly detected. As per the convention in the KCM modules shipped by plasma-desktop, inclusion of the kcms/input and kcms/touchpad subdirectory is made conditional on XInput being present and properly detected during the cmake configure stage. This patch can be pulled from the fix-cmake-xinput-dep branch at: g...@github.com:cmacq2/plasma-desktop.git Diffs - kcms/CMakeLists.txt 321fbebba49dad32d237f3941dea9fedaf1a8e5a Diff: https://git.reviewboard.kde.org/r/126014/diff/ Testing --- Built without XInput development files, using kdesrc-build. Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126013: fix: kacess should not be built if xkb is not present
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126013/ --- (Updated Nov. 25, 2015, 2:04 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit 5667cb503e513bc5197b2ad008d1a921d450ffb3 by Sebastian Kügler to branch Plasma/5.5. Repository: plasma-desktop Description --- The XCB-XKB dependency of plasma-desktop is optional, however kacess depends directly and unconditionally on the xcb/xkb.h header file. This causes the build of plasma-desktop to fail at compile stage if the xkb header is not present. As per the convention in the kcm modules shipped by plasma-desktop, inclusion of the kacess subdirectory is made conditional on XKB being present and properly detected during the cmake configure stage. Diffs - CMakeLists.txt 193238a8dcbb2c6e2bda01c390c57ff2ecfebeb0 Diff: https://git.reviewboard.kde.org/r/126013/diff/ Testing --- Built without xkb header, using kdesrc-build Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126013: fix: kacess should not be built if xkb is not present
> On Nov. 10, 2015, 1:26 a.m., David Edmundson wrote: > > Ship It! > > Johan Ouwerkerk wrote: > Forgot to mention that the patch can be pulled from the fix-cmake-xkb-dep > branch at: g...@github.com:cmacq2/plasma-desktop.git > > Johan Ouwerkerk wrote: > Please note: I do not have commit access (just a KDE identity account) so > please pull these changes because I cannot commit them! > > Sebastian Kügler wrote: > I see a problem here. The features offered by kaccess are important and > necessary for some users. Are we just disabling it and then be done? I think > we need to put this stuff on a porting list and find a better solution than > to just not build everything that #includes xcbsomething. > > Johan, I think you're getting pretty close to us asking you to get a KDE > identity account with commit privileges, just so you know. > https://identity.kde.org/index.php?r=developerApplication is currently > broken, but I'd say as soon as it's fixed, let's start that process. > > Martin Gräßlin wrote: > > Are we just disabling it and then be done? > > I think it's the distros task to built it properly. > > And yes, we might need to rethink which platform specific packages should > be required in build. Just saying "hey let's make all X11 deps mandatory" is > also not the way to go anymore with Wayland. > Are we just disabling it and then be done? That is not what this change is about. The change rectifies an inconsistency between the top level cmake configure stuff which checks the build environment for dependencies, and the C++ code which uses these unconditionally (e.g. kaccess). The plasma-desktop build process deals with two classes of X11 deps: mandatory and optional. As it happens the XKB dep is classified optional in the top level cmake files, meaning configure will accept a build environment without XKB. This change makes sure that the 'optional' part is, indeed, consistently optional and does not result in build failure later (during make). People who need kaccess must necessarily install the XKB headers/development files anyway. If the XKB dep is found then kacess is still included in the build and nothing changes (effectively). (The alternative is to classify XKB as mandatory.) - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126013/#review88208 --- On Nov. 10, 2015, 12:52 a.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126013/ > --- > > (Updated Nov. 10, 2015, 12:52 a.m.) > > > Review request for Plasma. > > > Repository: plasma-desktop > > > Description > --- > > The XCB-XKB dependency of plasma-desktop is optional, however kacess depends > directly and unconditionally on the xcb/xkb.h header file. > This causes the build of plasma-desktop to fail at compile stage if the xkb > header is not present. > > As per the convention in the kcm modules shipped by plasma-desktop, inclusion > of the kacess subdirectory is made conditional on XKB being present and > properly detected during the cmake configure stage. > > > Diffs > - > > CMakeLists.txt 193238a8dcbb2c6e2bda01c390c57ff2ecfebeb0 > > Diff: https://git.reviewboard.kde.org/r/126013/diff/ > > > Testing > --- > > Built without xkb header, using kdesrc-build > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
> On Nov. 11, 2015, 7:14 a.m., Martin Gräßlin wrote: > > personal comment from X world: this is horrible, horrible ;-) What we > > should try is to make the desktop file available to the window. With KF > > 5.16 we will have all that's needed available. Let's try to improve this in > > Plasma 5.5 and scratch the code completely. > > Eike Hein wrote: > +1, I want to get rid of hacks, not pile on them > > Johan Ouwerkerk wrote: > > With KF 5.16 we will have all that's needed available. Let's try to > improve this in Plasma 5.5 and scratch the code completely. > > Great and I agree that the code is not great --all those wasted service > lookups and subtly broken caching of the answer-- but: where is this > alternative code that fixes everything? ;) Right now, I think this change > amounts to a trivial fix (just one forgotten case in the if-clause) to an > existing 'feature'/workaround that has a fairly immediate benefit (something > works again) and little cost: it's hardly a new one. > > Martin Gräßlin wrote: > yeah sure, this was not meant as a "blocking" comment. I think the change > should go in, but leave the decision to Eike. > > I btw. already started working on the improvement by proposing a new > addition to the NETWM spec and implementing it in KWindowSystem. Eike: what's your verdict? To ship or not to ship? (In the case of shipping it: please note that I do not have commit access (just a KDE identity account) so please pull these changes because I cannot commit them.) - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/#review88236 --- On Nov. 10, 2015, 6:54 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126016/ > --- > > (Updated Nov. 10, 2015, 6:54 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > --- > > Previously the taskmanager library contained a special case logic for windows > of KDE-4 KCM modules (only). > These modules were recognised by finding wmClass=Kcmshell4. > This logic is extended to cover kcmshell5 windows as well, meaning that KCMs > written for Plasma 5 are properly recognised now. > The net benefit is that these KCMs are displayed in the task manager with > their proper KCM program icons. > > This patch can be pulled from the kcmshell5-task-url-fixes branch at: > g...@github.com:cmacq2/plasma-workspace.git > > > Diffs > - > > libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e > > Diff: https://git.reviewboard.kde.org/r/126016/diff/ > > > Testing > --- > > Built with kdesrc-build, and tested using: `plasmawindowed > org.kde.plasma.icontasks`. > I checked the change works as expected by running `which kcmshell5` style as > well as `kcmshell5 style`: the icon of the window matches that in system > settings (as expected). > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126014: fix: kcms/input and kcms/touchpad should not be built if XInput is not present.
> On Nov. 10, 2015, 3:15 p.m., Martin Gräßlin wrote: > > Ship It! Please note: I do not have commit access (just a KDE identity account) so please pull these changes because I cannot commit them! - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126014/#review88217 --- On Nov. 10, 2015, 2:22 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126014/ > --- > > (Updated Nov. 10, 2015, 2:22 p.m.) > > > Review request for Plasma. > > > Repository: plasma-desktop > > > Description > --- > > Previously the presence of evdev headers would enable the kcms/input KCM > module, and the presence of synaptics driver headers would enable the > touchpad module. > However, both KCMs unconditionally depend on XInput in some way in a (sub) > CMakelists.txt file and deliberately break the build if it is not present or > not properly detected. > > As per the convention in the KCM modules shipped by plasma-desktop, inclusion > of the kcms/input and kcms/touchpad subdirectory is made conditional on > XInput being present and properly detected during the cmake configure stage. > > This patch can be pulled from the fix-cmake-xinput-dep branch at: > g...@github.com:cmacq2/plasma-desktop.git > > > Diffs > - > > kcms/CMakeLists.txt 321fbebba49dad32d237f3941dea9fedaf1a8e5a > > Diff: https://git.reviewboard.kde.org/r/126014/diff/ > > > Testing > --- > > Built without XInput development files, using kdesrc-build. > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126013: fix: kacess should not be built if xkb is not present
> On Nov. 10, 2015, 1:26 a.m., David Edmundson wrote: > > Ship It! > > Johan Ouwerkerk wrote: > Forgot to mention that the patch can be pulled from the fix-cmake-xkb-dep > branch at: g...@github.com:cmacq2/plasma-desktop.git Please note: I do not have commit access (just a KDE identity account) so please pull these changes because I cannot commit them! - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126013/#review88208 --- On Nov. 10, 2015, 12:52 a.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126013/ > --- > > (Updated Nov. 10, 2015, 12:52 a.m.) > > > Review request for Plasma. > > > Repository: plasma-desktop > > > Description > --- > > The XCB-XKB dependency of plasma-desktop is optional, however kacess depends > directly and unconditionally on the xcb/xkb.h header file. > This causes the build of plasma-desktop to fail at compile stage if the xkb > header is not present. > > As per the convention in the kcm modules shipped by plasma-desktop, inclusion > of the kacess subdirectory is made conditional on XKB being present and > properly detected during the cmake configure stage. > > > Diffs > - > > CMakeLists.txt 193238a8dcbb2c6e2bda01c390c57ff2ecfebeb0 > > Diff: https://git.reviewboard.kde.org/r/126013/diff/ > > > Testing > --- > > Built without xkb header, using kdesrc-build > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
> On Nov. 11, 2015, 7:14 a.m., Martin Gräßlin wrote: > > personal comment from X world: this is horrible, horrible ;-) What we > > should try is to make the desktop file available to the window. With KF > > 5.16 we will have all that's needed available. Let's try to improve this in > > Plasma 5.5 and scratch the code completely. > > Eike Hein wrote: > +1, I want to get rid of hacks, not pile on them > With KF 5.16 we will have all that's needed available. Let's try to improve > this in Plasma 5.5 and scratch the code completely. Great and I agree that the code is not great --all those wasted service lookups and subtly broken caching of the answer-- but: where is this alternative code that fixes everything? ;) Right now, I think this change amounts to a trivial fix (just one forgotten case in the if-clause) to an existing 'feature'/workaround that has a fairly immediate benefit (something works again) and little cost: it's hardly a new one. - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/#review88236 ------- On Nov. 10, 2015, 6:54 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126016/ > --- > > (Updated Nov. 10, 2015, 6:54 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > --- > > Previously the taskmanager library contained a special case logic for windows > of KDE-4 KCM modules (only). > These modules were recognised by finding wmClass=Kcmshell4. > This logic is extended to cover kcmshell5 windows as well, meaning that KCMs > written for Plasma 5 are properly recognised now. > The net benefit is that these KCMs are displayed in the task manager with > their proper KCM program icons. > > This patch can be pulled from the kcmshell5-task-url-fixes branch at: > g...@github.com:cmacq2/plasma-workspace.git > > > Diffs > - > > libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e > > Diff: https://git.reviewboard.kde.org/r/126016/diff/ > > > Testing > --- > > Built with kdesrc-build, and tested using: `plasmawindowed > org.kde.plasma.icontasks`. > I checked the change works as expected by running `which kcmshell5` style as > well as `kcmshell5 style`: the icon of the window matches that in system > settings (as expected). > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
> On Nov. 11, 2015, 7:14 a.m., Martin Gräßlin wrote: > > libtaskmanager/taskitem.cpp, line 627 > > <https://git.reviewboard.kde.org/r/126016/diff/1/?file=416095#file416095line627> > > > > don't we have to change to kdeinit5 here? No. The commandline is /path/used/to/launch/kcmshell5 style. The "kcmshell5 style" portion is eventually matched to the desktop file in getServiceLauncherUrl. - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/#review88236 ------- On Nov. 10, 2015, 6:54 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126016/ > --- > > (Updated Nov. 10, 2015, 6:54 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > --- > > Previously the taskmanager library contained a special case logic for windows > of KDE-4 KCM modules (only). > These modules were recognised by finding wmClass=Kcmshell4. > This logic is extended to cover kcmshell5 windows as well, meaning that KCMs > written for Plasma 5 are properly recognised now. > The net benefit is that these KCMs are displayed in the task manager with > their proper KCM program icons. > > This patch can be pulled from the kcmshell5-task-url-fixes branch at: > g...@github.com:cmacq2/plasma-workspace.git > > > Diffs > - > > libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e > > Diff: https://git.reviewboard.kde.org/r/126016/diff/ > > > Testing > --- > > Built with kdesrc-build, and tested using: `plasmawindowed > org.kde.plasma.icontasks`. > I checked the change works as expected by running `which kcmshell5` style as > well as `kcmshell5 style`: the icon of the window matches that in system > settings (as expected). > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/ --- (Updated Nov. 10, 2015, 6:54 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Previously the taskmanager library contained a special case logic for windows of KDE-4 KCM modules (only). These modules were recognised by finding wmClass=Kcmshell4. This logic is extended to cover kcmshell5 windows as well, meaning that KCMs written for Plasma 5 are properly recognised now. The net benefit is that these KCMs are displayed in the task manager with their proper KCM program icons. This patch can be pulled from the kcmshell5-task-url-fixes branch at: g...@github.com:cmacq2/plasma-workspace.git Diffs - libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e Diff: https://git.reviewboard.kde.org/r/126016/diff/ Testing (updated) --- Built with kdesrc-build, and tested using: `plasmawindowed org.kde.plasma.icontasks`. I checked the change works as expected by running `which kcmshell5` style as well as `kcmshell5 style`: the icon of the window matches that in system settings (as expected). Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126016/ --- Review request for Plasma. Repository: plasma-workspace Description --- Previously the taskmanager library contained a special case logic for windows of KDE-4 KCM modules (only). These modules were recognised by finding wmClass=Kcmshell4. This logic is extended to cover kcmshell5 windows as well, meaning that KCMs written for Plasma 5 are properly recognised now. The net benefit is that these KCMs are displayed in the task manager with their proper KCM program icons. This patch can be pulled from the kcmshell5-task-url-fixes branch at: g...@github.com:cmacq2/plasma-workspace.git Diffs - libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e Diff: https://git.reviewboard.kde.org/r/126016/diff/ Testing --- Built with kdesrc-build, and tested using: `plasmawindowed org.kde.plasma.icontasks`. I checked the change works as expected by running ``which kcmshell5` style` as well as `kcmshell5 style`: the icon of the window matches that in system settings (as expected). Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126014: fix: kcms/input and kcms/touchpad should not be built if XInput is not present.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126014/ --- (Updated Nov. 10, 2015, 2:22 p.m.) Review request for Plasma. Changes --- review board is doing something really weird, seeing changes where there aren't meant to be any, then unseeing them? Repository: plasma-desktop Description (updated) --- Previously the presence of evdev headers would enable the kcms/input KCM module, and the presence of synaptics driver headers would enable the touchpad module. However, both KCMs unconditionally depend on XInput in some way in a (sub) CMakelists.txt file and deliberately break the build if it is not present or not properly detected. As per the convention in the KCM modules shipped by plasma-desktop, inclusion of the kcms/input and kcms/touchpad subdirectory is made conditional on XInput being present and properly detected during the cmake configure stage. This patch can be pulled from the fix-cmake-xinput-dep branch at: g...@github.com:cmacq2/plasma-desktop.git Diffs - kcms/CMakeLists.txt 321fbebba49dad32d237f3941dea9fedaf1a8e5a Diff: https://git.reviewboard.kde.org/r/126014/diff/ Testing --- Built without XInput development files, using kdesrc-build. Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 126014: fix: kcms/input and kcms/touchpad should not be built if XInput is not present.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126014/ --- Review request for Plasma. Repository: plasma-desktop Description --- Previously the presence of evdev headers would enable the kcms/input KCM module, and the presence of synaptics driver headers would enable the touchpad module. However, both kcms unconditionally depend on XInput in some way in a (sub) CMakelists.txt file and deliberately break the build if it is not present or not properly detected. As per the convention in the kcm modules shipped by plasma-desktop, inclusion of the kcms/input and kcms/touchpad subdirectory is made conditional on XInput being present and properly detected during the cmake configure stage. This patch can be pulled from the fix-cmake-xinput-dep branch at: g...@github.com:cmacq2/plasma-desktop.git Diffs - kcms/CMakeLists.txt 321fbebba49dad32d237f3941dea9fedaf1a8e5a Diff: https://git.reviewboard.kde.org/r/126014/diff/ Testing --- Built without XInput development files, using kdesrc-build. Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126013: fix: kacess should not be built if xkb is not present
> On Nov. 10, 2015, 1:26 a.m., David Edmundson wrote: > > Ship It! Forgot to mention that the patch can be pulled from the fix-cmake-xkb-dep branch at: g...@github.com:cmacq2/plasma-desktop.git - Johan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126013/#review88208 --- On Nov. 10, 2015, 12:52 a.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126013/ > --- > > (Updated Nov. 10, 2015, 12:52 a.m.) > > > Review request for Plasma. > > > Repository: plasma-desktop > > > Description > --- > > The XCB-XKB dependency of plasma-desktop is optional, however kacess depends > directly and unconditionally on the xcb/xkb.h header file. > This causes the build of plasma-desktop to fail at compile stage if the xkb > header is not present. > > As per the convention in the kcm modules shipped by plasma-desktop, inclusion > of the kacess subdirectory is made conditional on XKB being present and > properly detected during the cmake configure stage. > > > Diffs > - > > CMakeLists.txt 193238a8dcbb2c6e2bda01c390c57ff2ecfebeb0 > > Diff: https://git.reviewboard.kde.org/r/126013/diff/ > > > Testing > --- > > Built without xkb header, using kdesrc-build > > > Thanks, > > Johan Ouwerkerk > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 126013: fix: kacess should not be built if xkb is not present
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126013/ --- Review request for Plasma. Repository: plasma-desktop Description --- The XCB-XKB dependency of plasma-desktop is optional, however kacess depends directly and unconditionally on the xcb/xkb.h header file. This causes the build of plasma-desktop to fail at compile stage if the xkb header is not present. As per the convention in the kcm modules shipped by plasma-desktop, inclusion of the kacess subdirectory is made conditional on XKB being present and properly detected during the cmake configure stage. Diffs - CMakeLists.txt 193238a8dcbb2c6e2bda01c390c57ff2ecfebeb0 Diff: https://git.reviewboard.kde.org/r/126013/diff/ Testing --- Built without xkb header, using kdesrc-build Thanks, Johan Ouwerkerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
