search

emilk / egui

egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native
https://www.egui.rs/
Apache License 2.0
22.31k stars 1.61k forks source link

Wacom Stylus Input Driver Support for content creation #2104

Open omac777 opened 2 years ago

omac777 commented 2 years ago

Content creation industy highly relies on Wacom stylus pens and graphics tablets. Currently, I am only aware of gtk4 and qt supporting wacom stylus pen and tablets. How important are these Wacom drivers? Blender, Krita, Gimp, Toonboom, Maya rely on them. Thank you for listening.

felipetesc commented 2 years ago

Hi. I'm also interested about using egui with drawing tablets, but I really think hardware drivers should be provided by the hardware manufacturer. So, I believe you should ask for Wacon, for their header files, which will be probably given as a driver.dll and a c header file, if they decide to give it at all. It would be dangerous for any of us to dwelve into the intrisic of hardware definition. That's, to have an API which abstracts Wacon from Huion is something, and to provide drivers something else. I have a Huion and I can use a pen without any trouble when I open egui.rs and I draw using the canvas sample, no extra installation was needed for egui. What did, I navigated to Huion website, downlod and installed the correct driver for my drawing display. There is also the issue that this isn't a commercial project with a lot of people, and every display needs a different driver, which will need to be tested, so it's a lot of work.

But I'm in the same page you are and I will try to use for drawing sketches and so on...

omac777 commented 2 years ago

Thank you for the prompt reply. You mentioned your canvas example is working with Huion stylus and tablet.  I think it's too quick to say "working" if all it does is pretend to be a mouse and that you press an area and it draws.  That is not the definition of a stylus and its respective api. For a more thorough reflection of a stylus api, here's QT's qtabletevent api for inspiration: https://doc.qt.io/qt-6/qtabletevent.html#details"Tablet events are similar to mouse events; for example, the x(), y(), pos(), globalX(), globalY(), and globalPos() accessors provide the cursor position, and you can see which buttons() are pressed (pressing the stylus tip against the tablet surface is equivalent to a left mouse button). But tablet events also pass through some extra information that the tablet device driver provides; for example, you might want to do subpixel rendering with higher resolution coordinates (globalPosF()), adjust color brightness based on the pressure() of the tool against the tablet surface, use different brushes depending on the type of tool in use (deviceType()), modulate the brush shape in some way according to the X-axis and Y-axis tilt of the tool with respect to the tablet surface (xTilt() and yTilt()), and use a virtual eraser instead of a brush if the user switches to the other end of a double-ended stylus (pointerType())."

GTK also has GestureStylus and PadController https://runebook.dev/en/docs/gtk/-index-#Widgets%20/%20Gestures%20and%20event%20handling https://github.com/gtk-rs/gtk4-rs/blob/309a294bcaa192cb97f1220a0a96f425abf03f93/gtk4/src/auto/gesture_stylus.rs https://github.com/gtk-rs/gtk4-rs/blob/1f0e50b53726392bc5b259d4332cb0f20dcbd4d4/gtk4/src/gesture_stylus.rsBut I fail to see where the stylus pressure level values are captured within each event.  It's honestly not straightforward to follow here.

My request was to ensure consideration for all the event details captured for stylus/table devices are not lost and do find their way within the egui event relayers and handlers, and finally can co-exist and interoperate within systems that also use QT and GTK as well.

Thank you for listening.  Cheers.

On Tuesday, October 11, 2022 at 05:57:29 p.m. EDT, FTE ***@***.***> wrote:

Hi. I'm also interested about using egui with drawing tablets, but I really think hardware drivers should be provided by the hardware manufacturer. So, I believe you should ask for Wacon, for their header files, which will be probably given as a driver.dll and a c header file, if they decide to give it at all. It would be dangerous for any of us to dwelve into the intrisic of hardware definition. That's, to have an API which abstracts Wacon from Huion is something, and to provide drivers something else. I have a Huion and I can use a pen without any trouble when I open egui.rs and I draw using the canvas sample, no extra installation was needed for egui. What did, I navigated to Huion website, downlod and install the correct driver for my drawing display. There is also the issue that this isn't a commercial project with a lot of people, and every display needs a different driver, which will need to be tested, so it's a lot of work.

