Re: Proposal unify back our release schedules

> As a result I'll rescind my idea to slow down Frameworks feature > releases. Then I'll take over and fight for it! >that having a fast Frameworks release cycle allows > people developing apps with features in Frameworks to not have to live > on master like we do in Plasma. That was the

Re: Proposal unify back our release schedules

>> in that event I'd like for us to put it >> to a formal KDE e.V. vote > Is this an eV topic? Yes and no. The original decision had a big impact, changing things again will have a big impact. It's not something that should be decided by a few people, nor is it something that should be decided

Re: APIs for persistent remote access and headless/hybrid sessions

Hello, Thanks for reaching out and keeping us in the loop. It's better now than after something has been implemented. We are definitely interested in working in this area. We have a lot of the proposed core infrastructure that's listed in that proposed specification; pipewire, creation of

Re: revisiting the sycoca

> All in all I am not convinced we still need the sycoca As you noted it's 3 different things. I suggest we tackle it as 3 different tasks. The mime apps part we should be able to drop silently without any issue. The menu and desktop files are still needed by krunner and plasmashell and

Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

On Mon, Sep 18, 2023 at 5:45 AM Neal Gompa wrote: me of them, I've got ideas, others less so. > > The first thing that came up was that KiCad seems to need help and has > had a bad experience interfacing with some folks over resolving their > issues moving into a Wayland world. Given I'm quoted,

Frameworks / Plasma/ Gear Release Schedule Plan

in February Due to the delay of KDE Gear by an additional patch release of 23.08 will be made. David Edmundson

Frameworks / Plasma/ Gear Release Schedule Plan

in February Due to the delay of KDE Gear by an additional patch release of 23.08 will be made. David Edmundson

Re: Planning the final 6 release timeframes

As a reminder this meeting is tonight in 3 hours. David

Re: Planning the final 6 release timeframes

As a reminder this meeting is tonight in 3 hours. David

Re: Planning the final 6 release timeframes

Video call at https://meet.kde.org/b/ada-mi8-aem

Re: Planning the final 6 release timeframes

Video call at https://meet.kde.org/b/ada-mi8-aem

Re: Planning the final 6 release timeframes

A time has been chosen on the poll with a clear winner: 4th September 18:00 CEST See you all there David Edmundson

Re: Planning the final 6 release timeframes

A time has been chosen on the poll with a clear winner: 4th September 18:00 CEST See you all there David Edmundson

Planning the final 6 release timeframes

h multiple rounds of elimination. Open discussion ahead of time is available at: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/55 David Edmundson

Planning the final 6 release timeframes

h multiple rounds of elimination. Open discussion ahead of time is available at: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/55 David Edmundson

Re: Porting aid place for Plasma stuff?

For kwayland I would suggest to keep it in it's own repo kept being called kwayland Dialog is in Plasma-framework which is moving to workspace anyway. I'm not sure of the status of that move is. I would put suggest putting D stuff in plasma-framework (or whatever it ends up being called)

Re: Minutes from the porting BOF

Updates on this topic after the plasma BOF. There's some concerns (by me mostly) about Plasma being committed to a rigid schedule. As such the following was somewhat agreed upon. We can probably delay the .12 release of KDE Gear if it's needed. The Qt 6 transition is a special case. If we want

Minutes from the porting BOF

They're in a short format, ping if there's any questions. # Timelines KDE Gear 0.8 will be Qt5 ONLY KDE Gear .12 should be Qt5 and Qt6 Will REQUIRE plasma to be out (for themes and stuff). Plasma timing discussion is tomorrow, so that maybe throws things out. Apps should keep master as Qt5 and

Re: sentry evaluation

>Did you like it? When we had an initial influx of reports after you first blogged it was amazing. We were getting reports in places I hadn't seen before on bugzilla. It did a really good job of implicitly showing which things were the most relevant needing fixing, and what's just noise we can

Re: kf6 deconflictor progress

