By default, FVWM can't use more than 5/9 mouse buttons, which is not enough for modern inputs - for example, my Logitech mouse has 11 buttons, my touchpad drivers (mtrack) has 14. Except from the consequences mentioned in the URL above, which shouldn't interfere with people using the default values, I haven't found problems. Attached is a patch (patch -p0 < fvwm-accept_more_buttons.patch) against fvwm-2.6.3 (btw, 2.6.4 is out for quite a long time). Please consider making it the default or available via some USE. PS: I've set 15 buttons, since that's the example from the page and which should be good enough for most people, but according to the source, 31 is the upper limit. Reproducible: Always
Created attachment 308721 [details, diff] patch to accept more buttons than fvwm's default limit
Have you contributed it upstream yet?
I suggest that you( avx) send this to the fvwm-workers mailing list and see what Thomas Adam says. The patch is trivial enough but I can barely remember a conversation about this in the past, and if that's true, then there might be a reason why that number is that low.
Sure, I'll ask Thomas, but since it's stated in the FAQ, I guess they're very well aware and maybe waiting for a proper fix from X.org. While "doing it right" is surely good, having this patch available as a USE-flag might be good in the meantime, as you say, it's trivial so it's imho no reason to use a local overlay for that.
(In reply to comment #4) > Sure, I'll ask Thomas, but since it's stated in the FAQ, I guess they're > very well aware and maybe waiting for a proper fix from X.org. > > While "doing it right" is surely good, having this patch available as a > USE-flag might be good in the meantime, as you say, it's trivial so it's > imho no reason to use a local overlay for that. I see no harm in the patch (the translucent menu patch is far more invasive than this one, for example), and I can't imagine how it could break anything that's already working. So, I'd say that, if this is to be merged, we should merge it unconditionally, and not spoil the thing with yet-one-more-use-flag. Still, I'd like to hear the voice from someone who really knows what this is about, at Xorg level. Not that my opinion counts, but there you are anyway. :)
Oh, of course, you should first apply for this to be merged upstream. If it means really no harm, there's no reason why this should be a local patch only for Gentoo.
Hi, This one's easy to answer. The reason it's not the default, and will never be until other X servers catch up (yes, we still have users running FVWM on X servers other than XFree86 and X.org), mouse buttons over 5 tend not to be supported. Granted, this doesn't always reflect the hardware of 2012, or the platforms those users owning such hardware happen to use, but there is neither no portable way of determining which XServer FVWM is running on, and the code complexity would only increase this. (c.f. ServerVendor()). So people wishing to use this must do so at their discretion, and even then, I wouldn't want to impose this as a patch to FVWM, even at the distribution level. That said, I already have an internal ban on bug reports against FVWM coming from Gentoo, given the history of this distribution patching programs to the hilt; I always get people to use the CVS version to just malign the likelihood of some third-party patch causing problems -- it's easier that way. So by all means patch FVWM locally -- it's just never going to make it in to FVWM at all. -- Thomas Adam
While this patch may be trivial, it is a maintainer nightmare to maintain sets of local patches and given upstream's response in comment #7 we should work with upstream instead of against them so I would choose not to patch fvwm ebuild. So there are two options moving forward, 1) Do nothing, close this bug (preferred) 2) Add a Gentoo patch/sed applied unless USE=vanilla (not preferred)
Regarding this post from @dilfridge http://dilfridge.blogspot.de/2012/04/neat-trick-for-testing-patches-in.html that would be an acceptable solution for me, currently doesn't work though, as the ebuild doesn't have the needed features.
Just created a small patch against the current ~arch.ebuild, according to the buildlog, the patch gets picked up and the build runs successfully. Don't know if this is the proper way to do it, all that eclass stuff makes my head dizzy...
Created attachment 309083 [details, diff] patch against the ebuild to allow user patches from /etc/portage/patches/x11-wm/fvwm/
Comment on attachment 309083 [details, diff] patch against the ebuild to allow user patches from /etc/portage/patches/x11-wm/fvwm/ epatch_user() is defined in eutils.eclass, so the inherit line is not necessary. There is pro's and con's of having epatch_user in the ebuild of course.
Everyone, take this one with a grain of salt. I am not saying {if,that} we should apply the patch, I really have no idea, nor do I care about it. But, While FVWM might run in all sort of X implementations, for now, we only have Xorg (please, correct me if I am wrong), so I wander if we should really care about any other thing that's not Xorg. Thomas Adam always asks from bug reporters that they use the latest cvs snapshot to try to reproduce the bug at hand. I think that's legitimate, but it also means there's really no point in keeping the FVWM ebuild vanilla, for any matter. On the other side, if there's only one user wanting this, I guess the patch should be kept local on his /etc/, or wherever he wants.
(In reply to comment #13) > Everyone, take this one with a grain of salt. > > I am not saying {if,that} we should apply the patch, I really have no idea, > nor do I care about it. But, > > While FVWM might run in all sort of X implementations, for now, we only have > Xorg (please, correct me if I am wrong), so I wander if we should really > care about any other thing that's not Xorg. You probably shouldn't if you can guarantee the deployment of your ebuilds is only against Gentoo, which I suppose is reasonable -- and it should be that way. But a project such as FVWM which can run atop of anything cannot afford such luxuries, so make your own patch for this. > Thomas Adam always asks from bug reporters that they use the latest cvs > snapshot to try to reproduce the bug at hand. I think that's legitimate, but > it also means there's really no point in keeping the FVWM ebuild vanilla, > for any matter. This is only so I can guarantee the code I'll be looking at is the same as the bug that's reproducible. I've had stack traces on different projects which bore no relation to the code I was debugging against simply because the damn thing had been patched -- and it gets very annoying after a while. This isn't endemic to FVWM or Gentoo or any other distribution's means of handling their packaging of programs by patching them, but taking that out of the equation by getting bugs reproduced against vanilla code is always something that's just common sense. All I ask (as I've done Debian, Arch, etc) is that if you're going to ship an ebuild of FVWM which includes third-party patches, you ensure that any bug reports you get from users, which might result in them contacting fvwm-workers@ (and this includes the ebuild maintainer or whomever is responsible for forwarding bug-reports [1]) to be verified against CVS -- and furthermore, I would also request you mark such an ebuild as completely unmaintained upstream with respect to the patches provided. If it's patched, it's then simply unsupported, AFAIAC. -- Thomas Adam [1] This is a rare occurrence among maintainers of distributions, indeed!
I support Thomas for trying to keep the problems with patches at a reasonable level and I'll happily accept, that this patch won't get accepted before any X in question is capable of doing so. On the other hand, I personally need this patch and I guess the count of others also wanting this will rise in the future instead of declining. Only thing I want, is to have the packagemanager make my life easier apply custom patches when needed and I personally prefer the "/etc/portage/patches"-way - until a few hours ago, I wasn't even aware that we apply a rather big patch by default (USE=vanilla isn't set by default, according to the ebuild). Thus I'll give my vote to modifying the ebuild, allowing users to throw patches in the corresponding directory and applying them. This way, the responsibility is in the hands of the user, Gentoo devs aren't responsible and upstream/Thomas should have a somewhat easier life. I dunno what's stand on epatch_user() is for the future, but I'll hope this will be available sometime in the future to any ebuild, which should kill a lot of discussions like this making them unneeded.
I proposed some modifications to the ebuild for 2.6.4 here, setting USE=vanilla by default, and urging people not to report bugs upstream unless they make sure the bug can be reproduced in a vanilla build: https://bugs.gentoo.org/show_bug.cgi?id=412079 Nowadays, there's only the translucent menu patch around. I don't know its current status, since I USE=vanilla myself.
+*fvwm-2.6.5 (07 Oct 2012) + + 07 Oct 2012; Pacho Ramos <pacho@gentoo.org> +fvwm-2.6.5.ebuild: + Version bump, also include a default on vanilla USE and patch to increase + maximum mouse buttons number when that USE is off, also include epatch_user as + requested, please see bugs #411811 (by avx) and #412079 (also by Jesús + Guerrero). +
