> On Sept. 4, 2015, 1:38 nachm., Martin Gräßlin wrote: > > You are aware that this is a dead repo and that this is a new feature for a > > repository that has been feature frozen for years? > > > > Given that I think this should not and never be merged. If you want to keep > > the repo going for OSX I suggest to create a branch for your patches. > > René J.V. Bertin wrote: > As I wrote in the summary, I don't consider this so much a new feature as > a fix to an omission because the parameter is used in kdelibs (and possible > elsewhere I don't know about). Besides, this concerns a KCM that I think > should have been part of kde-runtime (but that's probably a moot point). > > Also, this is not only about OS X. There are several distribution > releases that ship KDE4 as the default desktop officially supported LTS > version, and I'd hope they too would be interested in upstream fixes. As such > I don't see the point in creating another branch, or in maintaining a freeze > on a branch that isn't going to see any more releases > A separate repository with only fixes, organised by project and possibly > target platform could make sense though. > > Luigi Toscano wrote: > I disagree: a separate branch makes definitely more sense than a separate > repository (which would lead more confusion and divide the code). > > René J.V. Bertin wrote: > In case it wasn't clear: I meant a separate repository containing only > patchfiles. The patch under consideration here is not specific to OS X so > wouldn't justify the creation of an OS X branch (I just haven't gotten around > to including it in my Kubuntu PPA yet). > > Jeremy Whiting wrote: > I think what Martin and Luigi are suggesting is a branch maybe called LTS > or something for feature improvements since master is frozen and has been for > quite a long time. > > Luigi Toscano wrote: > Exactly, a separate repository with patches does not make sense (git > already manages patches). > > René J.V. Bertin wrote: > Git doesn't make it particularly easy to keep patches (or patch sets) > separate once they're committed (and a couple other things have been > committed too), or does it? > > Martin Klapetek wrote: > Sure it does. Here is a random git commit from plasma-workspace -- > https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=e2df9af6e2df4ba1c07dc40d43ecd591584db498 > - you can get the diff with "git show > e2df9af6e2df4ba1c07dc40d43ecd591584db498", you can get a diff from that > commit to HEAD by "git diff e2df9af6e2df4ba1c07dc40d43ecd591584db498" or diff > set between two commits - "git diff > e2df9af6e2df4ba1c07dc40d43ecd591584db498..6ee0d63af943526e2453631c6c709861061f08ac" > > René J.V. Bertin wrote: > We're getting a bit side-tracked, but: > Suppose this "expose WheelMouseZooms" patch would get commited, followed > by the patch to build kcm_input and other kcontrol components on OS X, and > then some more patches that touch neighbouring lines, and then I do some > polishing up on the WheelMouseZooms patch which also gets commited. Will it > be easy for someone who just wants that patch to extract the WheelMouseZooms > patch from git, or would it be easier to maintain that patch as a separate > patchfile (like debian patches with dquilt)? > I know it isn't always straightforward to maintain patchfiles, but I'm > not so sure that working with long, meaningless and unreadable commit hashes > is easier ...
git cherry-pick <some_hash> "git log --oneline renes_fixes" prints you a list of commits in the "renes_fixes" branch 123456 expose WheelMouseZooms You *can* use this to eg. grep for a commit message and pass the matching hash to git cherry-pick, but that's of course not unambigious (that is why there are the hashes) And yes: they can use quickgit.kde.org to click their way to download a particular patch - if you meant that. - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125043/#review84821 ----------------------------------------------------------- On Sept. 4, 2015, 2:22 nachm., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125043/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2015, 2:22 nachm.) > > > Review request for KDE Software on Mac OS X, kde-workspace and kdelibs. > > > Repository: kde-workspace > > > Description > ------- > > KDE4 has been providing a setting that (would have) allowed to avoid unwanted > text zooming during simulated inertial scrolling (scroll coasting). KDE PIM > applications were immune to that issue because certain KDELibs classes use > the parameter, which made it all the more annoying that other (e.g. > Kate-based) applications weren't. Sadly this setting wasn't published via a > GUI. > > This patch adds a checkbox to the input ("mouse") KCM which seemed like the > most appropriate place if not only because it also makes sense to provide > this KCM on non-X11 platforms like OS X and MS Windows (where settings like > "double or single click" are relevant). > > I consider this a fix of an omission bug, but I realise that it could also be > considered a new feature, so this RR is also intended to give some public > exposure to my patch rather than keeping it to myself. > > > Diffs > ----- > > kcontrol/input/kmousedlg.ui b48a606 > kcontrol/input/mouse.h d926a99 > kcontrol/input/mouse.cpp cebb174 > > Diff: https://git.reviewboard.kde.org/r/125043/diff/ > > > Testing > ------- > > For now only on OS X with kdelibs 4.14.11 . > > > Thanks, > > René J.V. Bertin > >