Announcement

Collapse
No announcement yet.

Wacom Tablet Support Might Be Axed From Qt 5

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Wacom Tablet Support Might Be Axed From Qt 5

    Wacom Tablet Support Might Be Axed From Qt 5

    Phoronix: Wacom Tablet Support Might Be Axed From Qt 5

    While Wacom tablets command most of the graphics tablet market-share, within the open-source Qt world it seems not many people actually care about these input devices. Wacom support -- after being pressed by many long-standing open bugs -- is being talked about for removal from Qt 5.0...

    http://www.phoronix.com/vr.php?view=MTE3OTU

  • ecloud
    replied
    Please test the 5.4 beta

    In more recent times, the Krita developers have been interacting directly with us: they reported specific bugs, and came to the 2014 Contributors' Summit to discuss them. So I have focused on getting tablet support more usable and behaving consistently across platforms for Qt 5.4. The alpha is already out, and the beta will be out soon, so I would like to suggest that anyone who notices this in time should help to test it and see if there are any more problems.

    We (Digia, now The Qt Company) already had an Intuos 3 in the office for years; later I bought a Bamboo Pen & Touch to test the touch functionality as well. Recently I have acquired two Genius tablets (since they are notorious for weird firmware): the G-Pen F610 and the 560; and Wacom has provided an Intuos Pro for testing too. I asked for one from Huion but they have not sent it yet. And my personal laptop is a Thinkpad Helix which has a Wacom stylus. So, it's now possible to test all of these on all 3 OSes (except for the Helix not running OSX, obviously). As far as I can tell, they should all be behaving much better in Qt 5.4, as long as the right drivers are installed and working, and they are configured in a usable way (you need to ensure that in-driver touch gesture recognition is disabled, especially on Linux, so that Qt can receive the individual touch points, if that's what you expect in your application; and if you remap buttons etc., it has an impact on Qt applications too, of course). You can use either evdev or wacom drivers on X11, but it works better if you use the very latest wacom driver (xf86-input-wacom 0.26 at this time), because of some bug fixes that Wacom's driver developers have done recently, and because evdev doesn't support the whole feature set.

    The bugs which we discussed at QtCS 2014 can be found here:

    https://bugreports.qt-project.org/is...20qtcs14tablet

    On top of bug fixes, perhaps the most significant new feature is that QTabletEvent has buttons now, just like QMouseEvent. So you don't have to reject tablet events just so that you can get mouse events to find out which buttons were pressed (on the stylus and on the tablet itself).

    It's still true that there are not enough people in the office testing Wacom tablets. And, I'm not an artist (well, maybe to a certain extent now and then ;-) . So we do rely on community effort to help out with that and report bugs.

    Leave a comment:


  • marcello
    replied
    Working on 5.3

    Hi guys!

    Created an account here just to tell you that wacom is now working on linux with Qt5.3. Therefore we now have wacom support on Qt5 for Linux, OSX and Windows. Go test it out!

    Leave a comment:


  • cygn
    replied
    Originally posted by bug77 View Post
    If only I wasn't using KDE...
    ...
    Hell, it should be made part of KDE anyway.
    it is:
    http://dantti.wordpress.com/2012/03/...-1-0-released/

    I've got it here default on 4.8 on fedora.

    Leave a comment:


  • Temar
    replied
    Originally posted by bug77 View Post
    If only I wasn't using KDE... It seems there are no PPAs available, you have to compile from source. Not that big of a deal, someone determined to use it will use it. But like I said, some finishing touches are still missing. Hell, it should be made part of KDE anyway.
    Is there are special reason why you want to use the gnome color management system? Why not use the one from KDE?

    For the KDE color management system, there are ubuntu packages available: http://www.ubuntuupdates.org/package...getdeb/oyranos

    Leave a comment:


  • bug77
    replied
    Originally posted by r1348 View Post
    http://projects.gnome.org/gnome-color-manager/

    Just for the sake of completion. And yes, it's in by default.
    If only I wasn't using KDE... It seems there are no PPAs available, you have to compile from source. Not that big of a deal, someone determined to use it will use it. But like I said, some finishing touches are still missing. Hell, it should be made part of KDE anyway.

    Leave a comment:


  • squirrl
    replied
    I had some major issues with the latest Ubuntu 12.04.

    MyPaint upon selecting a tool wouldn't draw.

    So I don't know if it was GTK3 or X., or Unity/compiz...

    Leave a comment:


  • r1348
    replied
    Originally posted by bug77 View Post
    Nice. It should be included by default, but it seems things have improved a lot since I have last checked.
    http://projects.gnome.org/gnome-color-manager/

    Just for the sake of completion. And yes, it's in by default.

    Leave a comment:


  • hwertz
    replied
    "Nice. It should be included by default, but it seems things have improved a lot since I have last checked. "
    Yeah. I don't care about ICC personally, but I was real surprised to see all this color management suddenly show up in the newest Ubuntu release or two. I didn't think anyone was working on it, except right in the Gimp. Then -- bam! There it is.

    As for tablet support -- it'd be a real shame to lose pressure support. But, that said, some of the Qt stuff IS quite broken -- the multitouch was causing Qt to crash every time I tried to run any X app on a remote X server -- I had to downgrade Qt for it to work. And I don't even have a single touchpad or tablet on the local or remote system in question. The number of paid Qt developers has been slashed, the remaining programmers can only do so much. If this stuff's 99% done, someone's welcome to finish it but I think disabling it until it works (if not feature-complete, at least not causing other failures) is the right thing to do.

    Leave a comment:


  • bug77
    replied
    Nice. It should be included by default, but it seems things have improved a lot since I have last checked.

    Leave a comment:

Working...
X