First of all - do you want me to actually REPORT all the bugs I saw or mentioning it here is enough?

- On wacom intuos 3 menu with favorite brushes that should appear on "right click" it does on button set to "middle click". On a mouse though it appears on RMB as it should.

- My previouse brushes tags are there but just listed - everything is melted together, showing up all brushes. Like Artmessiah said - this is really annoying and real drawback. Specially when now icons are standarized and I have no clue what was originally with Krita and what I added from David for example. It really shouldnt loose it to make that option usable.

- OpenGL isnt working. I descibed it in detail on separate thread on subject.

- using filters in latest build krita_x64_2.7.8.20 is NOT giving me any problems.

With 2.7.8.20, I can confirm the problem with importing layers. Presses made in the explorer are registered on the canvas and it crashes Krita anyway. I also tested some filters and noted that it was filters with dialog options that crashed Krita and, even then, only if pressure sensitivity had been used. When I used my trackpad to scratch something out to test, things worked fine until I made a stroke with a stylus. The next filter crashed Krita. Filters such as invert and desaturate that don't have further options work regardless.

I also noticed that the pop-up menu's gone back to existing only when the right-mouse button is held. No problems with OpenGL here. Lastly, the canvas seems to default to wraparound mode (but without infinite tiling) before the 'w' key is ever pressed and reverts to normal after the wraparound tool has been properly started and stopped.

Hopefully, this is helpful to you.

Just mention bugs here. I'm mostly just interested in bugs with tablet handling -- though other issues can be mentioned as well.

nezumi wrote:First of all - do you want me to actually REPORT all the bugs I saw or mentioning it here is enough?
- OpenGL isnt working. I descibed it in detail on separate thread on subject.

- using filters in latest build krita_x64_2.7.8.20 is NOT giving me any problems.

The opengl code didn't change at all... And the filters crash only happens when pressing the OK button with the tablet stylus.

boudewijn wrote:The opengl code didn't change at all...

As much as I believe you - trust me it doesnt work

So i tried 2.7.8.20 on helix for a while,

opengl seems to be ok so far
filters crash if i hit the ok button with stylus, but haven't tested enough to be certain
minimizing krita, or running it alongside another program (eg chrome), causes the pc to be unresponsive and is propably restored after i put the stylus back in it's slot(maybe the wacom service stops, i don't know)
also had the canvas default in the wraparound mode, couldn't disable,

still the stylus button works as middle mouse button on canvas and right click on the rest of krita's interface

sometimes if i open helix and krita withoutt getting the stylus out, even though the stylus works fine afterwards, it won't work on the canvas (wacom tablet pc version 11-16, latest june version)

While moving the save dialog, the brush keeps painting in the background:

link

P.S.: Not sure if this is normal, but the open/save dialog window takes like 6 seconds to open.

I just hit Save As, and that sent it into one of its thrashing hard drive episodes, bringing the whole system to its knees for about 5 minutes before the save dialog opened.

The new solid backend code for discovering drives is actually supposed to prevent that from happening... Nothing changed in that code compared to the regular releases that we have on the download page. Does it happen with those as well?

Not when saving, as far as I can recall. I'll test again once I build up the nerve..

Must have been a one-off bit of weirdness, I just tried again and it went to the save dialog without all the fuss. Now it takes several seconds first time after opening Krita, with subsequent times being around a second.

Edit: Still happens when selecting the Text tool though.

Hi, All!

We have prepared an updated package which *might probably* fix the offset Bug #298144 for many people using Cintiq and Intuos4. We have no such hardware, so we need testing!

Here is the package:
http://www.valdyas.org/~boud/krita_x64_2.7.8.21.msi

If this fixes your offset bug, please tell us
If it doesn't fix the bug, please report us the following debugging information:

1) Calibrate your screen, so that the cursor appears with some offset from the stylus
2) Open DebugView (http://technet.microsoft.com/en-us/sysi ... 10%29.aspx)
3) Start Krita
4) Press Ctrl+Shift+T to start logging of the tablet events
5) Paint (note whether the offset in Krita is the same as in other applications)
6) And then save the resulting log here

If you have a bit of time, please also prepare the same log with the tablet calibration reset to defaults.

Just tried krita 2.7.8.21 with a win7 64bit pc hooked up with an intuos 4 and when krita opens there is no canvas, only the gray background in the work area. Plus, there is no pointer indication when hovering above work area with either mouse or intuos.
i can post log if you like, but it will be a long post. (Is there some kind of spoiler function or attachment, so i can keep this post short? soz, can't find it)

Hm, no, that doesn't sound to useful. You must have run into some other problem. However, on the linked bug report stipend reports that for him the offset is indeed gone. Now all we have to do is fix the issue with dialogs (crashing or painting underneath) and we should be able to merge and create a new installer for real.

boudewijn wrote:Hm, no, that doesn't sound to useful. You must have run into some other problem. However, on the linked bug report stipend reports that for him the offset is indeed gone. Now all we have to do is fix the issue with dialogs (crashing or painting underneath) and we should be able to merge and create a new installer for real.

Hi Boudewijn,
The offset only appears gone when calibration is reset and prompts to calibrate are ignored.
When calibrated there's still an offset, it's just in the opposite direction now as indicated by comment #41. (sorry)