I'll definitely be watching out for more built-in streaming support. Being able to throw the standard types directly over the wire and trust that the library will handle optimally utilizing the connection would make this the RPC library that I've been looking for all year.
My biggest complaint with library management tools, and I think this applies to Librari as well, is the lack of multi-user support. I have a lot of books in my "home library", spread out over a few rooms. But I'm not the only person interacting with this library. Their are books on the shelves that "belong" to other people in the house, and we all joint manage the books. Sharing logins can work, but misses out on so many things that we would like to have.
My dream tool for this would allow multiple people to be "members" of a library, and be able to belong to multiple members themselves. They could collectively manage things like metadata, like what books are on the shelves, but could have individual things like ratings or tracking what they've read.
Plex is actually a really good example of this. I hope some day to find a tracker like that for my books.
The paid version of libib.com allows you to do this. Each manager can be assigned overlapping collections to edit, but also have the ability to track status, rate and review individually.
Thank you for your comment and for explaining your problem in such detail. Currently, you can mark your library as public and share the link with others, but they can only see the books in it. What you're saying actually makes total sense, and I will add this feature to my backlog.
It doesn't use Chromium. I think that their point is that Firefox's rendering engine, Gecko, can only have an impact on the rendering engine space proportional to its user base, which they have argued is insignificant.
During our early exploration, someone made a data loader that returned an entire svg of a chart, instead of the data for a chart. I think it was a headless browser running Observable Plot, but I imagine there are lots of ways to generate charts in a data loader.
Observable engineer here. I haven't looked into Malloy much, but Framework's data loaders are very flexible. If you can write a script or binary that uses Malloy and writes to stdout, it can be a data loader. For example, although we use SQL a lot in our internal usage of Framework, Framework doesn't actually have any specific SQL support. We just use our database's normal bindings.
Can you link to the "data loader" API or perhaps even a "data loader" example implementation for something similar to malloy, duckdb, or any other DB/SQL data source/provider?
The docs for data loaders are here: https://observablehq.com/framework/loaders. The simple version is they are simply programs that write their output to standard out. Very Unixey. When those programs are referenced in client side parts of the JS, they are reactively run when in development, and prebuilt for deployment.
I don't think we have any full examples of using a database yet, but we have written a bit about using DuckDB via its Node bindings here: https://observablehq.com/framework/lib/duckdb
I imagine that either Malloy's CLI or its Python bindings would fit very well here.
Once you start typing the same icons should show up again. You can click on them to perform just that search with the selected search engine, or right click on it to make it the default.
The very worst I've seen is in Krita (maybe they've changed it) where to make a new brush you had to select the name field of an existing brush and edit it, and only then would the button for "Save a Copy as a New Brush" or whatever appear. Good luck hunting for the "New Brush" button, you're not going to find it.
I'd say that Firefox versions are mostly a unit of time now, since they aren't generally semantically meaningful in the way semver is. While working on Firefox, we often make plans that are delineated not in weeks, months, and quarters, but in Firefox releases and the nightly/beta/release cycle associated with them.
The recent change to having a releaes every 4-5 weeks is a small modification of the existing practice of having a new version every 6-8 weeks.
The 6-8 week schedule is about a decade old now. It's original goals were to help ensure that unrelated features didn't block each other from releasing, and make releases more consistent, which helps localization, testing, and project management. In that regard I think it's been very successful.
It's probably not worth nitpicking a decade old decision though.
This feature (source maps) has been improving a lot over time. A year ago it was basically unusable, and today I rarely have problems jumping from console to debugger. We're even working on a way to show the original variable names in the scope inspector when paused in the debugger now.
On the other hand, Firefox's layout dev tools, like the grid and flex box inspector, are way better than doing the same task in Chrome, in my experience.