On Fri, Apr 28, 2023 at 5:59 PM Jonathan Riddell wrote: > > The deconflictor job we run in neon still has a bunch of files overlapping > between kf5 and kf6 > > https://build.neon.kde.org/job/test_kf6_deconflictor/ > >

Re: kitemmodels kf6 build failure

Please ensure you are building with -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.91.0

KF5 branches

There is now a "kf5" branch in all frameworks repos as discussed last frameworks meeting. Starting now any commits that are also wanted in the next KF5 should be cherry-picked after landing. This does *not* mean master is fully open for going into KF6 dev mode. Now the kf5 branches exist, we'll

Re: How long with the kde-qt5.15 repo be kept updated?

I can't see our KDE patch collection going away whilst we still have Qt5 apps shipping. We have patches that Qt haven't backported that we deemed important and it'd be more work to get distros to swap back again. It doesn't cost anything to keep it there. It will probably get fewer and fewer

Re: Copying po/docbook files to repositories nightly

>Opinions? Comments? So our releases will end up a 1:1 with a git tag? That would be super-duper amazing for many cleanup things, including the security aspect +1 What's the plan for stable branches? We'll either need to port all active stable branches at the same time or we will have to

Plasma 6 Planning sprint starts tomorrow!

I'm sure everyone is excited: Full schedule and joining instructions available at: https://invent.kde.org/plasma/plasma-workspace/-/issues/32 Looking forward to seeing your all David

Re: KQuickChatComponents in kdereview

# Overall: How is LTR meant to work? You're using it for internal layouting purposes so any genuine LTR would now be quite broken, I suspect it will all appear aligned to one side. At a minimum we would need to inverse the logic inside ChatBubble::tailBase and it needs some testing # ChatBubble:

Re: KQuickChatComponents in kdereview

All of https://invent.kde.org/libraries/kquickchatcomponents/-/blob/master/src/controls/ appear to be missing API docs David

Re: Developer setups for user D-Bus service files?

> This triggered yet another idea with me, and I came across > https://www.freedesktop.org/software/systemd/man/environment.d.html > upon which I tried to add a file > /home/mydevuser/.config/environment.d/60-test.conf > with the content > --- 8< --- >

Re: Developer setups for user D-Bus service files?