But I'm in the same page you are and I will try to use for drawing sketches and so on...

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

omac777 commented 2 years ago

Crazy thought:  Could egui just borrow everything qtabletevent in its plumbing somehow?  In other words have egui call qt apis to create/capture/process qtabletevents?  Somehow meld whatever makes a QT Window and what makes an egui window into one type somehow? Qt Ritual rust bindings https://rust-qt.github.io/qt/ exist and would be a great start.  I still believe in many ways Qt Ritual is simpler to use in some ways, but lacks the depth and breadth of examples and documentation that the original QT has.  Eguis examples are impressive to see and the code is clean and concise, but the code examples are all glued together into one huge demo that isn't as easy to quickly reuse in the same way that the QT c++ project examples are. I could see the efforts of egui and Ritual merging together to come out as a stronger offering.  Qt itself supports web assembly as well.

Thank you for listening. On Thursday, October 13, 2022 at 12:04:26 a.m. EDT, David Marceau @.***> wrote:

Thank you for the prompt reply. You mentioned your canvas example is working with Huion stylus and tablet.  I think it's too quick to say "working" if all it does is pretend to be a mouse and that you press an area and it draws.  That is not the definition of a stylus and its respective api. For a more thorough reflection of a stylus api, here's QT's qtabletevent api for inspiration: https://doc.qt.io/qt-6/qtabletevent.html#details"Tablet events are similar to mouse events; for example, the x(), y(), pos(), globalX(), globalY(), and globalPos() accessors provide the cursor position, and you can see which buttons() are pressed (pressing the stylus tip against the tablet surface is equivalent to a left mouse button). But tablet events also pass through some extra information that the tablet device driver provides; for example, you might want to do subpixel rendering with higher resolution coordinates (globalPosF()), adjust color brightness based on the pressure() of the tool against the tablet surface, use different brushes depending on the type of tool in use (deviceType()), modulate the brush shape in some way according to the X-axis and Y-axis tilt of the tool with respect to the tablet surface (xTilt() and yTilt()), and use a virtual eraser instead of a brush if the user switches to the other end of a double-ended stylus (pointerType())."

GTK also has GestureStylus and PadController https://runebook.dev/en/docs/gtk/-index-#Widgets%20/%20Gestures%20and%20event%20handling https://github.com/gtk-rs/gtk4-rs/blob/309a294bcaa192cb97f1220a0a96f425abf03f93/gtk4/src/auto/gesture_stylus.rs https://github.com/gtk-rs/gtk4-rs/blob/1f0e50b53726392bc5b259d4332cb0f20dcbd4d4/gtk4/src/gesture_stylus.rsBut I fail to see where the stylus pressure level values are captured within each event.  It's honestly not straightforward to follow here.

My request was to ensure consideration for all the event details captured for stylus/table devices are not lost and do find their way within the egui event relayers and handlers, and finally can co-exist and interoperate within systems that also use QT and GTK as well.

Thank you for listening.  Cheers.

On Tuesday, October 11, 2022 at 05:57:29 p.m. EDT, FTE ***@***.***> wrote:

Hi. I'm also interested about using egui with drawing tablets, but I really think hardware drivers should be provided by the hardware manufacturer. So, I believe you should ask for Wacon, for their header files, which will be probably given as a driver.dll and a c header file, if they decide to give it at all. It would be dangerous for any of us to dwelve into the intrisic of hardware definition. That's, to have an API which abstracts Wacon from Huion is something, and to provide drivers something else. I have a Huion and I can use a pen without any trouble when I open egui.rs and I draw using the canvas sample, no extra installation was needed for egui. What did, I navigated to Huion website, downlod and install the correct driver for my drawing display. There is also the issue that this isn't a commercial project with a lot of people, and every display needs a different driver, which will need to be tested, so it's a lot of work.

