eejdoowad

Gave it a spin and it feels really polished!

Since you offered... I'm curious about the rendering technology behind it. I'm working on a web app with a spreadsheet interface, and I'm using a standard canvas-rendered grid.

You obviously have different design constraints, so it would be interesting to see how they shaped your solution.

Cool idea and onboarding experience. I spun up Chrome to demo it, and although its got the rough edges of a prototype, the potential is there.

I created a rule to remove thumbnails and shorts from YouTube, and after a few failed attempts, it succeeded! But there were massive tracts of empty space where the images were before. With polish and an accessible way to find and apply vetted addons so that you don't have to (fail at) making your own, I would consider using it.

My daily driver is Firefox, where I've set up custom uBlock Origin cosmetic rules to personalize YouTube by removing thumbnails, short, comments, images, grayscaling everything except the video, etc. My setup works great for me, but I can't easily share it with other people who would find it useful.

Love the concept and design.

Where are repositories stored and do you use any sort of backup or replication?

Sqorn author here.

Sqorn doesn't use tagged template literals to be cool. It uses them to make writing SQL flexible, secure and intuitive.

You can write:

const boy = sq.from`person`.where`age < ${7} and gender = ${'male}`

to produce the query:

{ text: 'select * from person where age < $1 and gender = $2', args: [7, 'male'] }.

All methods have both template and non-template string forms you can choose between. For example, the query above could also be written as:

sq.from('person').where({ maxAge: sq.l`age < ${7}`, gender: 'male' })

or even as:

sq`person``age < ${7} and gender = ${'male}`

or for those who like plain old SQL:

sq.l`select * from person where age < ${7} and gender = ${'male'}`

Read the tutorial at https://sqorn.org/docs/tutorial.html to learn about the possibilities.

It works well and I like the overall design. Why'd you make it?

The default keyboard shortcuts are a little awkward; using tab or the up/down arrows to navigate the list would be more intuitive. Also, it would be easier to distinguish tabs if the title were displayed before the hostname.

It's really cool to see the applications made possible by the high quality, reasonably priced, and fairly licensed text-to-speech APIs offered by AWS, Azure, and Google Cloud.

The most fleshed out service of this type that I've found is narro.co, which offers web/pdf/epub/video/rss/email/text to audio conversions.

Keylogging is just the beginning. Any (and many) browser extensions have the ability to record everything you do on every page you visit. All it takes is specifying the <all_urls> permission in the extension’s manifest and adding some event listeners.

It has to work this way or browsers wouldn’t be truly extensible. Be mindful of which extensions you install.

Great work. It’s a pleasure to use. A few questions:

1. Have you heard of Narro (narro.co)? It does the same thing, but it’s been around longer and has many integrations.

2. Can you share the tech stack currently powering your voice synthesis? Since it’s called PollyPodcast, are you currently using AWS Polly for TTS?

3. Is this something you intend to monetize?

4. It seems like you offer unlimited readings for free. Do you have an abuse prevention strategy? This could become a hole in your wallet if you’re paying for a charged-per-character TTS service.

5. Creating custom voices is a great differentiator. What are some problems you have to solve to create them and how is this effort progressing? Do you have quality and performance goals?

Looking forward to this update.

I wonder if it will be possible to load scripts into the reader view document. Currently, it isn’t, so keybinding extensions, which rely on inserting Keyboard event listeners, don’t work in reader view. I had been prototyping a custom reader view in Saka Key using Mozilla’s Readability library to work around this issue.

The Content Security Policy fix is a lifesaver. Saka Key attaches hint elements to the DOM and attaches a script tag to load common styles/fonts. Sites with the policy style-src: self (like crates.io) block script tags, which breaks hint styling and positioning.

This is unfortunately true, though it doesn’t have to be. The problem with webapps generated with JavaScript is that it’s tempting to create a custom implementation of built-in functionality. Good old anchor tags are “visible” to screen readers that visually impaired people use to browse the web. Chances are your JavaScript Link hack isn’t because you forgot to include the role=“link” attribute. Keybinding extensions are similarly blind when developers write inaccessible markup.

The solution is for developers to spend a day learning about accessibility. A good starting point is https://webaim.org/intro/.

Far as I can tell, no. I'm open to adding an emacs profile to Saka Key. It's as easy as modifying this JSON file: https://github.com/lusakasa/saka-key/blob/master/src/options...

My understanding is that if they do implement an API, they want it to be better than the status quo, not the same.

