Why-AreWeUsing-BothDashes-And-CamelCase? It creates unnecessary ambiguous situations where you don’t know if a command is Word-Word-Word, Word-WordWord or WordWord-Word. It’s like how PHP names its primitives all over again. Both dashed-separated-commands and CamelCase commands are fine, just, why both?
Fortunately I wasn’t because I’m not in the beta program. I already would have ditched Windows if i wasn’t for needing to do school work on Microsoft Office, though I have been transitioning from Microsoft apps to open source apps on my last Windows system for a while. Soon, hopefully.
The only decent Linux app I can’t find is a note taking platform that supports drawing/handwriting with electronic styluses and has palm rejection so I can write naturally on my laptop/tablet convertible instead of trying to hold my hand above the screen. It’s the last piece of the Linux puzzle for me.
They did actually manage to ship that file-deletion bug in production. It just didn’t affect that many users, because they pulled the update a few hours later: https://news.softpedia.com/news/microsoft-explains-why-windows-10-version-1809-deleted-user-files-523152.shtml
Top tier development work right there /s
About that, hope I can help, as I use a tablet to take notes while studying from home.
I use a 10-years old wacom tablet which has three inputs (libevent on linux separates the lateral buttons, the stylus and the touch area).
I’ve disabled the touch area through my configs (I use swaywm, so I setup the input directly from its config) to avoid bumping my hand on the surface and leaving random marks.
I use xournalpp as my note-taking application and I’m very satisfied. It has some quirks from time to time (he likes to crash on one of my systems), but nothing that you can solve by saving frequently.
It’s been four months and I have no problem with my workflow. I even configured the tablet side buttons to select different tools, although from a custom script which hooks to ydotool to reproduce the key combination for each tool.
I also use Xournal++, but it doesn’t have palm rejection when drawing on a touchscreen. I could use a wacom tablet, but ideally I would like to do everything from a laptop/tablet hybrid because I need it to be as portable as possible when I’m rushing across my university’s campus (which is quite large) between classes (though this year I don’t need to worry about that because I have online classes).
huh that is different then. It really boils down to how your hardware works.
I suppose the laptop stylus works only by pressure/contact, so not like a tablet stylus. In that case, a friend of mine uses a special kind of glove that is specifically made to prevent the hand from being recognized by the touchscreen.
I could ask her later, but in the meantime I think they are called stylus gloves or something on the lines.
A touchscreen that supports active styli instead of the simple capacitive ones are pretty similar to a drawing tablet, but it does require the software to understand how it works.
Interesting, I though windows or a specific driver allowed to disable one of the input modes.
I’m not sure honestly. As far as I know, active styli touchscreens “work” in Linux, but very little software actually take advantage of it on the Linux side since it’s largely a Windows thing that was introduced with the Surface line.
I don’t have enough experience with HID device drivers or input libraries to say this with proof, but I think the underlying structure to enable that should already be in place, so it could be a matter of time for it to become “mainstream” in drawing/note taking programs.
The only deep dive I took was into libevent when trying to come up with a way to map the tablet buttons, and seeing the capacity in a wayland environment makes me think each wayland wm/dm is “stylus-ready”.
I have no clue about xorg though, so xorg-native programs might not be able to distinguish mouse/tablet/stylus in a decisive manner.