>at least with systemd controlled start (but possibly also before Since forever. >So, what standard approach should we take as developers here? Personally I would say developers should avoid having a system installed KDE, you're only making life harder for yourself. Then things are relatively

Re: QML API docs for C++ wrapper types?

We have examples of where we have done this. Though I wouldn't necessarily use the word "properly". In Plasma-framework we have a manually made list where we can write the plugin name and list items by their exported QML type name.

Re: Gitlab CI - Inbound

Excellent news!! Thanks very much > Once the scripts have been proven successfully for Frameworks, we will look > at extending them to projects that depend only on Frameworks and repositories Does this mean we would like Plasma to wait a while before merging? Is it worth us creating the kde-cli

Re: Gitlab CI - Inbound

Excellent news!! Thanks very much > Once the scripts have been proven successfully for Frameworks, we will look > at extending them to projects that depend only on Frameworks and repositories Does this mean we would like Plasma to wait a while before merging? Is it worth us creating the kde-cli

Re: Gitlab CI - Inbound

Excellent news!! Thanks very much > Once the scripts have been proven successfully for Frameworks, we will look > at extending them to projects that depend only on Frameworks and repositories Does this mean we would like Plasma to wait a while before merging? Is it worth us creating the kde-cli

Re: [kdiff3] [Bug 436826] kdiff3 has no window, wayland, gnome

>I assume that is related to this: >https://gitlab.gnome.org/GNOME/mutter/-/issues/217 Not really. There are code paths upstream in QtWayland to support this case. > I am terminating support for gnome/wayland unless and until gnome Lets not just be dramatic. There is a bug, it not necessarily

Re: Moving plasma-frameworks & krunner to Plasma release set for *6? (was: Re: KF6 meeting notes 2021-04-17)

> It seems these days the only real user of plasma-frameworks & krunner > libraries is the Plasma shell itself, with other applications only providing > plugins/extensions and only targeting Plasma again. That is mostly in line with other discussions in plasma. There is a ticket splitting

Re: KF6 online sprint: March 27-28

I wanted to bump this thread, just so people remember that it is this weekend! There are many many slots still available. David

Re: KF6 online sprint: March 27-28

I wanted to bump this thread, just so people remember that it is this weekend! There are many many slots still available. David

Re: KCGroups in KDEreview

> > (where 1000 is of course dynamic) > > Ditto, what enum names could we give to those? / -> All /system.slice -> System user.slice/user-1000.slice/user@1000.service -> User user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps

Re: KCGroups in KDEreview

> > (where 1000 is of course dynamic) > > Ditto, what enum names could we give to those? / -> All /system.slice -> System user.slice/user-1000.slice/user@1000.service -> User user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps

Re: Plasma Firewall on KDE Review

>Doesn't look like translations would work, at least the C++ part, not sure >about the QML one. You were right at the time of writing. I have tested that now both the C++ and QML side have correct translations loaded with x-test. David

Re: Plasma Framework and Kirigami unittests

One down: https://invent.kde.org/frameworks/kirigami/-/merge_requests/200

Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

On Sun, 20 Dec 2020, 11:48 Friedrich W. H. Kossebau, wrote: > (Added Han Young as BCC: based on code email address, as the task is not > public, and not sure you are subscribed to the mailinglists) > > Am Sonntag, 20. Dezember 2020, 12:05:46 CET schrieb David Edmundson: > >

Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

Please see https://community.kde.org/Policies/Application_Lifecycle about the process of adding things to frameworks. As for plasma, we have a weather library there, so the comment about it being easier for new plasmoids doesn't hold directly. Maybe you can expand on what's different? David

Re: KCGroups in KDEreview

On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > Ultimately this isn't really dealing with cgroups directly but with > > the manager to control them, systemd. > > > &g

Re: KCGroups in KDEreview

On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > Ultimately this isn't really dealing with cgroups directly but with > > the manager to control them, systemd. > > > &g

Re: KCGroups in KDEreview

Ultimately this isn't really dealing with cgroups directly but with the manager to control them, systemd. That's correct usage, kernel docs of cgroups say to go via a controller for write operations. However that at point is it worth naming the library ksystemd? It might cause some contention due

Re: KCGroups in KDEreview

Ultimately this isn't really dealing with cgroups directly but with the manager to control them, systemd. That's correct usage, kernel docs of cgroups say to go via a controller for write operations. However that at point is it worth naming the library ksystemd? It might cause some contention due

Re: Synchronized release schedule for Plasma

> > As distribution package maintainers, we would like Plasma developers to > slightly alter the release schedule to align releases with a more > distribution friendly cycle. You could consider shortening one release > cycle (and then keep the 6 month schedule) to align releases. > We have in the

Re: Telemetry information in Plasma

> > It does indeed appear to always be null. Just to clarify, as this email was intended as a privacy review. That's a bug that will fail safe with less collected. Everything looks safe. David

Re: Telemetry information in Plasma

On Tue, Nov 10, 2020 at 3:21 AM Nicolás Alvarez wrote: > > El lun., 9 de nov. de 2020 a la(s) 13:32, Aleix Pol (aleix...@kde.org) > escribió: > > - BasicUsageStatistics > > Usage time > > Launches count (Discover) > > Is "launches count" reset to 0 after each telemetry submission, or is > it

Re: RSIBreak / KIdleTime on Wayland

change made: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133

Re: RSIBreak / KIdleTime on Wayland

change made: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133

Re: RSIBreak / KIdleTime on Wayland

>If the user was idle for a second (using a KIdleTime timeout), I start my own >idle time counter (counter++ every second). >Then I catch the next resume event (next user input) and reset my counter to 0. That sounds like what I had in mind. > 2) It works with XWayland, but only detects user

