ShortFuse @ ShortFuse @lemmy.world

Posts

0

Comments

300

Joined

2 yr. ago

Cite your sources because that's not how persistent notification works. PIA doesn't need it. It sounds like a poorly written app.

Edit: DNS66 as well.

I don't understand the article. They either aren't clearly explaining the issue or just heavily misinformed.

I have Google One and PIA. Both do the same thing, which is add a key to the top right of the screen. To me, that's like a persistent notification.

PIA has never needed to use the actual persistent notification API. There's no reason to. Persistent notification is for application that don't want their UI Window to terminate when Android gets memory pressured, or when wanting to use a local service (eg: Location or Orientation) when not the main foreground application. I can kill the PIA Window (swipe up from recent apps) and the VPN is still running.

If Google One were able to activate VPN without changing my status bar, that's a different story, and that's not the case.

Edit: DNS66 as well

That should be a slider pop-up, like this:

Probably best to widen it for better control.

I built this myself, and this stuff is already built into Android.

Barq's has bite!

And yet...

That's a strawman. I don't need 1000s of lines of JS to swap a UI. I can do it in 1 line with Web Components: oldElement.replaceWith(newElement). And those modules can be lazy loaded like anything else.

This is just DX in name of UX, which is almost never a good idea.

And maybe you're fine with throwing a server computation for every single UI change, but I'm not made of money and I much rather have stuff on a CDN.

C'mon, what's not to like about bonding every UI action against a remote server? What's a few milliseconds anyway? I'm sure it works fine over cellular networks. I mean, it works great on my dev machine! /s

Accessibility is horrible without JS. You should be modifying ARIA tags heavily as the user interacts with the page. I tried to write pages with no JS and realized the needs of the a11y group heavily outweighs the noScript group.

PascalCase default exports for Classes

camelCase named exports for functions

ALL_CAPS named exports for constants

Packet loss really, and the latency and jitter said loss can contribute to.

Radio waves go faster (speed of light) than through a medium (copper). Not that it matters at such a small scale, but it's helpful to have a good picture of the elements at work here. The further you are from the receiving point, the more obstacles (matter) that can obstruct it. But in ideal conditions WiFi is better than most people think. Replicating those ideal conditions though...

Yeah, sorry that was bumped up recently though I was grandfathered for a long while. But that was the impetus for getting it back when it was just GPM.

It's 6 actually (1+ 5 other members). My uncle basically paid for half of it.

It's $22.99 for me now which includes YouTube Premium. Just YouTube Music (for 6) is $16.99. Individual $10.99 and Student $5.49.

6 family members for $15 a month and no YouTube ads. Also that money was basically paid for by Google Rewards. The Web App is good too. I don't have to deal with CEF/Electron or any install really.

I just recently worked on fixed point 8.8 and basically the way fractional values work, you take an integer and say that integer is then divided by another one. So you represent the number in question with two numbers not one. 0.3 can be presented in a number of ways, like 30 % 10, or 6 % 20.

The problem is the way 0.1 is represented and 0.2 represented don't jive when you add them, so the compiler makes a fractional representation of 0.3 based on how 0.1 and 0.2 were expressed that just comes out weird.

That's also why 0.3 + 0.3 is fine. When you wrote 0.3, the compiler/runtime already knew how to express 0.3 without rounding errors.

You can use Dev Tools to see a page's full accessibility tree:

Chrome: https://developer.chrome.com/blog/full-accessibility-tree/#full-accessibility-tree-in-devtools

Firefox: https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/#features-of-the-accessibility-panel

I haven't really looked for anything that will present that to you as an Add-On/Extension but it's theoretically possible.

We're kinda getting it back with the Accessibility tree

In theory, if the page is compiled right, you can read everything right from there. You could also interact with it.

Outside of PWA shortcomings, I believe there's a way to have a .NET application run a WebView with Edge (Chromium). I believe Windows 11 has both pre-installed now.

I don't even want to run NodeJS anymore. I would run all my server apps on headless Chromium if I could.

Dropping C#, Java and Objective-C and just having one single deployment is nice as well.

Yeah, I have my own stuff that lets me do MSSQL, DynamoDB, REST/HATEAOS, regular Hash Maps, and some obscure databases (FilePro).

I throw them in a tree structure and perform depth-first searches for resources. Some of them have stuff for change data capture streaming as well, (eg: SQLNotifications, DynamoDB Stream, WebSockets).

DynamoDB was a rough one to optimize because I have to code to pick the best index. You don't do that with SQL.

The code on backend is the same as frontend, but a different tree. Frontend queries against REST and a cache layer. Backend queries against anything, REST included.

I've been writing my own render framework and component library for about a year now.

One thing I enjoy most about it is that the types are automatically inferred. There's a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic this, dynamic return types based on input, Class type reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).

It's all written in JavaScript with "JSDocs". It's not really JSDocs because there's a lot of recursion that's not possible with regular JSDocs. It's TS type information slipped into JSDoc comments.

Ridiculously complex core Class

But that is to setup the ability to tap into inferred types. The actual code that's written (eg: components) is fully typed check with little or no type declaration.

Declarative-style component with almost no explicit typing

The reality is, no complex piece of code should be written without some form of type checking. TS isn't perfect and if there were something better, I'd move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.

The result means all my code today just runs in the browser. I don't have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it's an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don't need npm to package and release. (CodePen Sample)

Starfield has a bunch of AS3 and Flash files. I've been hacking it all week.

And, uh, I use vanilla JavaScript with Typescript checking via JSDocs.