GNOME Bugzilla – Bug 143615
pressure sensitivity not functional
Last modified: 2008-04-29 15:50:06 UTC
try to draw using brush, set to to normal and with a tick box on say 'size' in pressure dialogue the brush acts as per a pencil with no pressure sensitivity. I don't know what the issue is, but this set up works fine for illustrator and painter, but not GIMP which is my preferred tool ~:"
sorry but bugzilla appears to have ignored my reference to version as: voisine gimp.app, which is the first really simple install for mac that I've found. It is excellent! but I do need pressure sensitivity. thanks!
Well, did you enable input devices in the Preferences dialog? If the Preferences say "No Input devices" then GTK+ wasn't compiled with support for XInput.
Closing as INCOMPLETE due to lack of feedback from the bug reporter.
Sven, it is ridiculous to close this bug, I did not compile the Gimp program for Mac osX I will however chase voisine, who did, and assured me it would be included in future compiles. he tried to send me a private compile, but that didn't work out.
Ridiculous?? We have asked a very simple question (comment #2) and didn't get an answer for more than three months. That is definitely reason enough to close the report.
I have today downloaded the latest version of Aaron's compile for os X http://prdownloads.sourceforge.net/gimp-app/Gimp-2.0.3-2.dmg?download unfortunately the issue remains unresolved, I am asking Aaron to confirm whether GTK+ was compiled with XInput support. He assured me that it would be, however, no input devices is the current state
So the answer is that the prefs dialog says "No Input Devices". It is certain then that this resport is not about a GIMP bug but deals with an issue in the Macintosh build. This bug tracker is about bugs in the GIMP source code though. Please settle this issue with Aaron or ask the fink and opendarwin package maintainers of the GTK+ package to add support for xinput devices.
Adding Aaron as a CC., reopening and setting to NEEDINFO again. Dave.
There is no further information needed here.
Sven, Why didn't you say this in the first place? nothing has changed afaik, you really aren't helping with this 'know it all' but "wont tell you" attitude. It is unlikely that i shall be reporting bugs in the future, as the responses are frequently unpleasant.
please leave open until we have gtk+ correctly compiled and can confirm that there isn't a problem. currently there is one.
Sorry, if GTK+ tells the Gimp that there are no input devices then there is not much we can do about this. We rely on GTK+ for the Input Device support and if it doesn't give access to them we are helpless. Thats why this bug does not belong to the GIMP product and thats why Sven closes it. That having said: Sven & Dave, you two should try to agree on a bug policy. You two fighting about the state of a bug is kind of annoying.
Your behaviour of not answering to a bug report for several months is what is unpleasant here. We have to deal with lots of bug reports. We need to draw the line. The line we have drawn is that this bug tracker is about bugs in the GIMP source code. It is by definition not about problems which only exist in a particular binary build that we don't have any control about. There is a bug tracker at sourceforge.net that you can use to report problems with the binary package that Aaron provides. We cannot do anything about this particular problem so it doesn't make sense for us to keep a bug report for it. You can easily verify if tablet support in GTK+ works as soon as it is enabled in the GTK+ build. The source code is freely available and building GTK+ and GIMP on a Mac is trivial thanks to fink and/or opendarwin. If it turns out that tablet support in GTK+ doesn't work when it is enabled in the GTK+ build, feel free to open a bug report against the GTK+ product. I will close this as NOTGNOME this time since I agree that there is a problem. The problem can however not be fixed in the GIMP tree and the package it can be fixed in doesn't exist in this bug-tracker. So the correct resolution here is NOTGNOME.
sven, the error is yours, as you should have decided this 3 months ago, and advised me, then I would have chased at GTK+, an apology is suitable I don't have the skills to build, but would be willing to if given, what are the apparently trivial instructions. For now I have decided not to bother, as you continue to be obstructive and rude
j. Please look again at the bug report. Sven asked you a question on 2004-06-02 18:23. The question is crucial to determine if the bug is in GIMP or GTK+. You did not bother to reply for more than three months: Thats why Sven closed the bug in the first place.
The bug policy was established when we added the "installers" component to bugzilla and agreed to accept installer specific bugs. As far as I'm concerned, this bug is owned by Aaron, in the same way as Win32 installer issues are owned by Jernej. As such, neither myself or Sven should be closing it. It's worth noting that Sven changed lots of bugs today, and I agree with most of those decisions. Closing a bug as incomplete is fine if there has been no feedback. However, for this bug, the original reporter came back straight away, the person most apt to answer the question was added as a CC. So stuff was happenning on this bug, and re-closing it was overly hasty. I'm re-opening and changing component to "installer", and priority to "Low". Please leave the bug open until the installer's maintainer has a chance to answer. Dave.
It is more than likely that there isn't a bug with GTK either, where to place the problem? this is as good as GTK the problem remains, open otherwise how will this ever get resolved? there is no rationale for moving to GTK until we know there is a problem with GTK, and they are bound to assert this much. please leave open, at least until Mac-Gimp has it own bugzilla thanks
I'm content, thanks dave installer is clearly the correct location for the present. no hard feelings Sven, and will chase with GTK+ if there is a bug my apologies as not aware of 'installer' option thanks again
Dave, we agreed on tracking problems with Jernej's installer here since he doesn't have his own bug tracker. The gimp.app package however does have it's own bug-tracker and I have mentioned this already. For you convenience, here's the URL: http://sourceforge.net/tracker/?group_id=104774 So, please, by all means, close this report now. I am sick of having to repeat myself over and over again. Dave, if you want to argue about this, please don't do it here.
Sven, it is a great pity that you didn't mention this 3 months ago, or as soon as you realised the issue. However I understand that you like me are busy. I am moving to gimp.app
I didn't know about the gimp.app's bug tracker. I think you're mistaken about having told me about it before. I wasn't arguing either. I don't understand why you were so eager to close the bug again after we got the feedback that you asked for, that's all.
I did compile gimp.app using configure --with-xinput, however I don't have any pressure sensitive input devices to test it. Is there any way to verify that the binary has the proper support compiled in? Next release I'll be sure to save the compile output.
Reopening to resolve correctly.
Sorry to be a nuisance, but Aaron Voisine, doesn't have the answers, and neither do I. notwithstanding that this bug was marked notGnome, I have filed a bug with GTK: http://bugzilla.gnome.org/show_bug.cgi?id=152690 Why was this bug marked NotGnome? I suggest we for the compile output from Aaron thanks
> but Aaron Voisine, doesn't have the answers, and neither do I. I don't understand this comment. So Aaron has used --with-xinput in the build of GTK+? Is that correct? Does this refer to the version that is offered at sourceforge.net or is this a new build? If so, has anyone tested this new build?
Sven, can you please just take a time-out and relax. Aaron advised me that he complied the latest version gimp.app with Xinput support. however until we have the compile output, we wont know whether this was succesful. as I already reported this build does not work. first Aaron has to build again and post the compile output, then if suitable I have to check if it works, then if it doesn't we can begin to find out why. helping Aaron to make sure that the compile is good is a great first step. thanks
I am completely relaxed. The comment you added simply didn't make any sense to me so I asked you to explain it. The explanation you have added now at least gives me a chance to guess what is going on. It still doesn't warrant this report to be reopened nor does it explain why a bug against GTK+ has been filed. The compile output won't help at all so it doesn't make sense to wait for it. What needs to be done is to test if the recompiled binary works and if the devices now show up in the preferences dialog. BTW, you did check that your X server provides the XInput extension and whether your tablet shows up as XInput device at all, didn't you?
The tablet works fine with illustrator on macOSX however that isn't using Xserver It isn't clear that Aaron compiled correctly with Xinput support, he wrote saying this himself, and he wants to see the compile output. I've already written a few times: the device does not show up, why do you insist on keeping on mentioning this? I have no idea whether X server provides the XInput extension nor whether my tablet shows up as XInput device. If you give me instructions on how to do this, which I understand, I can check. thanks
Oh well, we usually assume that people who report bugs here have done at least a minimum of research themselves. Other users seem to be able to find the information about how to setup their X server so that the tablet is available to X clients. So of course I assumed that you did some research before you opened this bug report. If it now turns out that this whole thing is just a misconfigured X server, you could have saved yourself and us a lot of time and wasted efforts. So please, grab an XInput Howto and read it. You should find that xdpyinfo can tell you whether your X server provides the XInput extension. You should also find that the xsetpointer and xinput utilities can be used to verify that the tablet is available and that it is sending events. But I guess I will better write it down for you in simple words... (1) run 'xdpyinfo | grep -i input' and look for "XInputExtension" (2) run 'xsetpointer -l' and check if tablet devices are listed (3) run 'xinput list' and look for tablet devices (4) run 'xinput test <devicename>' and check if you get any events Please consult the manpages for further information.
jayosx:~ jay$ xdpyinfo | grep -i input current input event mask: 0x1a0000 jayosx:~ jay$ I apologise for not being your dream bug reporter, however macs are popular, and especially amongst graphic artists, who don't necessarily wish to develop extreme bug skills. It appears that XInputExtension isn't provided, so it may be that I need a different X server X11 1.0 - XFree86 4.3.0 is the current version I hope you find a more able bug reporter, as I am unlikely to be able to spend much more time on this issue myself
XFree86 should provide the XInput extension. Perhaps the feature is just not enabled in your build. It's a pity that it isn't and I think you should file a bug report against the XFree86 package asking for XInput support to be added. Alternatively you could check if the X server that Apple provides has XInput support. I am now closing this report again as NOTGNOME since it is obviously not a problem that we could solve.