What happens when two extensions try to place a widget in the same location? Chaos. Not that the status quo is any better.

Interestingly, Firefox's sidebar API only allows a single sidebar to be shown.

An extension overlay API would have saved me so much pain when building Saka (saka.io). There are two options for injecting UI today:

1. Inject UI directly into the document

2. Inject an iframe containing the UI into the document

Both rely on manipulating the document, which can be used to fingerprint users. Most developers opt for 1 because it requires no setup and lets the content script synchronously access the UI. 2 is needed when the injected UI containing sensitive information.

I'd like an extension overlay API that lets you inject: 1. UI local to the tab 2. UI that persists across all tabs

In a brief #webextensions IRC discussion, I was told an overlay API isn't viable for a number of reasons, one of which is multiple extensions may conflict.

Just wanted to mention, one of the unique features of Saka Key is that it lets you define keybinding profiles that are easy to switch between, and there are multiple profiles built in, including one that mimics Vimium.

The address bar autofocusing is annoying. Best advice I have is to replace your new tab page with a URL or a custom new tab extension.

Also, I devised the default keybindings with three goals in mind.

1. Common keys should be easy to reach.

2. Users unintentionally trigger dangerous commands (like close the current tab). To prevent this, I bind dangerous commands to 2 key sequences.

3. Users not being able to remember keybindings. To help users remember, I try to associate commands with an intuitive key, e.g. Zooming is mapped to z.

Saka key author

I think site-specific keyboard shortcuts are great. Do you have plans to release the source code? My chrome extension Saka Key [1] provides generic keyboard shortcuts, but my vision is to eventually integrate with other extensions like yours and Streamkeys [2].

1. https://github.com/lusakasa/saka-key

2. https://www.streamkeys.com

Very cool to see my own extensions indexed there.

I have an obfuscated closed-source extension that I accidentally released with source maps in early versions. Guess I'll have to be more careful next time.

Thanks! I was very surprised a half-decent in-window tab search extension didn't already exist. They all opened in the popup or a new window. So I made one myself.

My goal is to make a complete Omnibar/tabs replacement so I can browse in full-screen mode by default.

This extension complements my other keybinding extension (https://github.com/lusakasa/saka-key).

I've been building a keybinding Chrome extension like Vimium for about half a year now. It started when I struggled to add a feature to Vimium and figured I could do it better myself.

From my biased perspective, my extension is better. User uptake has been negligible, but I think the lessons I've learned have made it worth the time invested.

https://github.com/lusakasa/saka-key

For my extension Saka Key (https://github.com/lusakasa/saka-key), I decided to use the browser.* APIs on both Chrome and Firefox using Mozilla's web extensions polyfill.

https://github.com/mozilla/webextension-polyfill

The biggest challenge for me was addressing browser incompatibilities and Firefox bugs. This is a big one:

https://bugzilla.mozilla.org/show_bug.cgi?id=1193394

Another is that Firefox doesn't fire blur events when DOM elements are removed or hidden.

The Firefox approval process is slow. Mine took 3 months the first time, < 10 days the second time, and this third time it's taking over a month.

Chrome's reviewal process is really nice. It usually takes <30 minutes.

Awesome job with the extension! I think the idea has great potential.

Judging from my five minute test drive, you could probably increase adoption if you made it 'discoverable'. It's hard to determine what to do once it's installed. Turns out, you have to click the browser action to start listening for user input. After that, you have to refer to the website to find out what commands are available. It would be great if there were on-screen suggestions of commands to voice. Using it was really frustrating and unreliable until I read the instructions on the web store page to disable 'ambient noise reduction' on macs. Showing an 'instructions' page on installation would help a lot. An instructional video would be great too.

Other nitpicks: * I couldn't get dictation to work. * More tab manipulation commands would be nice * I'm not a huge fan of the link hints placement and styling

I'm actually developing my own keybinding extension like Vimium/cVim/VimFx/Surfing Keys

https://github.com/lusakasa/saka-key

with the intent to use the codebase to later create a voice commands extension like yours.

After all the work I've put into my extension, I can see why only $10 in donations for your efforts is disheartening. Good luck!

I showed my 9-year-old nephew Scratch, and within an hour he had designed a dancing man that made noise and moved around. It makes creating interactive games and stories easy and fun.

Why isn't there a Scratch for adults? A serious tool targeted to artists and professionals that makes it easy to publish interactive stories and presentations using standard web tech.