Nice, I can see the appeal having familiar UI on Mac.
Even though I am not your target audience (linux i3 user myself), I would be interested in knowing how much "hacking" the macOS system is required to do this. Is it hard to get a list of running apps for your Task Bar? Is it hard to list the apps for the menu? How about keeping it all "on top" while other windows e.g. get maximized/minimized/full-screen, etc?
I could talk for days on all the peculiar bugs resolved. Once the alpha stabilizes I have drafts to publish on several topics.
You actually nailed the major pain points. Particularly window focus and state management. I've spent months solving this problem alone.
-
1. Applications data list: Getting the list is easy! Finding out which apps in that list are "real" apps isn't. Getting icons isn't. Reliably getting information on app state isn't. Finding out why something doesn't work right is as painful as can be. Doing all this in a performant way is a nightmare.
2. Applications menu renderer: Rendering the list for the menu is easy enough: the macOS app sends this data via socket. The frontend is just web sockets and web components under the hood (https://lit.dev). The difficult part was converting app icons to PNG, which is awfully slow. So a cache-warmup stage on startup finds all apps, converts their icons to png, and caches them to the app directory for read.
3. Window state: again, by far the worst and it isn't even close. Bugs galore. The biggest issue was overriding macOS core behavior on what a window is, when it's focused, and how to communicate its events reliably to the app. Although I did include a couple private APIs to achieve this, you can get pretty far by overriding Window class types in ways that I don't think were intended (lol). There is trickery required for the app to behave correctly: and the app is deceptively simple at a glance.
-
One bug, and realization, that still makes me chuckle today.. anything can be a window in macOS.
I'm writing this on Firefox now, and if I hover over a tab and a tooltip pops up - that's a window. So a fair amount of time has gone into determining _what_ these apps are doing and why. Then coming up with rules on determining when a window is likely to be a "real" window or not.
The Accessibility Inspector app comes standard on macOS and was helpful for debugging this, but it was a pain regardless.
It is a full port of VLC so it should be able to handle this task. You're probably referring to the frontend which differs from the ones used on desktop but that does not mean the functionality is not available. It is, you just access it differently. Either enable the 'Take a screenshot' option (Controls Settings -> Take a screenshot) and use that or send an intent to do so. The former works while watching videos, the latter makes it possible to automate this task from within termux, Tasker or Automagic.
You can also just install vlc in termux and use the command line interface:
~ $ apt search vlc
Sorting... Done
Full Text Search... Done
vlc/stable 3.0.18-7 aarch64
A popular libre and open source media player and multimedia engine
vlc-qt/x11 3.0.18-7 aarch64
A popular libre and open source media player and multimedia engine
vlc-qt-static/x11 3.0.18-7 aarch64
Static libraries for vlc-qt
vlc-static/stable 3.0.18-7 aarch64
Static libraries for vlc
Those two operations are not related to each other. It's more intuitive if you treat .indexOf() as .startOf(). Then "asdf"[0..x] is "as" for x=2, and ""[0..x] is "" for x=0.
If I were designing this, I'd want to treat this as an unsupported usage of "find".
If you're okay with using the same error code for (a) string not found and (b) erroneous usage, then returning -1 makes sense.
Since (b) is something that probably indicates a bug in the application code, I'd probably prefer that (b) triggers a different program flow. E.g., raising a C++ exception, failing an `assert`, etc.
They also disallow updates to MV2 extensions in January, which effectively kills them off: "Chrome Web Store stops accepting updates to existing Manifest V2 extensions"
I think this has to change and may just be an outdated part of the timeline that hasn't been updated yet. After all, this item is still on the timeline too: "Enterprise policy can let Manifest V2 extensions run on Chrome deployments within an organization." But that doesn't make any sense anymore, because V2 will no longer be disabled on the stable channel in January, so there's not even a need for an enterprise policy to keep V2 extensions running.
It wouldn't make any sense to let V2 extensions keep running until June but disallow updates. What about security issues? They have to allow security updates.
> January 17, 2022: New Manifest V2 extensions will no longer be accepted by the Chrome Web Store. Developers may still push updates to existing Manifest V2 extensions, but no new Manifest V2 items may be submitted.
> January 2023: The Chrome browser will no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions.
So V2 would be disabled in the stable channel simultaneously with the end of updates, in January 2023.
Only a special enterprise policy could keep V2 extensions running for a while after that time.
This study was done in China. It is important to know the locals behaviour with regards to natural Vitamin D source (the Sun). Locals do not like to have "too dark skin" and as such are using sun screen with factor 50 and try avoid sunshine altogether.
This study might have different results in other parts of the world.
E Ink owns the majority of the patents, so direct clones of E Ink are being made under license. I do not think that the patents are the limiting factor - the specific applications are somewhat limited compared to widespread use of OLED.
For the applications that have mass apeal we saw that the price goes down to a comparable level of an LCD (eg in ebook readers and shelf labels).
There is also a bunch of innovation happening in the market - competitors like ClearInk are trying to build a better version of E paper, but it's always hard to scale some new technology and it will take some time before anything substantial comes along. E Ink was lucky that they found the killer app in ebook readers and that really helped them get to volumes that allow them to build these screens in commercial volumes.
I would actually like to see combination of the two tested. Such as a greyscale high resolution e-ink base and a transparent layer of Mirasol like color pixels that can activate.
Kind of mimicking CMYK from print, and LED TV:s locally adjusting LED backlight to improve contrast ratios, and some high HDR screens. Except a very low energy use variant.
Even though I am not your target audience (linux i3 user myself), I would be interested in knowing how much "hacking" the macOS system is required to do this. Is it hard to get a list of running apps for your Task Bar? Is it hard to list the apps for the menu? How about keeping it all "on top" while other windows e.g. get maximized/minimized/full-screen, etc?