But I'm in the same page you are and I will try to use for drawing sketches and so on...

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

felipetesc commented 2 years ago

You mentioned your canvas example is working with Huion stylus and tablet. I think it's too quick to say "working" if all it does is pretend to be a mouse and that you press an area and it draws.

You are correct, I can't say it's working if it only mimics the mouse. To say it works, all functionality offered by the tablet should be fully accessible, and provided by tablet itself rather than an app which mimics its functionality.

I've looked the link https://doc.qt.io/qt-6/qtabletevent.html#details"Tablet and it seems a good start point if we only want to understand how things work out all together.

I've contacted Huion and I've asked help and if they can provide their API. Why? I want to create a prototype and use Huion's functionality, exactly what you have explained after the post where I showed my misunderstanding about what 'works' really should mean.

Something came to my mind, it would be nice to have something like OpenGL, but for Tablets, that is: an abstract way to interact with all tablets. So, I though about a a collection of traits for all tablets. So, we could use egui with a single unified tablet API. I've found this links when I made a quick Google search: https://dav.lbl.gov/archive/NERSC/Software/express/help6.3/help/reference/gdapi/GDAPIdrawing.html https://books.openfl.org/openfl-developers-guide/using-the-drawing-api/advanced-use-of-the-drawing-api/

Quick seach at crates.io, 'n I found:

I think it would be really nice to offer a new crate to access all tablets functionality . And after that, to think about another module to connect this drawing tablet to egui.

felipetesc commented 2 years ago

PS: Thank you for explaining everything in the way you did.

omac777 commented 2 years ago

Thanks for reaching out.  I now have at my access an xp pen Artist 12 pro table with linux drivers installed as of this morning.On AVLinux with an intel xeon cpu.I can provide event data for what I receive from it to you at some point.  It's a good start.I'm still learning about all this myself.  Cheers. On Friday, October 14, 2022 at 05:26:58 p.m. EDT, FTE @.***> wrote:

You mentioned your canvas example is working with Huion stylus and tablet. I think it's too quick to say "working" if all it does is pretend to be a mouse and that you press an area and it draws.

You are correct, I can't say it's working if it only mimics the mouse. To say it works, all functionality offered by the tablet should be fully accessible, and provided by tablet itself rather than an app which mimics its functionality.

I've looked the link https://doc.qt.io/qt-6/qtabletevent.html#details"Tablet and it seems a good start point if we only want to understand how things work out all together.

I've contacted Huion and I've asked help and if they can provide their API. Why? I want to create a prototype and use Huion's functionality, exactly what you have explained after the post where I showed my misunderstanding about what 'works' really should mean.

Something came to my mind, it would be nice to have something like OpenGL, but for Tablets, that is: an abstract way to interact with all tablets. So, I though about a a collection of traits for all tablets. So, we could use egui with a single unified tablet API. I've found this links when I made a quick Google search: https://dav.lbl.gov/archive/NERSC/Software/express/help6.3/help/reference/gdapi/GDAPIdrawing.html https://books.openfl.org/openfl-developers-guide/using-the-drawing-api/advanced-use-of-the-drawing-api/

Quick seach at crates.io, 'n I found:

I think it would be really nice to offer a new crate to access all tablets functionality . And after that, to think about another module to connect this drawing tablet to egui.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

felipetesc commented 2 years ago

For Windows to interact with pens I've found this link:

For MacOS, this documentation seems the correct one:

Rust documentation to use tablet pc and pens for Windows at https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/UI/TabletPC/index.html

DanielJoyce commented 1 year ago

Libinput (Wayland and now X use it) will send pressure and other events from supported devices. You just need to enumerate and listen to the proper events.