I was mostly focused on preparing 1.3.rc and landing everything I need to land in time, so not much happened in the meantime.
However, since it's hard code freeze now, I can start landing new stuff, so I've just landed the new undershoot, view switcher styles and toolbar refactoring, along with opening corresponding MRs for Calendar and Logs since it's a behavior change.
The rest still needs work:
First, all of the new API need docs and tests.
Otherwise:
AdwToolbarView is ready otherwise. I still need to port a few more apps to test things - I have a mostly complete port of Ephy (it's complicated because of fullscreen handling), but there are a few bugs there that I want to iron out first to make sure they are even fixable with this widget.
AdwAdaptiveState - there is a regression with porting preferences window that I need to get to first.
I'm also still waiting on GTK to start ellipsizing buttons - GTK people decided to try it out globally after branching gtk-4-10.
And then I need to decide if it will still need non-px units with that.
Meanwhile, I fixed a bug in GtkBuilder, so adaptive states in UI files can now be a little prettier.
I.e. <condition> just within the <object>, without <conditions>. It was always supposed to be like this (well, ideally it would be <property> but we can't have custom GBoxed there), and without <conditions> the parser was choking on nested conditions like:
Now, AdwBrowsingView still needs to implement swipes - it currently doesn't. And since I decided not to set clamped=true on spring animations there, I need to fix how AdwSwipeTracker calculates velocity - there's currently a bug there that's visible in Loupe - make a full swipe, so that the page is in the final position, then swipe further than that and release it - the page will still bounce. With proper timing this looks really weird - the page moves, stops for a few milliseconds, then keeps moving. This shouldn't happen.
I also still need to port AdwPreferencesWindow to that - currently it's still leaflet as it has API for subpages and it's kinda scary to touch that.
There are also smaller things - one of the features I'm a bit proud of is that the automatic back buttons automatically show the title of the previous view in their tooltip. However, there's no fallback for an empty title.
And finally, AdwDualPaneView is the one that needs the most work.
- It has a :pop-content-on-fold property that's unimplemented atm
- It doesn't implement GtkBuildable
- For sidebars it's common to have an empty title, this is a bit awkward to implement atm and there should be a helper in AdwHeaderBar
- AdwHeaderBar also needs a property to disable automatic window button handling
And otherwise I think that's it for these specific widgets.
or maybe the reason was that the 8008 was a popular microprocessor, and it happened to use an 8-bit byte so it became the foundation for all of intel’s future microprocessors, but in theory they could have also built a microprocessor with a 10-bit byte instead and that would have been fine too?
I think I drafted the bulk of grid lowering for my CatTrap layout engine! As well as unit lowering, though most of the conversion factors need to be fed in from outside.
I'll get those compiling tomorrow & navigate a dependency conflict I've got... Following day I'll finish this preprocessing work! And write a manual test script.
Got length units lowering in CatTrap, and now I'm wishing for a domain-specific language which wrote all the dataflow for me. Takes a lot to think that through...
"Just because you're the underdog doesn't mean that the public will support you. That sort of stuff only happens in Warner Brothers' movies, they work very hard to make sure it doesn't happen in real life."
"It's like when you built your house everyone was really into stilts. Thank god for stilts you might say, how else am I meant to reach my door!"
I've just drafted some logic to preprocess grids. Now I need to:
* read the spec again to figure out how exactly to handle spans & subgrids * lower various units as far as I can prior to layout, taking into account the font. * Figure out how to thread the necessary dataflow in. * Abstract both this grid preprocessor & the unit lowerer to add Flow Layout support.
This is Kickstarterable. It's not actually a big ask for the US queer community if the call goes broadly enough.
I cannot do it. I'm not in the US and do not have the time or flexibility to make it happen. Do you know someone doing queer studies work who had the bandwidth? Send them my way. Or just go do it! I don't need to be involved, I just want to know that in 40 years, they won't be able to say we were never here again.
The Internet Archive? They could do it. They can't do it for free, and they're better set up for books than looseleaf, so it's not a perfect fit, but there are few parties better equipped to host it. It's not inaccessibly expensive — at my guess, it would cost somewhere around $75k to scan the entire NYC Gay and Lesbian Center archive, one of the biggest. A couple million could probably handle most of the queer archives in the US.
This doesn't mean they'd be available online — many of these archives have documents that will be sealed for years yet, and online access is politically complex (for good reasons). Metadata is a whole other problem — I'm talking about the kind of scanning process that images the document and gives you a box number it came from, which is horrifying to any serious archivist. But if the alternative is the fire? Yeah, we can actually sort it later.
Almost all of the gay, lesbian, and trans history archives in the US and elsewhere are held on paper. There's one relatively small commercial collection that's been digitized, but very little else has. Stonewall? The AIDS crisis? All of it can just burn. It's held by community organizations that are doing well to keep it stored and accessible. They aren't in a position to scan it, and even if they could, they aren't set up to manage hosting data that large numbers of fascists want destroyed in a complex and rapidly-evolving risk environment.
If want to capture the nuances of lighting in 3D computer graphics we switch to using physics simulations! We trace lightrays backwards from the camera to the lights. Or, like in Blender's Cycles renderer, have these lightrays meet in the middle. The formulas are the same!
In the early days we hitted against spheres, cubes, etc without tracing the beam as it bounces around the scene. "Recursive" raytracing refers to tracing those bounces.
Concurrency is applied per output pixel due to the output device's demands, with a decently-designed index used to minimize the cost of hittesting each bounce. This same index can be reused for kinetics simulations!
Good old computer-science techniques!
1.1/1.1 Fin for today! Tomorrow: Modern GPU design.
A browser developer posting mostly about how free software projects work, and occasionally about climate change.Though I do enjoy german board games given an opponent.Pronouns: he/him#noindex