[HN Gopher] Show HN: Wavvy - web-based audio editor (Audacity port)
___________________________________________________________________
Show HN: Wavvy - web-based audio editor (Audacity port)
I originally developed a WASM port of wxWidgets for
https://dj.app/. When it came time to open source wxWidgets-wasm, I
decided to port another complex app as a test case, and Audacity
seemed like the obvious choice. In the process, I also needed to
write a new host API for PortAudio for playback and recording in
the browser. https://github.com/ahilss/wxWidgets-wasm
https://github.com/ahilss/portaudio-wasm
https://github.com/ahilss/wavvy
Author : ahilss
Score : 491 points
Date : 2022-09-02 09:31 UTC (1 days ago)
(HTM) web link (wavvy.app)
(TXT) w3m dump (wavvy.app)
| paskozdilar wrote:
| This is so awesome :)
| ilitirit wrote:
| > Audacity seemed like the obvious choice
|
| Tangential question, but why did Audacity seem like the obvious
| choice? Not a knock on the product - I use it often - but I'm
| just curious about why it was chosen.
| samwillis wrote:
| Audacity is one of the largest (if not the largest?) still
| active projects using wxWidgets, it seems like fairly obvious
| if you are somewhat aware of that.
| tambourine_man wrote:
| Why did wxWidgets fell out of favor?
| samwillis wrote:
| I don't think it did, the world just moved to mobile and
| web based apps, then backward towards the desktop with
| Electron.
|
| I would say wxWidget and QT are probably still the most
| used cross platform desktop GUI toolkits.
| ekianjo wrote:
| Not used much anywhere.
| klodolph wrote:
| I think there were some problems with wxWidgets and
| generally people moved to Qt, if they were still making
| cross-platform desktop apps, and if they haven't migrated
| to Electron.
| ahilss wrote:
| It's probably the most visible project using the wxWidgets
| framework and in the audio domain which fits well with my
| experience building the DJ app.
| paulgb wrote:
| Cool! The UI even works on iPhone (alas, playback doesn't work,
| so my dreams of multitrack audio editing with just my thumbs are
| dashed /s)
|
| I'm curious what porting wxwidgets involved -- are you rendering
| them with the 2D canvas API, WebGL, or is all the rendering done
| by WxWidgets and you just have to send a framebuffer into a
| canvas?
| samwillis wrote:
| Not the OP, but taking a look at the DOM, it's rendering each
| "window" as a canvas. So you have a main window canvas, then
| canvases for popup menus, message boxes etc. All canvases are
| using a 2d context, and there are many offscreen canvases
| created for each interaction for each widget which I assume are
| then composited to the window canvases.
|
| It's an amazing project! If the OP is here, do you have any
| plans for accessibility to screen readers? I suppose it's a
| similar problem to that with Flutter.
|
| I also wander if there is a possibility to combine your
| wxWidget port with the work going into WASM Python...
|
| Edit:
|
| Taking a closer looks at how the wxWidget port works, wxWidgets
| has multiple backends using native widgets on each platform.
| They also have wxUniversal which draws each widget itself to a
| frame buffer, this port uses that as a base to draw the ui to
| html canvases.
| tobsterius wrote:
| Doesn't the iOS version of GarageBand allow for multi-track
| editing?
| ahilss wrote:
| It is rendering using the 2D canvas API. There's a device
| context class (wxDC) for each wxWidgets port that implements
| primitive drawing ops (DrawLine, DrawText, etc). For the WASM
| port, I created a glue library in javascript [1] that wxDC
| calls into for each primitive.
|
| [1] https://github.com/ahilss/wxWidgets-
| wasm/blob/master/build/w...
| squeaky-clean wrote:
| Wow, it loads so quickly for me.
| chaosprint wrote:
| Very impressive work! I tried to play some loops and add some
| effects. They all went well. Did you manually handle the audio or
| is it wrapped in the portaudio-wasm?
|
| One thing I can learn from your work is to how the canvas is
| rendered. For my project Glicol (https://glicol.org) I use the
| Web Audio Analyser Node for visualisation but I am considering to
| use SAB to send even non-audio channels and render the canvas in
| real-time. It would be great to explore the process if you can
| write more on your GH repo.
| ycombinete wrote:
| Is there a way to record the output audio? Audacity on windows
| has the WASAPI option, which my wife has to use a lot.
| mkl wrote:
| Is File > Export not suitable? And if WASAPI can be used with
| your browser, won't it work for this? I don't really understand
| the use case though.
| ycombinete wrote:
| I mean record system output audio. E.g. audio streamed to
| speakers. Desktop Audacity can capture this audio directly on
| Windows. The specific use case is extracting the audio from
| long videos, to upload to a transcription service.
|
| It's an edge case for sure. Since the video is hosted weirdly
| and no video downloaders I've tried can get the video
| downloaded _with_ the audio.
|
| So we simply stream the video normally in the browser, and
| capture the audio output directly into Audacity.
| mkl wrote:
| Oh, I see, WASAPI as Audacity's input not output. Setting
| up a virtual microphone with something like VoiceMeeter
| might do it, since the browser would just see it as a
| microphone.
| ycombinete wrote:
| Oh, that looks promising! Thank you.
| pippy360 wrote:
| Can you comment on how difficult this was? and how much time it
| took?
|
| I've thought about doing something similar with some open source
| games but have just never had the time.
|
| The work is fantastic! I hope you enjoyed making it!
| jbverschoor wrote:
| I feel so productive with this 90s type UI, and crisp mouse
| pointer
| shaicoleman wrote:
| For me it plays back audio during recording, causing audio
| feedback screeches
| squarefoot wrote:
| I'm generally against web apps, but have to admit this one is
| really cool; it also loads surprisingly fast. So far the only
| difference with the original seems the waveform display which
| uses a smaller resolution, probably not to slow down too much the
| UI.
| miduil wrote:
| OMG, finally a audacity version that won't crash my Wayland
| window manager. Unfortunately the recorded audio is really weird.
| Basically it tunes down the audio once I'm speaking, maybe some
| weird autogain racecondition between PulseAudio/Pipewire and
| Firefox?
| handelaar wrote:
| Sounds a _lot_ more like playing 44.1kHz audio through a 48kHz
| device
| miduil wrote:
| You are right, that might be it. I've tried setting all the
| preferences I could find to 44.1kHz though it's still the
| same.
| tambourine_man wrote:
| This is amazing. I'm sure many HN would appreciate an in depth
| exploration of the porting process.
| poisonarena wrote:
| its crazy how this works better in my browser than on my macbook
| air M1
| arendtio wrote:
| I like this very much, especially because I love Audacity, but
| lately Audacity seems to be somewhat buggy as a native app on
| (Arch) Linux. With some versions I had rendering problems and
| buttons that didn't work (probably related to the widgets), with
| other version the whole sound system didn't work.
| bluelightning2k wrote:
| This seems like a really impressive technical work. Well done!
| I'd be interested in a write up of the process
| stjohnswarts wrote:
| Me too. Maybe just a blog post with the big details and some
| lessons learned. I tried a Qt app once to wasm. and it was just
| painfully slow and so buggy when I got done (mostly just
| unexplained crashes). I'm no pro though, it was just a weekend
| project.
| chaosprint wrote:
| impressive.
|
| everything looks very smooth.
|
| did you manually manage the sharedarraybuffer?
| ycuser2 wrote:
| Wow! It feels like the native app.
| qolop wrote:
| Are there terminal based keyboard first audio/video editors? Sort
| of like vim but for multimedia.
| radarsat1 wrote:
| probably not what you're looking for but you might enjoy
| reading about Snd if you're not familiar [0].
|
| side note, such a fun list of abandoned projects here [1] and
| here [2] to browse through.. many sadly broken links but i
| remember checking some of them out back in the day. there was
| so much activity in the open source audio sphere back in the
| early 2000s.
|
| [0]: https://ccrma.stanford.edu/software/snd/snd/snd.html
|
| [1]: http://www.linux-sound.org/one-page.html
|
| [2]: https://wiki.linuxaudio.org/apps/daw_apps
| elevaet wrote:
| Bravo! This is fantastic!
|
| I was excited to see Dr. Jeep's Hardcore mix of Dissociate in the
| default library for dj.app - that's been my jam lately, really
| niche track to come across in the wild :)
| alkonaut wrote:
| What other options exist for "complex native-ish browser
| interfaces" in this style? E.g. if you wanted to develop a new
| app which is a traditional desktop GUI app with tons of menus and
| buttons that need to be custom rendered (so wasm/canvases
| presumably, rather than html), what options exist aside from this
| effort with wxWidgets?
|
| For example, say you wanted to make a 3D editor/CAD program or
| full-featured DAW from scratch - what would you use?
| chaosprint wrote:
| I will use rust egui
| squarefoot wrote:
| Not a popular language/RAD these days, but I wouldn't rule out
| Lazarus/FPC.
|
| https://github.com/zamtmn/zcad
| https://wiki.freepascal.org/Projects_using_Free_Pascal
| badsectoracula wrote:
| Note that Lazarus isn't (yet) able to do web-based GUIs. Free
| Pascal only just added wasm support (not in a release yet,
| but it is part of the main branch), so all is needed (which
| TBH is kind of a big "all" :-P) is someone to make an LCL
| backend for it, so it might happen at some point.
| kethinov wrote:
| Now we just need to wrap this in Electron so we can run it on
| desktop! ;)
| [deleted]
| seydor wrote:
| Nah, we ll just run it remotely through Mighty app
| highwind wrote:
| Relevant talk: https://www.destroyallsoftware.com/talks/the-
| birth-and-death...
| pinato wrote:
| Thanks for the link, very good talk.
| jijji wrote:
| The OP mentioned this is a part of Audacity, so hopefully you
| were being sarcastic, but you can already do apt install
| audacity if you want a desktop app, as it already exists in the
| form of Audacity
| naikrovek wrote:
| you missed that it was a joke, it seems. a sad, realistic
| joke that makes me weep, instead of laugh.
| zeandcode wrote:
| This can't be better, another level
| cush wrote:
| No, Tauri!
| hrdwdmrbl wrote:
| A cheap way to do it is to use Nativefier. It's not perfect but
| it's like a 80% solution.
| xd1936 wrote:
| I think this was tongue-in-cheek. Nobody would actually want
| to take a native C/C++ Audacity, port it to WASM, and then
| wrap it in Electron to make it a "desktop app" again.
| sitkack wrote:
| It would give you safety properties that native Audacity
| doesn't have. It would also make distribution much easier.
| lelanthran wrote:
| > It would give you safety properties that native
| Audacity doesn't have. It would also make distribution
| much easier.
|
| Has Audacity ever had safety issues in the past?
|
| Because it sounds like you'll be going to a lot of effort
| to prevent a problem that had never surfaced in over a
| decade of use.
| dspillett wrote:
| Not the sort of safety issues I think you mean, but there
| have been some rather questionable behaviours from the
| current owners in the last year or so. A quick search for
| Audacity here or elsewhere will find the details.
| mb7733 wrote:
| I'll save everyone the quick search. They added really
| basic opt-in telemetry, and then removed it after an out-
| of-proportion outcry.
| swyx wrote:
| i dont understand privacy maniacs. have telemetry in from
| the start, nobody bats an eye. add it later, everyone
| freaks.
| tuckerpo wrote:
| especially if it's opt-in (which is provable since the
| project is entirely open-source) -- can people simply
| _not_ opt-in if they disagree with telemetry?
| eurasiantiger wrote:
| In the first case, intentions are clear from the start,
| so user trust can be built.
|
| In the second case, intentions have been hidden or they
| have changed, which obviously erodes user trust.
| [deleted]
| hutzlibu wrote:
| Simple, privacy "maniacs" do not install something with
| telemetry integrated by default.
|
| So of course they freak, when it is suddenly creeping in,
| in something they trusted.
| robocat wrote:
| Good write-up here:
| https://arstechnica.com/gadgets/2021/07/no-open-source-
| audac...
|
| It wasn't clear it was opt-in (although maybe the code
| was clear?).
|
| Either way, adding telemetry (especially to open source)
| is obviously going to cause a ruckus, so they obviously
| mishandled the situation.
| sitkack wrote:
| Audacity segfaults all the time when I use it. Don't make
| it sound like it is more stable than it really is.
| Security bugs are a subset of bugs, of which Audacity has
| many.
| ahilss wrote:
| On the M1 Mac I actually measured lower CPU usage during
| audio playback on WASM compared to the native desktop
| version which uses Rosetta. I'm not sure if the slowness is
| due to Rosetta or a performance bug on the Mac port.
| 0xedd wrote:
| Niche hardware popular in the US alone? Mild shock.
| codetrotter wrote:
| Supposedly[1], Audacity 3.2.0 will be available as an M1
| native app.
|
| Guess we'll see then :)
|
| [1]: https://forum.audacityteam.org/viewtopic.php?f=47&t=
| 114242&s...
| r4vik wrote:
| also it would let you have a common target (wasm) for
| plugins so it doesn't matter if you're running on ARM/x86
| thement_ wrote:
| Very well done! Thanks!
| swyx wrote:
| i use Audacity -daily- for my podcast mixtape. its a bit buggy,
| occasionally crashes, and i have to reboot it everytime i plug
| in/out a different mic. hoping this solves my problems!
| tgv wrote:
| Wow. How much work was the porting of audicity? It seems there's
| no commit history for wavvy.
| antoineMoPa wrote:
| This is awesome, and also awesome is this:
|
| > I originally developed a WASM port of wxWidgets
|
| I had some fun looking at the commits here[1] and I can imagine a
| lot of classic wxWidgets apps are going to be ported to wasm now.
| Congrats, that a lot of dedication!
|
| [1]
| https://github.com/wxWidgets/wxWidgets/compare/master...ahil...
| ClawsOnPaws wrote:
| I feel like I should preemptively apologize and I'm really not
| trying to knock the project in any way, and the achievement is
| pretty epic, but those who have seen my username on this site
| before know what's coming, especially in regards to people
| seriously considering using WX Widgets on the web... This app
| is inaccessible. Audacity on its own is already a bit difficult
| to use with a screen reader, but sadly, this port,
| unsurprisingly, is even worse. I've managed to at least explore
| some of the UI using OCR, but it was very cumbersome and I
| could never get it to do what I wanted. Just uttering my
| careful warning that you should please, please, please think 3,
| 4, 5 times before deciding to actually use this UI library for
| serious projects. The benefits of using what the browser
| already gives you is that, if you're not going too crazy,
| accessibility comes for free and there's very little you need
| to do to make sure that we can still use your app. Again, I
| understand that this is a port of Audacity, and I believe that
| what we can do in browsers is pretty amazing and my aim is not
| to discourage anyone from trying out new things. I'm just
| saying that this app is 100% screen reader inaccessible so
| please make sure you have a valid reason for keeping out users
| with disabilities (hint, you almost never do) by using WX
| widgets drawn directly to a canvas. And if you do, please think
| hard about what you can do to still keep your app accessible.
| I'm sure there are ways to add accessibility to a web port of
| WX, but if you can, sticking with the things the browsers give
| you is usually the better idea.
| ivraatiems wrote:
| I so frequently see this tone with accessibility discussions:
| "X is not accessible, so don't use it, stop what you're
| doing, this is bad." I don't think that kind of scolding -
| which is what it comes off as - is productive for solving the
| problem of "X is not accessible", because it presumes the
| problem is unfixable. I believe you wrote your comment in
| good faith, and I agree accessibility is important. But I
| think you should consider focusing on this:
|
| > I'm sure there are ways to add accessibility to a web port
| of WX
|
| and not
|
| > Just uttering my careful warning that you should please,
| please, please think 3, 4, 5 times before deciding to
| actually use this UI library for serious projects.
|
| because, as you acknowledge, this is a hobby project. The
| goal is to do something cool and fun and push boundaries of
| what's possible. So if pushing accessibility for all web apps
| is your goal, why not seize this moment to say "hey let's
| find ways to make WASM apps more accessible" rather than
| saying "nobody should use this for serious projects"? Why not
| try to fix it rather than shutting it down? Doesn't it
| benefit people more if we find a way to make accessibility
| _easy_ , rather than discouraging people because it's hard?
|
| There are lots of cool and interesting technical problems in
| there that somebody who takes the time to make something like
| this could have interest in: How do OCR or other
| accessibility tools understand canvasses? How can we
| communicate with them? What addons to WASM or wxWidgets would
| achieve this goal?
| mwcampbell wrote:
| > I don't think that kind of scolding - which is what it
| comes off as - is productive for solving the problem of "X
| is not accessible", because it presumes the problem is
| unfixable.
|
| Of course the problem is fixable. But in the meantime,
| until it's fixed, a disabled person could fail to get a
| particular job, or even lose a job they already have, due
| to an inaccessible application. It's important to remember
| that the stakes are really that high. If we want to prevent
| that from happening, I think it's worthwhile to try to
| persuade application developers to not use inaccessible GUI
| toolkits, particularly for new projects. We can do that at
| the same time that we work on making more GUIs accessible.
| ivraatiems wrote:
| > I think it's worthwhile to try to persuade application
| developers to not use inaccessible GUI toolkits,
| particularly for new projects. We can do that at the same
| time that we work on making more GUIs accessible.
|
| Can we? People don't typically work on tools they don't
| intend to use. Where are the people doing the fixing
| going to come from if the conventional wisdom is "even if
| you use this for a side project, you're harming disabled
| people?"
|
| Another way of framing your suggestion here is that
| toolkits with the resources to make themselves accessible
| without community help will always dominate toolkits that
| don't have those resources. That stifles progress for
| anyone.
|
| > But in the meantime, until it's fixed, a disabled
| person could fail to get a particular job, or even lose a
| job they already have, due to an inaccessible
| application.
|
| This kind of stake-raising honestly feels toxic to me,
| sometimes. You can make the same argument about almost
| anything. Eventually, you're going to get tuned out,
| because the knee-jerk reaction expressed to any new
| project is "well, you didn't do thing X I wanted, so I
| refuse to care even if the project has merit."
|
| What's wrong with saying "hey, this is cool, but be aware
| if you wanna use wxWidgets for production app, know it's
| inaccessible and so you'll have more work to do to make
| your app accessible, which I assume you want to do,
| because it's the right (and often profitable!) thing to
| do"?
|
| Why do we have to escalate it to "If you make side
| projects with wxWidgets, you're encouraging people to use
| them for production apps and therefore causing disabled
| people to lose their jobs"? It's purposefully taking
| everything in the most negative way possible.
|
| Put another way, how is your argument distinct from the
| following: "Working on Audacity, a project for audio,
| privileges hearing people over Deaf people, and therefore
| could deprive Deaf people of programming jobs would go to
| text-based projects if there were fewer commercial audio
| engineering products helping people to replace text
| resources (blogs, etc.) with audio (podcasts, etc.).
| Therefore, Audacity is harmful and one should not work on
| it."
| Eduard wrote:
| > I so frequently see this tone with accessibility
| discussions: "X is not accessible, so don't use it, stop
| what you're doing, this is bad."
|
| 'Don't use X for reasons ABC' is a great advice! Why use
| unusable X if some other thing Y works?
|
| Have you tried using Wavvy on a smartphone? Guess what:
| it's effectively unusable on smartphones: - touch events
| aren't leveraged. - hover and right click aren't available,
| and keyboard shortcuts don't have an appropriate
| substitute; therefore core audio editing tasks cannot be
| accomplished in any acceptable manner.
|
| If you are accustomed as I am to use Audacity on a desktop
| PC - clicking, cutting, shortcutting your sound files
| effortlessly - but then use Wavvy for the first time, you
| gonna feel...
|
| disabled.
|
| And that's only a glimpse into what the experience must be
| for a blind person using Wavvy. Here is an experiment:
| Close your eyes, use Wavvy. Only OCR allowed...
|
| Being an awesome POC, the accessibility issues aren't
| Wavvy's "fault", but wxwidget's (and Audacity's by
| depending on wxwidget).
|
| Considering audio is especially valuable for visually
| impaired people, having a usable audio editor is very
| valuable.
|
| Now imagine, as it's so often the case in IT, everybody
| jumps on the latest bandwagon ("Docker all the things!",
| "Electron all the things!"), and suddenly everybody "WASM-
| canvases all the things!".
|
| Now imagine Audacity decides "WASM-canvas" is the way to go
| for Audacity distribution; no more separate builds for
| Windows, Linux, macOS, just one WASM-canvas build.
|
| And so do other software projects. And so does your company
| with its IT department software contribution... more and
| more, you cannot do your tasks the way you used to...
|
| Back to the comment: constructive critique is always
| helpful:
|
| - It helps Wavvy to consider using an alternative audio
| editor. - It helps Audacity to improve their usability and
| accessibility and consider another widget provider. - It
| helps wxwidget to fix their accessibility shortcomings.
|
| We discuss problematic tools, libraries, websites, and
| services all the time at HN - be it for privacy concerns,
| performance issues and whatnot. We all learn from that why
| e.g. having a slice of privacy is also a good thing for us
| personally. So is accessibility, even when it's just the
| slices involving good layouts, readable fonts, unconfusing
| button naming, logical tabbing order, consistent shortcuts
| across applications, big-enough advertising close buttons,
| unfrustating timepickers... , ..., ...
|
| > I don't think that kind of scolding - which is what it
| comes off as - is productive for solving the problem of "X
| is not accessible"...
|
| ClawsOnPaws is neither scolding, nor is it coming off as it
| for me. They apologize upfront, says "please, please,
| please", says "my aim is not to discourage anyone from
| trying out new things".
|
| If there was one polite, constructive comment at HN it be
| it.
|
| > ...because it presumes the problem is unfixable.
|
| I don't understand how you came to the conclusion that this
| was even remotely implied.
|
| > But I think you should consider focusing on this: "I'm
| sure there are ways to add accessibility to a web port of
| WX"
|
| I think you should consider focusing on this: "I'm sure
| wxwidgets could follow basic accessibility best practices
| and leverage accessibility APIs which are provided by
| operating systems already for years."
|
| > why not seize this moment to say "hey let's find ways to
| make WASM apps more accessible"
|
| I'm not an WASM expert, but I'm versed in accessibility
| features specified by W3C and implemented in browsers. As
| WASM can interact with Javascript, and Javascript allows
| all kinds of web accessibility standards interactions, this
| part is solved. What's required then is a mapping from OS
| accessibility calls (wxwidgets' duty) to browserland
| (WASM's side). I don't know about WASM's status here, but
| wxwidgets will have to make its own first step. ...
|
| ClawsOnPaws' comment is a tangent comment on an important
| aspect of any application: usability. It gives awesome
| insights about why Wavvy is unusable for visually-impaired
| users.
|
| - I learned that Audacity has its own problems with
| accessibility; - I learned that Audacity uses wxWidgets,
| which especially is bad when it comes to accessibility.
| That already is great to know, as I'm now informed to avoid
| it in my projects - with bad accessibility always comes a
| generally bad usability. - Now port this to the web as in
| the currently presented Wavvy form and you get a hilarious
| clusterfuck of inaccessibility. I learned from the comment
| that usability by default and without explicit
| consideration just degrates with each layer added and each
| porting. - useful information that there exists some OCR
| software for what's currently shown on the screen.
|
| In essence, ClawsOnPaws' comment has everything in it for
| why I come to Hacker News.
| ivraatiems wrote:
| I don't have time now to reply to everything in here;
| there's a lot. But I did want to mention that I posted
| some thoughts about WASM accessibility here:
| https://news.ycombinator.com/context?id=32697514 which
| are hopefully valuable in terms of how the problem could
| be solved without rewriting a given target application.
|
| With regards to the rest, suffice it to say that I don't
| find the slippery slope argument persuasive. Given,
| though, that we're mostly arguing about how to approach
| doing the thing we both agree should be done, figured I
| might try and think about things that actually achieve
| the goal instead.
| antoineMoPa wrote:
| Actually, that's a good thing to keep in mind. I would not
| use this for anything serious right now, unless for some
| reason it perfectly fits all requirements one might have. I
| see this as useful more for fun side projects and as another
| commenter said, it's possible to improve accessibility later.
| Maybe text could be rendered as actual text over the canvas?
| melony wrote:
| Why don't you spend some time harangueing browser and other
| big tech engineers instead of blaming application developers
| at every turn? The tools we use are ultimately determined by
| the companies that make them. Complete GUI toolkits are some
| of the most expensive software to build. We are limited by
| whatever's out there. The fact that HTML is a poor framework
| for rich application development is no fault of your average
| software engineer. If you want to blame someone, blame
| upstream and the product managers who run the browser
| engineering projects.
| tssva wrote:
| Unless you have a legal requirement to provide accessibility,
| I encourage everyone to ignore this advice. It is basically
| letting perfect be the enemy of good. Especially if your
| project is opensource. Someone that cares, which may even be
| you at a later date when other things on the to-do list are
| done, can submit patches to address accessibility later.
| HenrikB wrote:
| > ... can submit patches to address accessibility later.
|
| I'm not experienced with accessibility, but I pay attention
| to it whenever I can to increase my own awareness. A very
| common feedback when it fails (e.g. in software, online
| conferences, ...) is: "Accessibility must be part of the
| plan from early on. Trying to add it afterwards basically
| always fails."
| Eduard wrote:
| Brace yourself: the "European accessibility act" will soon
| make accessibility a legal requirement to the private
| sector, including computers, operating systems,
| smartphones, and e-commerce.
|
| https://ec.europa.eu/social/main.jsp?catId=1202
|
| Have your popcorn ready to watch how this will freak out
| plenty of big corporations, rushing to fix their products,
| services, and websites from their accessibility "short-
| sightedness" of times past.
|
| Depending on circumstances, failing to comply may cause
| heavy fines and having the product removed from market.
|
| My guess is this show will peak in 2025.
| tssva wrote:
| I just read it and the requirement for computers applies
| to hardware and operating systems. Ecommerce sites are
| covered but website and mobile app requirements beyond
| that apply to communication, transportation and public
| sector systems. The vast majority of private sector
| systems will still not have a legal accessibility
| requirement.
| mwcampbell wrote:
| > I feel like I should preemptively apologize
|
| You should not. A mentor once told me that we disabled people
| tend to apologize too much. You are right to point out the
| problem of accessibility in this context, despite the
| negative responses you've received.
|
| Of all the GUI toolkits with wasm ports, IMO wx is the most
| amenable to using native HTML controls rather than doing
| everything with canvas. I'm sure that kind of port would take
| more work though.
| ivraatiems wrote:
| I've seen this discussion happen before and the same
| problem be pointed out re: WASM and canvas[1]. (I'm sure
| there are more examples than just that.) The trouble is
| that Canvas exists for a good reason: It is much more time-
| intensive to re-implement something like Audacity in the
| DOM than it is to render Audacity to a canvas.
|
| So if we wanted to spend the time, could we be over-
| focusing on "just manipulate the DOM" as a solution? WASM
| conceives of the web browser as the "OS", or at least as
| hardware, and JavaScript as a means to manipulate that
| "hardware" (ask the browser to do things). Most operating
| systems expose APIs that let you do accessible things (read
| the screen, automate UI actions, etc.). Then frameworks
| like QT, for example, hook into those APIs from their own
| code to provide generic accessibility regardless of OS.[2]
|
| So, maybe one half of the solution here is that to try to
| develop a neutral API WASM can use to emit accessibility
| information which can then be read by JavaScript running in
| the browser, and transformed into objects in the DOM? Then
| you could write an interface to that from your framework
| (something like QT would be a better starting point than
| wxWidgets, though, admittedly) and you'd get what you need.
|
| Not that any of that is easy. But it would be fun, and
| naively, seems not too much harder than "rewrite app X in
| WASM to use the DOM" for much broader impact.
|
| Maybe this discussion already happened and there are very
| good reasons not to do this - but I couldn't find anything
| about it in previous arguments.
|
| [1] https://news.ycombinator.com/item?id=17349170 [2]
| https://doc.qt.io/qt-6/accessible.html
| itsagavin wrote:
| Accessibility is great but its hardly humanity's goal. In
| most instances your burden is no one else's unless we are
| talking life or death.
| Eduard wrote:
| "Allowing people to participate in society is great but
| hardly humanity's goal."
|
| Not only does your comment show ignorance of a significant
| percentage of humans, it also shows you have zero idea of
| the fact that good accessibility provides service to
| everyone.
|
| Have you ever struggled to use your smartphone while
| driving (temporary blindness, because your eyes are focused
| on the street),
|
| or pressed the wrong button while sitting in a bumpy,
| shaking bus, because the button you actually wanted to
| press was way too small (temporary hand coordination
| disability)?
|
| Accessibility's best practices also exist for everyone to
| enjoy a great usability.
| itsagavin wrote:
| Lol what? No you are right struggling to use your smart
| phone while driving and simultaneously being blinded by
| the sun are one of humanities great struggles. Let's get
| real accessibility has and will always take a back seat
| to innovation unless the innovator is in some way also
| disabled. You can always circle back around but no
| disabled person has any right to talk down to someone
| else because they weren't a first consideration.
| greggman3 wrote:
| It's not just accessabilty, nothing but English works. Even
| the keyboard doesn't work as it's hardcoded to keycodes so
| click the top of the track and click "Name..." and try to
| enter e and nope let alone Yin
|
| I'm not trying to knock the app or the work put into
| wxWidgets. But, we need to not regress in supporting the
| entire world and not just the English speaking subset. I
| don't really want to go back to the 80s/90s. I like that in
| general, with HTML, international text input/editing just
| works.
| pseudalopex wrote:
| Other wxWidgets apps don't have this problem.
| suby wrote:
| I feel like it should be possible to build a universal
| accessibility tool using machine learning that relies on
| vision rather than native framework UI/toolkit support. The
| problem seems much more tractable than other AI projects like
| self-driving cars, and also more in the realm of existing
| successes that we've already seen with machine learning. The
| problem of inaccessible apps will only get worse as wasm
| becomes more mature, I feel like the only way to win is to
| sidestep the problem.
| lukasb wrote:
| I'm surprised at the pushback against ClawsOnPaws here. Why
| would you not want to make your apps usable by as many people
| as possible?
| tuckerpo wrote:
| I'd be interested to see the man-hours-needed : people-
| helped ratio when it comes to user accessibility. There's
| certainly a threshold where it simply doesn't make sense to
| put in a man year's worth of work to cater to a
| proportionally very small percentage of the population.
| dark-star wrote:
| With this same argument, could we please also stop
| catering to the "special needs" of the LGBTQ+ community?
| That also affects only a tiny fraction of the population,
| yet everyone has to live with huge dropdown lists for 25
| genders, web forms that ask for "pronouns", and (e.g. in
| Germany) the "gendering" of every single word?
|
| /S
| xnxn wrote:
| I'd like to politely challenge your assumption that
| accessibility concerns are relevant only to a
| "proportionally very small percentage of the population".
| It's a common myth in this space.
|
| Disabled people represent between 10% and 20% of the
| world population, and that's not even including those who
| don't identify as disabled but would nevertheless benefit
| from more accessible technology. If you've ever adjusted
| the text size in your browser or enabled captions while
| watching media, this group includes you.
| naet wrote:
| This may sound insensitive, but accessibility isn't usually
| the #1 concern when developing new projects. It is usually
| tacked on later in an update because it isn't a core feature
| and it affects only a small subset of users.
|
| Rather than encourage everyone to never use WX widgets for
| any reason in a website, maybe you should be encouraging
| people (or working yourself) to add this accessibility
| feature.
| hutzlibu wrote:
| ". It is usually tacked on later in an update because it
| isn't a core feature and it affects only a small subset of
| users"
|
| But thats not optimal, right? But most do not care, as long
| as they are not part if that subset.
|
| I mean, I find it hard to care too much either, when my
| main concern are all the missing and buggy features, that
| needs fixing first..
| km3r wrote:
| Accessibility, like globalization, expands your market,
| and should be part of a long term strategy. But when
| building out new projects, its severely slows down
| feature development. Both should be seen as tech debt,
| but tech debt is not evil, just like debt is not even.
| You are borrowing from the future for present day
| benefits. Used wisely and you can create a successful
| project that can afford to spend time on accessibility.
| Waste too much time on accessibility to start and you may
| burn through all your resources before seeing any
| success.
| hutzlibu wrote:
| I mainly agree, but does the numbers of blind people
| really justify it economic wise?
|
| I allmost see accessibility as charity. I want to add it
| to my apps, mainly because it is not nice to ignore
| people needs(and who know, with bad luck I might end up
| in that group one day), but not because I expect great
| monetary returns.
| aaaaaasss wrote:
| DustinBrett wrote:
| Awesome work, I love these kinds of ports! As someone working on
| a desktop environment in the browser, it's great seeing more apps
| coming to the browser.
| fareesh wrote:
| I recently needed a crop component that allowed my users to
| record something and trim it to their desired size. I ended up
| using wavesurfer.js with the regions plugin. It seems like there
| are very few components that meet this type of requirement.
| smrtinsert wrote:
| Feels very similar to the real app. Zooming in with key macros
| isn't as accurate for some reason. Blown away by wasm. Truly the
| next frontier.
| futhey wrote:
| This is amazing work. Very well done. Congrats on the launch!
| flanbiscuit wrote:
| This is awesome! Bookmarking this for sure!
|
| I really dig your dj.app, it looks a lot like an app I sometime I
| use called Mixxx[1], which is open source[2]. But I think it's
| built using QT instead of wxWidgets. Anyways, now that I know
| there's a similar web-app available I might start trying dj.app
| out! thanks!
|
| 1. https://mixxx.org/ 2. https://github.com/mixxxdj/mixxx
| fuzzy2 wrote:
| It leaks HTML elements (div + canvas) for every dialog (or maybe
| just _About_?), but I have to say, it is fucking impressive. Good
| work!
| elviejo wrote:
| I bow my head to you sir... You have done what I've dreamed of
| many times. Thank you.
| nmstoker wrote:
| It's really impressive. Playback seems not to work in Firefox
| Nightly on Android but Chrome on Android works great.
| realyashnag wrote:
| Thank you for this. I've been looking for something like this for
| quick audio editing.
| nu11ptr wrote:
| Nice! Is it possible to merge this WASM port back into the
| wxWidgets main project? It just seems like a valuable target
| addition and could breathe some life back into wxWidgets.
| bfors wrote:
| Excellent work!
| stevehiehn wrote:
| very nice
___________________________________________________________________
(page generated 2022-09-03 23:02 UTC)