Re: RSIBreak / KIdleTime on Wayland

>If the user was idle for a second (using a KIdleTime timeout), I start my own >idle time counter (counter++ every second). >Then I catch the next resume event (next user input) and reset my counter to 0. That sounds like what I had in mind. > 2) It works with XWayland, but only detects user

Re: RSIBreak / KIdleTime on Wayland

> > Yes, I meant that progress bar. > I've had that 1s idle timer idea as well, unfortunately after writing this, > but thank you for confirming that this would indeed work. > I will give that a try and if I can get RSIBreak to a working state on > wayland submit a PR for it. Excellent, thank

Re: RSIBreak / KIdleTime on Wayland

> > Yes, I meant that progress bar. > I've had that 1s idle timer idea as well, unfortunately after writing this, > but thank you for confirming that this would indeed work. > I will give that a try and if I can get RSIBreak to a working state on > wayland submit a PR for it. Excellent, thank

Re: RSIBreak / KIdleTime on Wayland

> I agree, if we can't make the KIdleTime framework work in Wayland there > should be a way to query the framework if it's going to work or not. Just to make sure that's not misread by others; the framework works for the majority of methods used in the common case, just not this one polling

Re: RSIBreak / KIdleTime on Wayland

> I agree, if we can't make the KIdleTime framework work in Wayland there > should be a way to query the framework if it's going to work or not. Just to make sure that's not misread by others; the framework works for the majority of methods used in the common case, just not this one polling

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> > your_merge_request_commit_history > > . > > However, it remains a fairly advanced workflow which is challenging for > newcomers, drive-by-developers, and people not as familiar with git. For > these

Re: KDE CI: Frameworks » kxmlgui » kf5-qt5 SUSEQt5.12 - Build # 190 - Still Unstable!

My fault. Fix on review. David

Re: Commit hookscripts operating only on commits from email addresses associated with a Bugzilla account

> So here's an idea: close the bug with the committer's own Bugzilla > account when an account is found that matches the email address in the > commit. Otherwise, use a bot account so that the bug at least gets > closed as intended. Could that work? > Any developer in question can also change

Re: Move Plasma Firewall to KDE Review

>Arent we trying to portaway from kdelibs4support ? Yes. Though in this particular case It appears that is just a CMakeLists.txt leftover, it builds fine with that line removed.

Re: kwayland's testRemoteAccess still flaky

Urgh, let me just remove that test. No-one will even use that protocol soon anyway.

Re: Looking for maintainer of Wayland KDE Idle protocol

On Tue, Jul 7, 2020 at 12:18 PM David Edmundson wrote: > >It seems that the most popular Wayland protocol for detecting when a > user is "idle" is this protocol that is a part of KDE. > > Yes-ish. > > Note it is now being upstreamed: > > https://gitlab.free

Re: Looking for maintainer of Wayland KDE Idle protocol

>It seems that the most popular Wayland protocol for detecting when a user is "idle" is this protocol that is a part of KDE. Yes-ish. Note it is now being upstreamed: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/29 So now is a good time for any changes. Any

D26503: [Dialog Shadows] Port to KWindowSystem shadows API

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R242 Plasma Framework (Library) BRANCH port-to-shadows-api REVISION DETAIL https://phabricator.kde.org/D26503 To: zzag, #plasma, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack,

D28355: Introduce function ecm_install_configured_file

davidedmundson added a comment. Moved to invent. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D28355 To: davidedmundson, #build_system Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham,

D28355: Introduce function ecm_install_configured_file

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R240:2976b27a6c0b: Introduce function ecm_install_configured_file (authored by davidedmundson). REPOSITORY R240 Extra

D29050: KRunner fix prepare/teardown signals

davidedmundson added a comment. > the runner "backend" is used (from the QML side of things). Repo is called milou REPOSITORY R308 KRunner BRANCH krunner_signal_bugfix (branched from master) REVISION DETAIL https://phabricator.kde.org/D29050 To: alex, meven, ngraham, broulik Cc:

