René J.V. Bertin posted on Mon, 15 Aug 2022 14:05:09 +0200 as excerpted:
> @Duncan: in what part of the code did you see the implementation?
For the plasmashell long-click behavior I haven't seen the actual code
(and if it was noted in the git log I either didn't notice or forgot about
it), just confirmed (after reading the initial posts to this thread) that
a long-click on the desktop did indeed trigger edit mode for me too.
But because it's a behavior clicking on the desktop itself, not something
in kwin, etc, I'd say it's almost certainly coded in either plasma-
workspace or plasma-desktop. And while I'm still a bit blurry on the
difference between the two, from what I can tell (IOW, my best guess based
on what I've seen including components that have moved from one to the
other), plasma-workspace contains the common code that would apply to
plasma-touch too, while plasma-desktop is desktop-specific. So my guess
would be plasma-workspace since it's behavior that applies to both the
desktop and the mobile/touch interface.
The implementation I /did/ see more of -- at least as git log comments, I
didn't then have reason to read the actual code and while I have a bit
more now it's not yet risen to a priority to actually go back and find the
git log comments and take a look at the code -- was in kwin, if I'm not
mistaken, and was the relatively recent introduction of the 3-finger-swipe
stuff, and earlier the four-finger-swipe stuff, to activate desktop
switching and the overlay and grid effects -- which are all global and
thus kwin's turf (as opposed to the above long-click which is plasmashell
specific).
I'm pretty certain I could/can find the kwin code, since I know I saw the
git log entries for it and can search back in git history for them, but
rather less certain I could find the (presumably) plasma-workspace code,
since I don't have git log entries to point me at it, thus leaving me
either trying to search for git log entries that might not be there, or
trying, as a git-sources-consumer literate[1] and patch literate but non-
dev kde-using gentooer, to find it in the code directly.
---
[1] Git: consumer-side aka sysadmin-side vs. dev-side: For example, I
routinely do the git consumer-side tasks of checking git logs, inspecting
individual git commits, sometimes with -R to create a revert-patch I can
apply as-is or modify further, etc. But the best I can do in terms of
/submitting/ a patch is file a bug with an attached patch, even tho the
kde bug attachment process specifically says bugs aren't checked for
patches, because I'm not a dev and don't know the dev-side process for
actually creating a branch, doing a commit, and pushing the result to
invent.kde.org in ordered to create a PR/pull-request.
Similarly, running the gentoo/kde project live-git packages, when I detect
that a gentoo-level patch needs rebased, all I can do is file a gentoo bug
requesting it, perhaps with a patch attached that I've created by manually
reviewing the old patch and comparing it against the new code. I haven't
a clue how to actually do it in git and submit what I'm told is a rebase
as a pull request, because that's dev-side and all my git experience is
admin/consumer-side.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
