It’s not just me. Phoronix is reporting on growing concerns in the Qt community about the project’s increasing commercial focus and apparent deprecation of its open source core.
I have said many times in these pages and elsewhere that I really like Qt: it’s the right tool for a lot of jobs. But increasingly I’ve been feeling that any contribution I make in educating users about Qt is benefiting a commercial enterprise and not a community tool. So much so that I am re-surveying other open source multi-platform libraries to use as an alternative to Qt.
If the community no longer has meaningful Qt ownership, a lot of users will no longer be interested.
So there I was scratching an itch when I realized the scratch would make for a good Arduino library. AsyncTimer lets you create a timer that does something when you start it (or nothing if you prefer), then waits a predetermined time before doing something else. While it’s waiting, it doesn’t lock up your Arudino the way the delay() function does—it just schedules the time-out action to take place some time in the future.
If you’re not the RTFM type, you can just get what you need from the GitHub repository.
I have been evaluating WebKit and Blink-based open-source browsers for Linux—mostly because Firefox is often noticeably laggy on an old laptop I like to use. (I still <3 you though, Moz!!) Chromium is an obvious option, but I would like to investigate solutions that don’t rely on Google. This has led me to Midori and QupZilla. Both position themselves as lightweight alternatives to the big kids. Both have their pros and cons.
A con with QupZilla that I want to take on in this post is the result of its use of Qt. I love Qt. It’s the right tool for a lot of jobs. But it harbors a hidden gotcha when it comes to rendering web pages: you are at the mercy of the Qt maintainers’ web rendering engine update policies. The latest version of QupZilla that you can build with the production version of Qt (5.5) uses QtWebEngine, which is based on the Blink-based Chromium. (So much for not relying on Google!)
A similar situation exists with Midori. It uses GTK’s WebKitGTK+, which in Debian sid is as of this writing at 2.4.9-2 and also is about about two years old. Probing the user agent indicates it uses WebKit 538.1.5. But as there is in Qt, there is an additional wrinkle in the GTK+ world. There are currently two versions of WebKit for GTK: WebKitGTK+ and WebKit2GTK+ . Depending on which one your GTK+ application uses, you may get an old or a new version of WebKit. The version of WebKit2GTK+ that ships with Debian sid appears to provide WebKit 602.1 at the moment, which is the current point-release WebKit, and new releases of WebKitGTK+ flow regularly. (Why Midori doesn’t use WebKit2GTK+ is a question for the developers and one that I hope to pursue. FYI, GNOME’s Web, née Epiphany, uses WebKit2GTK+.)
Whatever the specifics may be in this case, the takeaway is this:
When using integrated application frameworks, you need to be aware of versioning limitations with third-party tools that they bundle.
Audio by Van Alstine has adopted my discrete Class A audio module into two of their products. The Vision DAC uses the module in its differential anti-imaging filter and output stage and the Vision SL Preamp uses it for line stage amplification. The pair will be premiered at the Axpona Audio Expo in Chicago this weekend. Looking forward to feedback from the show.
As part of my Open source audio remote control initiative, I’ve just published Volume-AlpsRK16814MG, an open source hardware design that integrates a high-quality Alps motorized quad potentiometer with an H bridge. The design lets you control the motor’s direction using two logic-level signals: VOL_UP and VOL_DOWN. The fact that it’s a quad pot means you can use it to control regular stereo volume by ignoring one of the dual gangs or a differential stereo signal.
Here’s the schematic* to give you an idea what it’s doing. Gerbers and PCBs are available at OSH Park.
I’ve also modified the remote control receiver to better support motorized pots. There is now a compile-time option that lets you latch and unlatch the VOL_UP and VOL_DOWN signals rather than produce repeated VOL_UP and VOL_DOWN pulses—which makes control of motorized pots more fluid.
I’ve started a FLOSS remote control receiver project for DIY audio preamplifiers. I think it’s just about good enough to make public.
Remote control is one of the more challenging things for an audio DIY person to implement, so I thought having an open source hardware and software platform for doing this would be useful. It uses our good friend Arduino for brains and works with the Philips RC-5 protocol. I like RC-5 because its the closest thing I know of to a universal, well-documented, brand- and model-agnostic protocol.
The IR command decoding is done using Guy Carpenter’s excellent RC5 library. I also considered using Ken Shirriff’s multi-protocol IR library. Ken’s library works with a large number of protocols, but I thought its larger memory footprint might preclude porting this thing to tiny AVRs.
Here’s a workaround I used in a KiCad layout that involved a DRC error with a module’s (non-conducting) mounting pin. The mounting pin is physically close enough to an electrical pin that it makes the DRC clearance test fail. The proximity isn’t actually a problem because the offending pin is just so much mounting foo for the part, but KiCad doesn’t know the difference.
The workaround is to edit the pad for the mounting pin and assign it the same pad number as the pad the DRC thinks it’s too close to. (See the two pads numbered 3 in the above image). Kludgey, but it silences the (not really an) error. I made this change in the PCB layout rather than in the library module as it won’t be a problem on boards with smaller copper clearance.