D29228: [KProcessRunner] Use only executable name for scope

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D29228 To: broulik, #frameworks, #plasma, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29811: t/simplify-sending-data-through-socket

davidedmundson added a comment. > that would probably mean recompiling most of KDE (Debian has packages for 5.69 only). I will check out your change and see what remains. This isn't a universal rule that always applies, but generally speaking you can just roll back the the frameworks

D29811: t/simplify-sending-data-through-socket

davidedmundson added a comment. Your base kcrash is quite out of date - I simplified this method considerably a month ago, which gets rid of the two paths. Also can you check your commit messages, I don't know if it's phab being weird, but they all start with "t/" in the phab UI,

D29034: Add systemd user service file for kded

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R297 KDED REVISION DETAIL https://phabricator.kde.org/D29034 To: broulik, #plasma, #frameworks, davidedmundson Cc: bruns, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh,

Request for plasma framework patch release

We seem to have a common crasher newly introduced in plasma-framework. A dozen reports in a few days. Can I ask for a plasma-framework 5.70.1. with c215c54eced5bd0b195c208dd72bb580e65f8fe4 cherry-picked. Sorry. David

D29742: Avoid potential disconnect of all signals in IconItem

This revision was automatically updated to reflect the committed changes. Closed by commit R242:c215c54eced5: Avoid potential disconnect of all signals in IconItem (authored by davidedmundson). REPOSITORY R242 Plasma Framework (Library) CHANGES SINCE LAST UPDATE

D29742: Avoid potential disconnect of all signals in IconItem

