> On Sept. 4, 2015, 3:38 p.m., 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"
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 ... - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125043/#review84821 ----------------------------------------------------------- On Sept. 4, 2015, 4:22 p.m., 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, 4:22 p.m.) > > > 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 > >