davidedmundson created this revision. davidedmundson added a reviewer: Plasma. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY m_svgIcon can be null. disconnect(q, nullptr, nullptr,

D29680: Fix modified line marker in kate minimap

This revision was automatically updated to reflect the committed changes. Closed by commit R39:f2b0dcdefea7: Fix modified line marker in kate minimap (authored by davidedmundson). REPOSITORY R39 KTextEditor CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29680?vs=82663=82717

D29680: Fix modified line marker in kate minimap

davidedmundson added a comment. What about ktexteditor? REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D29680 To: davidedmundson, #kate Cc: ngraham, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, bruns, demsking, cullmann, sars,

D29680: Fix modified line marker in kate minimap

davidedmundson created this revision. davidedmundson added a reviewer: Kate. Herald added projects: Kate, Frameworks. Herald added subscribers: kde-frameworks-devel, kwrite-devel. davidedmundson requested review of this revision. REVISION SUMMARY Our pixmap is the size of the number of lines in

D29409: Add documentation line on KCM translations

davidedmundson added inline comments. INLINE COMMENTS > cblack wrote in configmodule.h:98 > You probably want to use backticks instead of quotes as this is referring to > something codewise. I don't understand. REPOSITORY R296 KDeclarative REVISION DETAIL

D29668: Do not reject icon theme dir with invalid context/type.

davidedmundson added a comment. Seems sensible, given it's valid to have an empty context. I don't know enough about icons to know all possible ill effects. If there's no other comments in a few days consider this a "ship it!" REPOSITORY R302 KIconThemes REVISION DETAIL

D29292: Port KKeySequenceItem to QQC2

This revision was automatically updated to reflect the committed changes. Closed by commit R296:c730edc8dce4: Port KKeySequenceItem to QQC2 (authored by davidedmundson). REPOSITORY R296 KDeclarative CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29292?vs=81557=82604 REVISION DETAIL

D29511: Label: Add ping-pong logic

davidedmundson requested changes to this revision. davidedmundson added a comment. Plasmacomponents is deprecated please see Plasmacomponents3 then see the readme within that and put this somewhere else. 1. Label is a super super super common element we don't want to add any overhead

D29503: Pixel align children of GridViewInternal

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R296 KDeclarative BRANCH master REVISION DETAIL https://phabricator.kde.org/D29503 To: fvogt, #frameworks, broulik, mart, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack,

D25814: [KColorScheme] Add SeparatorColor

davidedmundson added a comment. Relevant link on that last comment: https://bugreports.qt.io/browse/QTBUG-63331 They actively seeked our opinion on colour roles REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D25814 To: ndavis, #frameworks, #vdg Cc:

D29397: KPreviewJob : Support for DeviceRatioPixel

davidedmundson added a comment. > Allow users of KPreviewJob to request a devicePixelRatio for generated thumbnails. At the risk of asking a stupid question, why? As opposed to just having a width and height always be in device pixels. We're always working with pixmaps is there a

D29409: Add documentation line on KCM translations

davidedmundson created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REPOSITORY R296 KDeclarative BRANCH master REVISION DETAIL https://phabricator.kde.org/D29409 AFFECTED FILES

D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R175 KHolidays REVISION DETAIL https://phabricator.kde.org/D29374 To: weisi, winterz, davidedmundson Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29371: KMainWindow: remove doc paragraph about KGlobal::ref usage

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R263 KXmlGui BRANCH master REVISION DETAIL https://phabricator.kde.org/D29371 To: dvratil, dfaure, #frameworks, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh,

D28498: [xdgoutput] Explicitly set version of server interface

davidedmundson abandoned this revision. davidedmundson added a comment. All these problems go away with KWaylandServer \o/ REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28498 To: davidedmundson, #kwin Cc: zzag, anthonyfieroni, apol, kde-frameworks-devel,

D29278: Port KWin to KWaylandServer

davidedmundson added a comment. > Hmm, I can't build kwin Hit the same thing, we've since fixed that (patch in kwayland-server) REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag,

D29278: Port KWin to KWaylandServer

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev,

D29292: Port KKeySequenceItem to QQC2

davidedmundson added inline comments. INLINE COMMENTS > broulik wrote in KeySequenceItem.qml:57 > Why is it the worst? It keeps us from having to hardcode magic numbers. See task. REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D29292 To: davidedmundson, #plasma,

D29292: Port KKeySequenceItem to QQC2

davidedmundson added inline comments. INLINE COMMENTS > cblack wrote in KeySequenceItem.qml:57 > Are we able to use some form of units? Hardcoding this seems wrong. > Can we use the non-attached version here please since it's not likely It's the worst! > Are we able to use some form of units?

D29292: Port KKeySequenceItem to QQC2

davidedmundson created this revision. davidedmundson added a reviewer: Plasma. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY This implicitly fixes a bug where space is used in the shortcut

D29231: Add keyboard_shortcuts_inhibit protocol

davidedmundson added inline comments. INLINE COMMENTS > zzag wrote in keyboard_shortcuts_inhibit_interface.cpp:21 > You've probably meant Q_DECL_HIDDEN, right? > > On an unrelated note: there are valid arguments against nested private > classes so it would be really nice if we revisit this

D29231: Add keyboard_shortcuts_inhibit protocol

davidedmundson added a comment. Let's wait for the new kwaylandserver repo before pushing. But ++, looks good. INLINE COMMENTS > keyboard_shortcuts_inhibit_interface.cpp:21 > + > +class KeyboardShortcutsInhibitorInterface::Private : public >

Re: Splitting KWayland

That is what I imagined. The protocols section contains some things we can strip down. We shouldn't host anything that's in wayland-protocols like text-input. Also I think there's some dead things like plasma-effects. But we can do that sort of thing anytime before the first release. David

D29256: [server] Introduce mapped() signal

davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R127 KWayland BRANCH introduce-mapped-signal REVISION DETAIL https://phabricator.kde.org/D29256 To: zzag, #kwin, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh,

Re: Splitting KWayland

On Tue, 28 Apr 2020, 07:24 Vlad Zahorodnii, wrote: > On 4/27/20 4:12 PM, David Edmundson wrote: > > I don't think we want to remove client or server tests on this one. As > > the client tests covered the server side too > > Hmm, does this mean we are going to keep both the

  1   2   3   4   5   6   7   8   9   10   >