FEED Validator

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

• line 2, column 0: Use of unknown namespace: http://planet.intertwingly.net/ [help]

  <feed xmlns="http://www.w3.org/2005/Atom" xmlns:planet="http://planet.intert ...
  

• line 297, column 45: Identifier "https://samthursfield.wordpress.com" is not in canonical form (the canonical form would be "https://samthursfield.wordpress.com/") (7 occurrences) [help]

        <id>https://samthursfield.wordpress.com</id>
                                               ^

• line 766, column 0: p should not contain preload attribute (2 occurrences) [help]

  <video class="html-video" controls="" preload="auto" width="100%">
  

• line 766, column 0: p should not contain controls attribute (2 occurrences) [help]

  <video class="html-video" controls="" preload="auto" width="100%">
  

• line 2199, column 15: name should not be blank [help]

          <name/>
                 ^

• line 2288, column 0: div should not contain controls attribute (2 occurrences) [help]

  <video class="wp-video-shortcode" controls="" height="394" id="video-3094-1" ...
  

• line 2288, column 0: div should not contain preload attribute (2 occurrences) [help]

  <video class="wp-video-shortcode" controls="" height="394" id="video-3094-1" ...
  

• line 3189, column 4: figure should not contain controls attribute (2 occurrences) [help]

      <video controls="" src="https://bxt.rs/blog/just-how-much-faster-are-the ...
      ^

Source: https://planet.gnome.org/atom.xml

1. <?xml version="1.0"?>
2. <feed xmlns="http://www.w3.org/2005/Atom" xmlns:planet="http://planet.intertwingly.net/" xmlns:indexing="urn:atom-extension:indexing" indexing:index="no"><access:restriction xmlns:access="http://www.bloglines.com/about/specs/fac-1.0" relationship="deny"/>
3.  <title>Planet GNOME</title>
4.  <updated>2024-05-19T09:03:42Z</updated>
5.  <generator uri="http://intertwingly.net/code/venus/">Venus</generator>
6.  <author>
7.    <name>GNOME Sysadmin Team</name>
8.    <email>gnome-sysadmin@gnome.org</email>
9.  </author>
10.  <id>https://planet.gnome.org/atom.xml</id>
11.  <link href="https://planet.gnome.org/atom.xml" rel="self" type="application/atom+xml"/>
12.  <link href="http://pubsubhubbub.appspot.com/" rel="hub"/>
13.  <link href="https://planet.gnome.org/" rel="alternate"/>
14.  
15.  <entry xml:lang="en-US">
16.    <id>https://blogs.gnome.org/aday/?p=10534</id>
17.    <link href="https://blogs.gnome.org/aday/2024/05/17/gnome-maintainers-heres-how-to-keep-your-issue-tracker-in-good-shape/" rel="alternate" type="text/html"/>
18.    <title>GNOME maintainers: here’s how to keep your issue tracker in good shape</title>
19.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">One of the goals of the new GNOME project handbook is to provide effective guidelines for contributors. Most of the guidelines are based on recommendations that GNOME already had, which were then improved and updated. These improvements were based on input from others in the project, as well as by drawing on recommendations from elsewhere. … <a class="more-link" href="https://blogs.gnome.org/aday/2024/05/17/gnome-maintainers-heres-how-to-keep-your-issue-tracker-in-good-shape/">Continue reading <span class="screen-reader-text">GNOME maintainers: here’s how to keep your issue tracker in good shape</span></a></div>
20.    </summary>
21.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>One of the goals of the new <a href="https://handbook.gnome.org/">GNOME project handbook</a> is to provide effective guidelines for contributors. Most of the guidelines are based on recommendations that GNOME already had, which were then improved and updated. These improvements were based on  input from others in the project, as well as by drawing on recommendations from elsewhere.</p>
22. <p>The best example of this effort was around <a href="https://handbook.gnome.org/issues/management.html">issue management</a>. Before the handbook, GNOME’s issue management guidelines were seriously out of date, and were incomplete in a number of areas. Now we have shiny new issue management guidelines which are full of good advice and wisdom!</p>
23. <p>The state of our issue trackers matters. An issue tracker with thousands of open issues is intimidating to a new contributor. Likewise, lots of issues without a clear status or resolution makes it difficult for potential contributors to know what to do. My hope is that, with effective issue management guidelines, GNOME can improve the overall state of its issue trackers.</p>
24. <p>So what magic sauce does the handbook recommend to turn an out of control and burdensome issue tracker into a source of calm and delight, I hear you ask? The formula is fairly simple:</p>
25. <ul>
26. <li><a href="https://handbook.gnome.org/issues/review.html">Review</a> all incoming issues, and regularly conduct reviews of old issues, in order to weed out reports which are ambiguous, obsolete, duplicates, and so on</li>
27. <li>Close issues which haven’t seen activity in over a year</li>
28. <li>Apply the “needs design” and “needs info” labels as needed</li>
29. <li>Close issues that have been labelled “need info” for 6 weeks</li>
30. <li>Issues labelled “needs design” get closed after 1 year of inactivity, like any other</li>
31. <li><a href="https://handbook.gnome.org/issues/management.html#encourage-contributors">Recruit contributors to help with issue management</a></li>
32. </ul>
33. <p>To some readers this is probably controversial advice, and likely conflicts with their existing practice. However, there’s nothing new about these issue management procedures. The current incarnation has been in place <a href="https://wiki.gnome.org/action/recall/Bugsquad/TriageGuide?action=recall&amp;rev=96">since 2009</a>, and some aspects of them are even older. Also, personally speaking, I’m of the view that effective issue management requires taking a strong line (being strong doesn’t mean being impolite, I should add – <a href="https://handbook.gnome.org/issues/management.html#be-polite-empathetic">quite the opposite</a>). From a project perspective, it is more important to keep the issue tracker focused than it is to maintain a database of every single tiny flaw in its software.</p>
34. <p>The guidelines definitely need some more work. There will undoubtedly be some cases where an issue needs to be kept open despite it being untouched for a year, for example, and we should figure out how to reflect that in the guidelines. I also feel that the existing guidelines could be simplified, to make them easier to read and consume.</p>
35. <p>I’d be really interested to hear what changes people think are necessary. It is important for the guidelines to be something that maintainers feel that they can realistically implement. The guidelines are not set in stone.</p>
36. <p>That said, it would also be awesome if more maintainers were to put the current issue management guidelines into practice in their modules. I do think that they represent a good way to get control of an issue tracker, and this could be a really powerful way for us to make GNOME more approachable to new contributors.</p></div>
37.    </content>
38.    <updated>2024-05-17T15:29:36Z</updated>
39.    <published>2024-05-17T15:29:36Z</published>
40.    <author>
41.      <name>Allan</name>
42.    </author>
43.    <source>
44.      <id>https://blogs.gnome.org/aday</id>
45.      <link href="https://blogs.gnome.org/aday/feed/" rel="self" type="application/rss+xml"/>
46.      <link href="https://blogs.gnome.org/aday" rel="alternate" type="text/html"/>
47.      <subtitle>Allan Day's GNOME Blog</subtitle>
48.      <title>Form and Function</title>
49.      <updated>2024-05-17T15:29:36Z</updated>
50.    </source>
51.  </entry>
52.  
53.  <entry>
54.    <id>https://wingolog.org/2024/05/16/on-hoot-on-boot</id>
55.    <link href="https://wingolog.org/archives/2024/05/16/on-hoot-on-boot" rel="alternate" type="text/html"/>
56.    <title>on hoot, on boot</title>
57.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><div><p>I realized recently that I haven’t been writing much about the <a href="https://spritely.institute/hoot/">Hoot
58. Scheme-to-WebAssembly compiler</a>.  Upon
59. reflection, I have been too conscious of its
60. limitations to give it verbal tribute, preferring to spend each marginal
61. hour fixing bugs and filling in features rather than publicising
62. progress.</p><p>In the last month or so, though, Hoot has gotten to a point that pleases
63. me.  Not to the point where I would say “accept no substitutes” by any means, but good already for some things, and worth
64. writing about.</p><p>So let’s start today by talking about bootie.  Boot, I mean!  The boot, the boot, the boot
65. of Hoot.</p><h3>hoot boot: temporal tunnel</h3><p>The first axis of boot is time.  In the
66. beginning, there was nary a toot, and now, through boot, there is Hoot.</p><p>The first boot of Hoot was on paper.  <a href="https://dustycloud.org/">Christine
67. Lemmer-Webber</a>
68. had asked me, ages ago, what I thought Guile should do about the web.
69. After thinking a bit, I concluded that it would be best to avoid
70. compromises when building an in-browser Guile: if you have to pollute
71. Guile to match what JavaScript offers, you might as well program in
72. JavaScript.  JS is cute of course, but Guile is a bit different in some
73. interesting ways, the most important of which is control: delimited
74. continuations, multiple values, tail calls, dynamic binding, threads,
75. and all that.  If Guile’s web bootie doesn’t pack all the funk in its
76. trunk, probably it’s just junk.</p><p>So I wrote up a plan something to which I attributed the name
77. <a href="https://lists.gnu.org/archive/html/guile-devel/2021-06/msg00005.html">tailification</a>.
78. In retrospect, this is simply a specific flavor of a
79. continuation-passing-style (CPS) transmutation, late in the compiler
80. pipeline.  I’ll elocute more in a future dispatch.  I
81. did end up writing the tailification pass back then; I could have continued to
82. target JS, but it was sufficiently annoying and I didn’t prosecute.  It
83. sat around unused for a few years, until Christine’s irresistable
84. charisma managed to conjure some resources for Hoot.</p><p>In the meantime, the <a href="https://wingolog.org/archives/2023/03/20/a-world-to-win-webassembly-for-the-rest-of-us">GC extension for WebAssembly
85. shipped</a>
86. (woot woot!), and to boot Hoot, I filled in the missing piece: a backend
87. for Guile’s compiler that tailified and then translated primitive
88. operations to snippets of WebAssembly.</p><p>It was, well, hirsute, but cute and it did compute, so we continued to
89. boot.  From this root we grew a small run-time library, written in raw
90. WebAssembly, used for slow-paths for the various primitive operations
91. that are part of Guile’s compiler back-end.  We filled out Guile
92. primcalls, in minute commits, growing the WebAssembly runtime library
93. and toolchain as we went.</p><p>Eventually we started constituting facilities defined in terms of those
94. primitives, via a Scheme prelude that was prepended to all programs,
95. within a nested lexical environment.  It was never our intention though
96. to drown the user’s programs in a sea of predefined bindings, as if the
97. ultimate program were but a vestigial inhabitant of the lexical
98. lake—don’t dilute the newt!, we would often say <i>[ed: we did not]</i>— so
99. eventually when the prelude became unmanageable, we finally figured out
100. how to do <a href="https://wingolog.org/archives/2024/01/05/scheme-modules-vs-whole-program-compilation-fight">whole-program compilation of a set of
101. modules</a>.</p><p>Then followed a long month in which I would uproot the loot from the
102. boot: take each binding from the prelude and reattribute it into an
103. appropriate module.  User code could import all the modules that suit,
104. as long as they were known to Hoot, but no others; it was only until we
105. added the ability for users to programmatically consitute an environment
106. from their modules that Hoot became a language implementation of any
107. repute.</p><p>Which brings us to the work of the last month, about which I cannot be
108. mute.  When you have existing Guile code that you want to distribute via
109. the web, Hoot required you transmute its module definitions into the
110. more precise R6RS syntax.  Precise, meaning that R6RS modules are
111. static, in a way that Guile modules, at least in absolute terms, are
112. not: Guile programs can use first-class accessors on the module systems
113. to pull out bindings.  This is yet another example of what I impute as
114. the original sin of 1990s language development, that modules are just
115. mutable hash maps.  You see it in Python, for example: because you don’t
116. know for sure to what values global names are bound, it is easy for any
117. discussion of what a particular piece of code means to end in dispute.</p><p>The question is, though, are the semantics of name binding in a language
118. fixed and absolute?  Once your language is booted, are its aspects
119. definitively attributed?  I think some perfection, in the sense of
120. becoming more perfect or more like the thing you should be, is something
121. to salute.  Anyway, in Guile it would be coherent with Scheme’s lexical
122. binding heritage to restitute some certainty as to the meanings of
123. names, at least in a default compilation node.  Lexical binding is,
124. after all, the foundation of the <a href="https://www.youtube.com/watch?v=LIEX3tUliHw">Macro Writer’s Statute of
125. Rights</a>.  Of course if you
126. are making a build for development purposes, not to distribute, then you
127. might prefer a build that marks all bindings as dynamic.  Otherwise I
128. think it’s reasonable to require the user to explicitly indicate which
129. definitions are denotations, and which constitute locations.</p><p>Hoot therefore now includes an implementation of the static semantics of
130. Guile’s <tt>define-module</tt>: it can load Guile modules directly, and as a
131. tribute, it also has an implementation of the ambient <tt>(guile)</tt> module
132. that constitutes the lexical soup of modules that aren’t <tt>#:pure</tt>.  (I
133. agree, it would be better if all modules were explicit about the
134. language they are written in—their imported bindings and so on—but there
135. is an existing corpus to accomodate; the point is moot.)</p><p>The astute reader (whom I salute!) will note that we have a full boot:
136. Hoot is a Guile.  Not an implementation to substitute the original, but
137. more of an alternate route to the same destination.  So, probably we
138. should scoot the two implementations together, to knock their boots, so
139. to speak, merging the offshoot Hoot into Guile itself.</p><p>But do I circumlocute: I can only plead a case of acute Hoot.  Tomorrow,
140. we elocute on a second axis of boot.  Until then, happy compute!</p></div></div>
141.    </content>
142.    <updated>2024-05-16T20:01:41Z</updated>
143.    <published>2024-05-16T20:01:41Z</published>
144.    <author>
145.      <name>Andy Wingo</name>
146.      <uri>https://wingolog.org/</uri>
147.    </author>
148.    <source>
149.      <id>https://wingolog.org/feed/atom</id>
150.      <link href="https://wingolog.org/" rel="alternate" type="text/html"/>
151.      <link href="https://wingolog.org/feed/atom" rel="self" type="application/atom+xml"/>
152.      <subtitle>A mostly dorky weblog by Andy Wingo</subtitle>
153.      <title>wingolog</title>
154.      <updated>2024-05-16T20:01:41Z</updated>
155.    </source>
156.  </entry>
157.  
158.  <entry xml:lang="en">
159.    <id>http://samthursfield.wordpress.com/?p=2419</id>
160.    <link href="https://samthursfield.wordpress.com/2024/05/16/status-update-16-05-2024-learning-async-rust/" rel="alternate" type="text/html"/>
161.    <title>Status update, 16/05/2024 – Learning Async Rust</title>
162.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">This is another month where too many different things happened to stick them all in one post together. So here’s a ramble on Rust, and there’s more to come in a follow up post. I first started learning Rust in late 2020. It took 3 attempts before I could start to make functional commandline apps, … <a class="more-link" href="https://samthursfield.wordpress.com/2024/05/16/status-update-16-05-2024-learning-async-rust/">Continue reading <span class="screen-reader-text">Status update, 16/05/2024 – Learning Async Rust</span></a></div>
163.    </summary>
164.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>This is another month where too many different things happened to stick them all in one post together. So here’s a ramble on Rust, and there’s more to come in a follow up post.</p>
165.  
166.  
167.  
168. <p>I first started learning Rust <a href="https://samthursfield.wordpress.com/2020/12/04/beginning-rust/">in late 2020</a>. It took 3 attempts before I could start to make functional commandline apps, and the current outcome of this is the <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/">ssam_openqa</a> tool, which I work on partly to develop my Rust skills. This month I worked on some intrusive changes to finally start using async Rust in the program.</p>
169.  
170.  
171.  
172. <h2 class="wp-block-heading">How it started</h2>
173.  
174.  
175.  
176. <p>Out of all the available modern languages I might have picked to learn, I picked Rust partly for the size and health of its community: every community has its issues, but Rust has no “BDFL” figure and no one corporation that employs all the core developers, both signs of a project that can last a long time. Look at GNOME, which is turning 27 this year.</p>
177.  
178.  
179.  
180. <p>Apart from the community, learning Rust improved the way I code in all languages, by forcing more risks and edge cases to the surface and making me deal with them explicitly in the design. The ecosystem of crates has most of what you could want (although there is quite a lot of experimentation and therefore “churn”, compared to older languages). It’s kind of addictive to know that when you’ve resolved all your compile time errors, you’ll have a program that reliably does what you want.</p>
181.  
182.  
183.  
184. <p>There are still some blockers to me adopting Rust everywhere I work (besides legacy codebases). The “cycle time” of the edit+compile+test workflow has a big effect on my happiness as a developer. The fastest incremental build of my simple CLI tool is 9 seconds, which is workable, and when there are compile errors (i.e. most of the time) its usually even faster. However, a release build might take 2 minutes. This is 3000 lines of code with <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/-/blob/main/Cargo.toml">18 dependencies</a>. I am wary of embarking on a larger project in Rust where the cycle time could be problematically slow.</p>
185.  
186.  
187.  
188. <p>Binary size is another thing, although I’ve learned several tricks to keep ssam_openqa at “only” 1.8MB. Use a minimal arg parser library instead of <a href="https://github.com/clap-rs/clap/issues/1365">clap</a>. Use <a href="https://github.com/neonmoe/minreq/">minreq</a> for HTTP. Follow the <a href="https://github.com/johnthagen/min-sized-rust">min-size-rust</a> guidelines. Its easy to pull in one convenient dependency that brings in a tree of 100 more things, unless you are careful. (This is a problem for C programmers too, but dependency handling in C is traditionally so horrible that we are already conditioned to avoid too many external helper libraries).</p>
189.  
190.  
191.  
192. <p>The third thing I’ve been unsure about until now is async Rust. I never immediately liked the model used by Rust and Python of having a complex event loop hidden in the background, and a magic <code>async</code> keyword that completely changes how a function is executed, and requires all other functions to be <code>async</code> such as you effectively have two *different* languages: the async variant, and the sync variant; and when writing library code you might need to provide two completely different APIs to do the same thing, one async and one sync. </p>
193.  
194.  
195.  
196. <p>That said, I don’t have a better idea for how to do async.</p>
197.  
198.  
199.  
200. <p>Complicating matters in Rust is the error messages, which can be mystifying if you hit an edge case (see below for where this bit me). So until now I learned to just use <a href="https://doc.rust-lang.org/std/thread/fn.spawn.html">thread::spawn</a> for background tasks, with a <a href="https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html">std::sync::mpsc</a> channel to pass messages back to the main thread, and use blocking IO everywhere. I see other projects doing the same.</p>
201.  
202.  
203.  
204. <h2 class="wp-block-heading">How it’s going</h2>
205.  
206.  
207.  
208. <p>My blissful ignorance came to an end due to changes in a dependency. I was using the <a href="https://github.com/websockets-rs/rust-websocket">websocket</a> crate in ssam_openqa, which embeds its own async runtime so that callers can use a blocking interface in a thread. I guess this is seen as a failed experiment, as the library is now “sluggishly” maintained, the dependencies are old, and the developers recommend <a href="https://github.com/snapview/tungstenite-rs">tungstenite</a> instead.</p>
209.  
210.  
211.  
212. <p>Tungstenite seems unusable from sync code for anything more than toy examples, you need an async wrapper such as <a href="https://github.com/sdroege/async-tungstenite/">async-tungstenite</a> (shout out to <a href="https://www.coaxion.net/">slomo</a> for this excellent library, by the way). So, I thought, I will need to port my *whole codebase* to use an async runtime and an async main loop.</p>
213.  
214.  
215.  
216. <p>I tried, and spent a few days lost in a forest of compile errors, but its never the correct approach to try and port code “in one shot” and without a plan. To make matters worse, websocket-rs embeds an *old* version of Rust’s <a href="https://docs.rs/futures/latest/futures/">futures</a> library. Nobody told me, but there is “futures 0.1” and “futures 0.3.” Only the latter works with the <code>await</code> keyword; if you <code>await</code> a future from futures 0.1, you’ll get an error about not implementing the expected trait. The docs don’t give any clues about this, eventually I discovered the <a href="https://docs.rs/futures/latest/futures/compat/struct.Compat01As03.html">Compat01As03 wrapper</a> which lets you convert types from futures 0.1 to futures 0.3. Hopefully you never have to deal with this as you’ll only see futures 0.1 on libraries with outdated dependencies, but, now you know.</p>
217.  
218.  
219.  
220. <p/>
221.  
222.  
223.  
224. <p>Even better, I then realized I could keep the threads and blocking IO around, and just start an async runtime in the websocket processing thread. So I did that <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/-/merge_requests/33">in its own MR</a>, gaining an integration test and squashing a few bugs in the process.</p>
225.  
226.  
227.  
228. <p>The key piece is <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/-/blob/main/src/helpers/isotovideo/control.rs?ref_type=heads#L119">here</a>:</p>
229.  
230.  
231.  
232. <pre class="wp-block-code"><code>use tokio::runtime;
233. use std::thread;
234.  
235. ...
236.  
237.    thread::spawn(move || {
238.        let runtime = runtime::Builder::new_current_thread()
239.            .enable_io()
240.            .build()
241.            .unwrap();
242.  
243.        runtime.block_on(async move {
244.            // Websocket event loop goes here
245. </code></pre>
246.  
247.  
248.  
249. <p>This code uses the tokio <a href="https://docs.rs/tokio/latest/tokio/runtime/struct.Builder.html#method.new_current_thread"><code>new_current_thread</code>()</a> function to create an async main loop out of the current thread, which can then use <a href="https://docs.rs/tokio/latest/tokio/runtime/struct.Runtime.html#method.block_on"><code>block_on</code>()</a> to run an async block and wait for it to exit. It’s a nice way to bring async “piece by piece” into a codebase that otherwise uses blocking IO, without having to rewrite everything up front.</p>
250.  
251.  
252.  
253. <p>I have some more work in progress to use <code>async</code> for the two main loops in ssam_openqa: these currently have manual polling loops that periodically check various message queue for events and then call <code>thread::sleep(250)</code>, which work fine in practice for processing low frequency control and status events, but it’s not the slickest nor most efficient way to write a main loop. The classy way to do it is using the <a href="https://tokio.rs/tokio/tutorial/select">tokio::select!</a> macro.</p>
254.  
255.  
256.  
257. <h2 class="wp-block-heading">When should you use async Rust?</h2>
258.  
259.  
260.  
261. <p>I was hoping for a simple answer to this question, so I asked my colleagues at Codethink where we have a number of Rust experts. </p>
262.  
263.  
264.  
265. <p>The problem is, cooperative task scheduling is a very complicated topic. If I convert my main loop to <code>async</code>, but I use the std library blocking IO primitives to read from stdin rather than tokio’s async IO, can Rust detect that and tell me I did something wrong? Well no, it can’t – you’ll just find that event processing stops while you’re waiting for input. Which may or may not even matter.</p>
266.  
267.  
268.  
269. <p>There’s no way automatically detect “syscall which might wait for user input” vs “syscall which might take a lot of CPU time to do something”, vs “user-space code which might not defer to the main loop for 10 minutes”; and each of these have the same effect of causing your event loop to freeze.</p>
270.  
271.  
272.  
273. <p>The best advice I got was to use <a href="https://github.com/tokio-rs/console">tokio console</a> to monitor the event loop and see if any tasks are running longer than they should. This looks like a really helpful debugging tool and I’m definitely going to try it out.</p>
274.  
275.  
276.  
277. <div class="wp-block-cover"><span class="wp-block-cover__background has-background-dim"/><img alt="Screenshot of tokio-console" class="wp-block-cover__image-background wp-image-2434" height="625" src="https://samthursfield.wordpress.com/wp-content/uploads/2024/05/image.png?w=1024" width="1024"/><div class="wp-block-cover__inner-container is-layout-flow wp-block-cover-is-layout-flow">
278. <p class="has-text-align-center has-large-font-size"/>
279. </div></div>
280.  
281.  
282.  
283. <p>So I emerge from the month a bit wiser about async Rust, no longer afraid to use it in practice, and best of all, wise enough to know that its not an “all or nothing” switch – its perfectly valid to mix and sync and async in different places, depending on what performance characteristics you’re looking for.</p>
284.  
285.  
286.  
287. <p/></div>
288.    </content>
289.    <updated>2024-05-16T12:10:18Z</updated>
290.    <published>2024-05-16T12:10:18Z</published>
291.    <category term="General"/>
292.    <category term="rust"/>
293.    <author>
294.      <name>Sam Thursfield</name>
295.    </author>
296.    <source>
297.      <id>https://samthursfield.wordpress.com</id>
298.      <logo>https://samthursfield.wordpress.com/wp-content/uploads/2020/10/cropped-favicon.png?w=32</logo>
299.      <link href="https://samthursfield.wordpress.com/feed/" rel="self" type="application/rss+xml"/>
300.      <link href="https://samthursfield.wordpress.com" rel="alternate" type="text/html"/>
301.      <link href="https://samthursfield.wordpress.com/osd.xml" rel="search" title="Sam Thursfield" type="application/opensearchdescription+xml"/>
302.      <link href="https://samthursfield.wordpress.com/?pushpress=hub" rel="hub" type="text/html"/>
303.      <subtitle>Software and technology from Galicia, Spain</subtitle>
304.      <title>Sam Thursfield</title>
305.      <updated>2024-05-16T13:56:03Z</updated>
306.    </source>
307.  </entry>
308.  
309.  <entry xml:lang="en-US">
310.    <id>https://blogs.gnome.org/chergert/?p=12157</id>
311.    <link href="https://blogs.gnome.org/chergert/2024/05/15/ptyxis-on-flathub/" rel="alternate" type="text/html"/>
312.    <title>Ptyxis on Flathub</title>
313.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">You can get Ptyxis on Flathub now if you would like to run the stable version rather than Nightly. Unless you’re interested in helping QA Ptyxis or contributing that is probably the Flatpak you want to have installed. Nightly builds of Ptyxis use the GNOME Nightly SDK meaning GTK from main (or close to it). … <a class="more-link" href="https://blogs.gnome.org/chergert/2024/05/15/ptyxis-on-flathub/">Continue reading <span class="screen-reader-text">Ptyxis on Flathub</span></a></div>
314.    </summary>
315.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>You can get <a href="https://flathub.org/apps/app.devsuite.Ptyxis">Ptyxis on Flathub</a> now if you would like to run the stable version rather than Nightly. Unless you’re interested in helping QA Ptyxis or contributing that is probably the Flatpak you want to have installed.</p>
316. <p>Nightly builds of Ptyxis use the GNOME Nightly SDK meaning GTK from <code>main</code> (or close to it). Living on “trunk” can be a bit painful when it goes through major transitions like is happening now with a move to Vulkan-by-default.</p>
317. <p>Enjoy!</p></div>
318.    </content>
319.    <updated>2024-05-15T20:35:43Z</updated>
320.    <published>2024-05-15T20:35:43Z</published>
321.    <author>
322.      <name>chergert</name>
323.    </author>
324.    <source>
325.      <id>https://blogs.gnome.org/chergert</id>
326.      <link href="https://blogs.gnome.org/chergert/feed/" rel="self" type="application/rss+xml"/>
327.      <link href="https://blogs.gnome.org/chergert" rel="alternate" type="text/html"/>
328.      <subtitle>Details of Christian's work on GNOME</subtitle>
329.      <title>Happenings in GNOME</title>
330.      <updated>2024-05-15T20:35:43Z</updated>
331.    </source>
332.  </entry>
333.  
334.  <entry>
335.    <id>tag:blogger.com,1999:blog-5968355124473522212.post-5007812004593570231</id>
336.    <link href="https://nibblestew.blogspot.com/feeds/5007812004593570231/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
337.    <link href="https://nibblestew.blogspot.com/2024/05/generative-non-ai.html#comment-form" rel="replies" title="1 Comments" type="text/html"/>
338.    <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/5007812004593570231" rel="edit" type="application/atom+xml"/>
339.    <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/5007812004593570231" rel="self" type="application/atom+xml"/>
340.    <link href="https://nibblestew.blogspot.com/2024/05/generative-non-ai.html" rel="alternate" title="Generative non-AI" type="text/html"/>
341.    <title>Generative non-AI</title>
342.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><a href="https://www.ign.com/videos/game-scoop-768-square-enix-takes-the-l">In last week's episode of the Game Scoop podcast</a> an idea was floated that modern computer game names are uninspiring and that better ones could be made by picking random words from existing NES titles. This felt like a fun programming challenge so I went and implemented it. Code and examples can be found <a href="https://github.com/jpakkane/nesnamegen/">in this GH repo</a>.</p><p>Most of the game names created in this way are word salad gobbledigook or literally translated obscure anime titles (<i>Prince Turtles Blaster Family</i>). Running it a few times does give results that are actually quite interesting. They range from games that really should exist (<i>Operation Metroid</i>) to surprisingly reasonable (<i>Gumshoe Foreman's Marble Stadium</i>), to ones that actually made me laugh out loud (<i>Punch-Out! Kids</i>). Here's a list of some of my favourites:</p><ul><li>Ice Space Piano</li><li>Castelian Devil Rainbow Bros.</li><li>The Lost Dinosaur Icarus</li><li>Mighty Hoops, Mighty Rivals</li><li>Rad Yoshi G</li><li>Snake Hammerin'</li><li>MD Totally Heavy</li><li>Disney's Die! Connors</li><li>Monopoly Ransom Manta Caper!</li><li>Revenge Marble</li><li>Kung-Fu Hogan's F-15</li><li>Sinister P.O.W.</li><li>Duck Combat Baseball</li></ul><p>I emailed my findings back to the podcast host and they actually discussed it in this week's show (<a href="https://www.ign.com/videos/game-scoop-769-its-a-little-hard-to-believe-in-xbox-right-now">video here starting at approximately 35 minutes</a>). All in all this was an interesting exercise. However pretty quickly after finishing the project I realized that doing things yourself is no longer what the cool kids are doing. Instead this is the sort of thing that is seemingly tailor-made for AI. All you have to do is to type in a prompt like "create 10 new titles for video games by only taking words from existing NES games" and post that to tiktokstagram.</p><p>I tried that and the results were absolute garbage. Since the prompt has to have the words "video game" and "NES", and LLMs work solely on the basis of "what is the most common thing (i.e. popular)", the output consists almost entirely of the most well known NES titles with maybe some words swapped. I tried to guide it by telling it to use "more random" words. The end result was a list of ten games of which eight were alliterative. So much for randomness.</p><p>But more importantly every single one of the recommendations the LLM created was boring. Uninspired. Bland. Waste of electricity, basically.</p><p>Thus we find that creating a list of game names with an LLM is easy but the end result is worthless and unusable. Doing the same task by hand did take a bit more effort but the end result was miles better because it found new and interesting combinations that a "popularity first" estimator seem to not be able to match. Which matches the preconception I had about LLMs from prior tests and seeing how other people have used them.</p></div>
343.    </content>
344.    <updated>2024-05-14T17:47:00Z</updated>
345.    <published>2024-05-14T17:47:00Z</published>
346.    <author>
347.      <name>Jussi</name>
348.      <email>noreply@blogger.com</email>
349.      <uri>http://www.blogger.com/profile/03370287682352908292</uri>
350.    </author>
351.    <source>
352.      <id>tag:blogger.com,1999:blog-5968355124473522212</id>
353.      <author>
354.        <name>Jussi</name>
355.        <email>noreply@blogger.com</email>
356.        <uri>http://www.blogger.com/profile/03370287682352908292</uri>
357.      </author>
358.      <link href="https://nibblestew.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
359.      <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default" rel="self" type="application/atom+xml"/>
360.      <link href="https://nibblestew.blogspot.com/" rel="alternate" type="text/html"/>
361.      <link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
362.      <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default?start-index=26&amp;max-results=25" rel="next" type="application/atom+xml"/>
363.      <subtitle>A gathering of development thoughts of Jussi Pakkanen. Some of you may know him as the creator of the Meson build system. jpakkane at gmail dot com</subtitle>
364.      <title>Nibble Stew</title>
365.      <updated>2024-05-17T14:06:49Z</updated>
366.    </source>
367.  </entry>
368.  
369.  <entry>
370.    <id>https://wingolog.org/2024/05/13/partitioning-pitfalls-for-generational-collectors</id>
371.    <link href="https://wingolog.org/archives/2024/05/13/partitioning-pitfalls-for-generational-collectors" rel="alternate" type="text/html"/>
372.    <title>partitioning pitfalls for generational collectors</title>
373.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><div><p>You might have heard of long-pole problems: when you are packing a
374. tent, its bag needs to be at least as big as the longest pole.  (This is
375. my preferred etymology; <a href="https://devblogs.microsoft.com/oldnewthing/20080805-00/?p=21373">there are
376. others</a>.)
377. In garbage collection, the long pole is the longest chain of object
378. references; there is no way you can algorithmically speed up
379. pointer-chasing of (say) a long linked-list.</p><p>As a GC author, some of your standard tools can mitigate the long-pole
380. problem, and some don’t apply.</p><p><i>Parallelism</i> doesn’t help: a baby takes 9 months, no matter how many
381. people you assign to the problem.  You need to visit each node in the
382. chain, one after the other, and having multiple workers available to
383. process those nodes does not get us there any faster.  Parallelism does
384. help in general, of course, but doesn’t help for long poles.</p><p>You can apply <i>concurrency</i>: instead of stopping the user’s program (the
385. <i>mutator</i>) to enumerate live objects, you trace while the mutator is
386. running.  This can happen on mutator threads, interleaved with
387. allocation, via what is known as <i>incremental</i> tracing.  Or it can
388. happen in dedicated tracing threads, which is what people usually mean
389. when they refer to <i>concurrent</i> tracing.  Though it does impose some
390. coordination overhead on the mutator, the pause-time benefits are such
391. that most production garbage collectors do trace concurrently with the
392. mutator, if they have the development resources to manage the
393. complexity.</p><p>Then there is <i>partitioning</i>: instead of tracing the whole graph all the
394. time, try to just trace part of it and just reclaim memory for that
395. part.  This bounds the size of a long pole—it can’t be bigger than the partition you trace—and so tracing a graph subset should reduce total pause
396. time.</p><p>The usual way to partition is <i>generational</i>, in which the main program
397. allocates into a <i>nursery</i>, and objects that survive a few collections
398. then get promoted into <i>old space</i>.  But there may be other partitions,
399. for example to put <a href="https://wingolog.org/archives/2022/06/20/blocks-and-pages-and-large-objects">“large
400. objects”</a>
401. (for example, bigger than a few virtual memory pages) in their own
402. section, to be managed with their own algorithm.</p><h3>partitions, take one</h3><p>And that brings me to today’s article: generational partitioning has a
403. failure mode which manifests itself as spurious out-of-memory.  For
404. example, in V8, running this small JavaScript program that repeatedly allocates
405. a 1-megabyte buffer grows to consume all memory in the system and
406. eventually panics:</p><pre class="pre-js">while (1) new Uint8Array(1e6);
407. </pre><p>This is a funny result, to say the least.  Let’s dig in a bit to see
408. why.</p><p>First off, note that allocating a 1-megabyte Uint8Array makes a <i>large
409. object</i>, because it is <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/common/globals.h;l=581-588">bigger than half a V8
410. page</a>,
411. which is <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/base/build_config.h;l=60-77.">256 kB on most
412. systems</a>
413. There is a backing store for the array that will get allocated into the
414. large object space, and then the JS object wrapper that gets allocated
415. in the young generation of the regular object space.</p><p>Let’s imagine the heap consists of the nursery, the old space, and a
416. large object space (<i>lospace</i>, for short).  (See the next section for a
417. refinement of this model.)  In the loop, we cause allocation in the
418. nursery and the lospace.  When the nursery starts to get full, we run a
419. <i>minor</i> collection, to trace the newly allocated part of the object
420. graph, possibly promoting some objects to the old generation.</p><p>Promoting an object adds to the byte count in the old generation.  You
421. could say that promoting causes allocation in the old-gen, though it
422. might happen just on an accounting level if an object is promoted in
423. place.  In V8, old-gen allocation is subject to a
424. <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/heap.h;drc=41d53a863ef269e6d53fea38cc1d3feda6c3df78;l=2240">limit</a>,
425. and that limit is set by a <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/heap.cc;l=2698;drc=41d53a863ef269e6d53fea38cc1d3feda6c3df78">gnarly series of
426. heuristics</a>.
427. Exceeding the limit will cause a <i>major</i> GC, in which the whole heap is
428. traced.</p><p>So, minor collections cause major collections via promotion.  But what
429. if a minor collection never promotes?  This can happen in
430. request-oriented workflows, in which a request comes in, you handle it
431. in JS, write out the result, and then handle the next.  If the nursery is at least as large as the memory allocated in one request, no object will ever survive more than one collection.  But in our <tt>new Uint8Array(1e6)</tt> example above, we are allocating
432. to newspace and the lospace.  If we never cause promotion, we will
433. always collect newspace but never trigger the full GC that would also
434. collect the large object space, triggering this out-of-memory
435. phenomenon.</p><h3>partitions, take two</h3><p>In general, the phenomenon we are looking for is nursery allocations
436. that cause non-nursery allocations, where those non-nursery allocations
437. will not themselves bring about a major GC.</p><p>In our example above, it was a typed array object with an associated
438. lospace backing store, assuming the lospace allocation wouldn’t
439. eventually trigger GC.  But V8’s heap is not exactly like our model, for
440. one because it actually has separate nursery and old-generation
441. lospaces, and for two because allocation to the old-generation lospace
442. does count towards the old-gen allocation limit.  And yet, that simple
443. does still blow through all memory.  So what is the deal?</p><p>The answer is that V8’s heap now has <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/heap.h;l=764-822">around two dozen spaces</a>, and allocations to some of those spaces escape the limits and allocation counters.  In this
444. case, <a href="https://v8.dev/blog/sandbox">V8’s sandbox</a> makes the link between
445. the JS typed array object and its backing store pass through a <a href="https://docs.google.com/document/d/1V3sxltuFjjhp_6grGHgfqZNK57qfzGzme0QTk0IXDHk/edit#heading=h.xzptrog8pyxf">table of
446. indirections</a>.
447. At each allocation, we make an object in the nursery, allocate a backing
448. store in the nursery lospace, and then allocate a new entry in the
449. external pointer table, storing the index of that entry in the JS
450. object.  When the object needs to get its backing store, it dereferences
451. the corresponding entry in the external pointer table.</p><p>Our tight loop above would therefore cause an allocation (in the
452. external pointer table) that itself would not hasten a major collection.</p><p>Seen this way, one solution immediately presents itself: maybe we should
453. find a way to make external pointer table entry allocations trigger a GC
454. based on some heuristic, perhaps the old-gen allocated bytes counter.
455. But then you have to actually trigger GC, and this is annoying and not
456. always possible, as EPT entries can be allocated in response to a
457. pointer write.  <a href="https://issues.chromium.org/issues/40643874#comment9">V8 hacker Michael Lippautz summed up the issue in a
458. comment</a> that can
459. be summarized as “it’s gnarly”.</p><p>In the end, <a href="https://issues.chromium.org/issues/40643874#comment24">it would be better if new-space allocations did not cause
460. old-space
461. allocations</a>.  We
462. should separate the external pointer table (EPT) into old and new
463. spaces.  Because there is at most one “host” object that is associated
464. with any EPT entry—if it’s zero objects, the entry is dead—then the
465. heuristics that apply to host objects will do the right thing with
466. regards to EPT entries.</p><p>A couple weeks ago, I <a href="https://source.chromium.org/chromium/_/chromium/v8/v8/+/90f276be1122336c6ff7b808054fb183af7a2a9e">landed a
467. patch</a>
468. to do this.  It was much easier said than done; the patch went through
469. upwards of 40 revisions, as it took me a while to understand the
470. delicate interactions between the concurrent and parallel parts of the
471. collector, which were themselves evolving as I was working on the patch.</p><p>The challenge mostly came from the fact that <a href="https://wingolog.org/archives/2023/12/08/v8s-mark-sweep-nursery">V8 has two nursery
472. implementations that operate in different
473. ways</a>.</p><p>The semi-space nursery (the <i>scavenger</i>) is a parallel stop-the-world
474. collector, which is relatively straightforward... except that there can
475. be a concurrent/incremental major trace in progress while the scavenger
476. runs (a so-called <i>interleaved</i> minor GC).  External pointer table
477. entries have mark bits, which the scavenger collector will want to use to
478. determine which entries are in use and which can be reclaimed, but the
479. concurrent major marker will also want to use those mark bits.  In the
480. end we decided that if a major mark is in progress, an interleaved
481. collection will neither mark nor sweep the external pointer table
482. nursery; a major collection will finish soon, and reclaiming dead EPT entries will be its
483. responsibility.</p><p>The <a href="https://wingolog.org/archives/2023/12/08/v8s-mark-sweep-nursery">minor mark-sweep
484. nursery</a>
485. does not run concurrently with a major concurrent/incremental trace,
486. which is something of a relief, but it does run concurrently with the
487. mutator.  When we promote a page, we also need to promote all EPT
488. entries for objects on that page.  To keep track of which objects have
489. external pointers, we had to add a new <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/memory-chunk-layout.h;l=33?q=survivor_to_external_pointer">remembered
490. set</a>,
491. built up during a minor trace, and cleared when the page is swept (also
492. lazily / concurrently).  Promoting a page <a href="https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/minor-mark-sweep.cc;l=872?q=survivor_to_external_pointer">iterates through that set,
493. evacuating EPT entries to the old
494. space</a>.
495. This is additional work during the stop-the-world pause, but hopefully
496. it is not too bad.</p><p>To be honest I don’t have the performance numbers for this one.  It
497. rides the train this week to Chromium 126 though, and hopefully it fixes
498. this problem in a robust way.</p><h3>partitions, take three</h3><p>The V8 sandboxing effort has sprouted a number of <a href="https://docs.google.com/document/d/1FM4fQmIhEqPG8uGp5o9A-mnPB5BOeScZYpkHjo0KKA8/edit#heading=h.fg3qxf1x0p2q">indirect
499. tables</a>:
500. <a href="https://docs.google.com/document/d/1V3sxltuFjjhp_6grGHgfqZNK57qfzGzme0QTk0IXDHk/edit#heading=h.xzptrog8pyxf">external
501. pointers</a>,
502. <a href="https://issues.chromium.org/issues/42204529">external buffers</a>,
503. <a href="https://docs.google.com/document/d/1IrvzL4uX_Zv0k2Iakdp_q_z33bj-qlYF5IesGpXW0fM/edit#heading=h.xzptrog8pyxf">trusted
504. objects</a>,
505. and <a href="https://docs.google.com/document/d/1CPs5PutbnmI-c5g7e_Td9CNGh5BvpLleKCqUnqmD82k/edit#heading=h.xzptrog8pyxf">code
506. objects</a>.
507. Also recently to better integrate with compressed pointers, there is
508. also a <a href="https://chromium-review.googlesource.com/c/v8/v8/+/5392814">table for V8-to-managed-C++ (Oilpan)
509. references</a>.
510. I expect the Oilpan reference table will soon grow a nursery along the
511. same lines as the regular external pointer table.</p><p>In general, if you have a generational partition of your main object
512. space, it would seem that you almost always need a generational
513. partition of every other space.  Otherwise either you cause new
514. allocations to occur in what is effectively an old space, perhaps
515. needlessly hastening a major GC, or you forget to track allocations in
516. that space, leading to a memory leak.  If the generational hypothesis
517. applies for a wrapper object, it probably also applies for any auxiliary
518. allocations as well.</p><h3>fin</h3><p>I have a few cleanups remaining in this area but I am relieved to have
519. landed this patch, and pleased to have spent time under the hood of V8’s
520. collector.  Many many thanks to Samuel Groß, Michael Lippautz, and
521. Dominik Inführ for their review and patience.  Until the next
522. cycle, happy allocating!</p></div></div>
523.    </content>
524.    <updated>2024-05-13T13:03:26Z</updated>
525.    <published>2024-05-13T13:03:26Z</published>
526.    <author>
527.      <name>Andy Wingo</name>
528.      <uri>https://wingolog.org/</uri>
529.    </author>
530.    <source>
531.      <id>https://wingolog.org/feed/atom</id>
532.      <link href="https://wingolog.org/" rel="alternate" type="text/html"/>
533.      <link href="https://wingolog.org/feed/atom" rel="self" type="application/atom+xml"/>
534.      <subtitle>A mostly dorky weblog by Andy Wingo</subtitle>
535.      <title>wingolog</title>
536.      <updated>2024-05-16T20:01:41Z</updated>
537.    </source>
538.  </entry>
539.  
540.  <entry>
541.    <id>tag:blogger.com,1999:blog-5620128670216603593.post-1417939162197944782</id>
542.    <link href="https://ml4711.blogspot.com/feeds/1417939162197944782/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
543.    <link href="https://ml4711.blogspot.com/2024/05/may-maps.html#comment-form" rel="replies" title="2 Comments" type="text/html"/>
544.    <link href="https://www.blogger.com/feeds/5620128670216603593/posts/default/1417939162197944782" rel="edit" type="application/atom+xml"/>
545.    <link href="https://www.blogger.com/feeds/5620128670216603593/posts/default/1417939162197944782" rel="self" type="application/atom+xml"/>
546.    <link href="https://ml4711.blogspot.com/2024/05/may-maps.html" rel="alternate" title="May Maps" type="text/html"/>
547.    <title>May Maps</title>
548.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSHu87GAV4L1GpEIb6X6jEuSKfuCPVDhKYeBDmR8sq0c2dnfhbNYUZrTDJfT_ULXZ6qMtj7C3dgsYctRRUgBBAS5d68tu5o1LU8PMr5cNNmDYUHFc-J6poU4nd8HzcAqY9GmQN6B27RS2PY2XAMJMfYGO_bWxw22oxQrb8XjbfC83-vd57T4Bvuzmn/s655/about-47.alpha.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSHu87GAV4L1GpEIb6X6jEuSKfuCPVDhKYeBDmR8sq0c2dnfhbNYUZrTDJfT_ULXZ6qMtj7C3dgsYctRRUgBBAS5d68tu5o1LU8PMr5cNNmDYUHFc-J6poU4nd8HzcAqY9GmQN6B27RS2PY2XAMJMfYGO_bWxw22oxQrb8XjbfC83-vd57T4Bvuzmn/s16000/about-47.alpha.png"/></a></div><p/><p>It's about time for the spring update of goings on in Maps!</p><p>There's been some changes going on since the release of 46.</p><p><br/></p><h2 style="text-align: left;">Vector Map by Default</h2><p style="text-align: left;">The vector map is now being used by default, and with it Maps supports dark mode (also the old raster tiles has been retired, though there still exists the hidden feature of running with a local tile directory. Which was never really intended for general use but more as a way to experiment with offline map support). The plan will be to eventually support proper offline map support with a way to download areas in a more user-friendly and organized way then to provide a raw path…).<br/></p><h2 style="text-align: left;">Dark Improvements</h2><p style="text-align: left;">Following the introduction of dark map support the default rendering of public transit routes and lines has been improved for the dark mode to give better contrast (something that trickier before when the map view was always light even when the rest of the UI, such as the sidebar itinerary was shown in dark mode).</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNGxr88v1txujKll8nBHGXaXfePnKvMUDxWHjTtTPqNhJfPzEyCMKVIYC_M5ASsT7Rtk4v-lKHjebJbznimIYiRfioLeb9iAoykxb4t-WYNZG2ktNCq1G1DRlRkzBJgJjW8tgmtGYeH0QWEdYGZNNaTNjth_6-P9ud928OYL0SHVc44iE2Enm698ux/s550/dark-transit.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNGxr88v1txujKll8nBHGXaXfePnKvMUDxWHjTtTPqNhJfPzEyCMKVIYC_M5ASsT7Rtk4v-lKHjebJbznimIYiRfioLeb9iAoykxb4t-WYNZG2ktNCq1G1DRlRkzBJgJjW8tgmtGYeH0QWEdYGZNNaTNjth_6-P9ud928OYL0SHVc44iE2Enm698ux/s16000/dark-transit.png"/></a></div><br/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh40YmVh0LfMxIUdN00SFkz3zmvDEAMBCvaHggYEXBH2JbfYb3Gt3NXNkikimVx3cztxiTcSt8KvwKlyf5zfLE01eSdeA1PgYSS4AqxDli-Q5TedVgrZ_-6JIlNPxGyFOlB7Q6ZGDNzGJEKv6YEw-DyPzN6nbw04YlJPZIdGv8xE4SLvdh46VI6ppaU/s831/dark-transitline.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh40YmVh0LfMxIUdN00SFkz3zmvDEAMBCvaHggYEXBH2JbfYb3Gt3NXNkikimVx3cztxiTcSt8KvwKlyf5zfLE01eSdeA1PgYSS4AqxDli-Q5TedVgrZ_-6JIlNPxGyFOlB7Q6ZGDNzGJEKv6YEw-DyPzN6nbw04YlJPZIdGv8xE4SLvdh46VI6ppaU/s16000/dark-transitline.png"/></a></div><br/><h2 style="text-align: left;">More Transit Mode Icons</h2><p style="text-align: left;">Jakub Steiner and Sam Hewitt has been working on designing icons for some additional modes of transit, such as trolley buses, taxi, and monorail.<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj39dMtPMXfxsf5dPtmR3L9OmtoQpKl4iMrtSxINEiUjVM0ifyQoikbd8N8OW82zEI8QA5gCVR10nytAthdvVAC876fV53T6idXssogn11B9IZf6hJrpOkiVThxivJXxZ6-2EZYpUgsOIxQcvnqcjnURXTsbxJ_CBfIDbh2-BlAyHRNCr2Jw_NHQzFW/s685/trolley-bus.png" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj39dMtPMXfxsf5dPtmR3L9OmtoQpKl4iMrtSxINEiUjVM0ifyQoikbd8N8OW82zEI8QA5gCVR10nytAthdvVAC876fV53T6idXssogn11B9IZf6hJrpOkiVThxivJXxZ6-2EZYpUgsOIxQcvnqcjnURXTsbxJ_CBfIDbh2-BlAyHRNCr2Jw_NHQzFW/s16000/trolley-bus.png"/></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Trolley bus routes<br/></td></tr></tbody></table><br/></p><p style="text-align: left;">This screenshot was something I “mocked” by changing the icon for regular bus to temporarily use the newly designed trolley bus icon as we don't currently have any supported transit route provider in Maps currently that exposed trolley bus routes. I originally made this for an excursion with a vintage trolley bus I was going to attend, but that was cancelled in the last minute because of technical issues.<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPc3rZqNAooRH7Z17Drr1smIsJWhUkzupKgZwJw2Djn66tOR4i31WAWgXc9myfH0hN3Kx5o4XDWV0oSAe-wzyW0jzKirdRoeBpM3W3j5F7lwbtohoDVT62aqsCmqZ2-9TET4vDuHG1cbvXJ5GVwOGOKhs39U-4blPCARpD8ZBZS5VpfdFWYLNRU5CP/s652/taxi-station.png" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPc3rZqNAooRH7Z17Drr1smIsJWhUkzupKgZwJw2Djn66tOR4i31WAWgXc9myfH0hN3Kx5o4XDWV0oSAe-wzyW0jzKirdRoeBpM3W3j5F7lwbtohoDVT62aqsCmqZ2-9TET4vDuHG1cbvXJ5GVwOGOKhs39U-4blPCARpD8ZBZS5VpfdFWYLNRU5CP/s16000/taxi-station.png"/></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Showing a taxi station<br/></td></tr></tbody></table><br/></p><p style="text-align: left;">And above we have the new taxi icon (this could be used both for showing on-demand communal taxi transit and for taxi stations on the map.</p><p style="text-align: left;">These icons have not yet been merged into Maps, as there's still some work going on finalizing their design. But I thought I still wanted to show them here…</p><h2 style="text-align: left;">Brand Logos</h2><p style="text-align: left;">For a long time we have shown a title image from Wikidata or Wikipedia for places when available. Now we show a logo image (using the Wikidata reference for the brand of a venue) when available, and the place has no dedicated article).</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU8BWH9MpergcFK2bt7mu4UanLBxsLibdXdgdTw4CA8yZDIz7yfSWV4otnAySvno06oYNYOSkHs390pLWfcKd9qT00RK6MSH1hCL_2LpbxUy2hvSBS6-S_At57JlgQ_J88i33VTcVd9czjgBeTFY-liKWGIFto1xEq-_zneCq9OQm8bHySOokLD9ZX/s634/place-logo.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU8BWH9MpergcFK2bt7mu4UanLBxsLibdXdgdTw4CA8yZDIz7yfSWV4otnAySvno06oYNYOSkHs390pLWfcKd9qT00RK6MSH1hCL_2LpbxUy2hvSBS6-S_At57JlgQ_J88i33VTcVd9czjgBeTFY-liKWGIFto1xEq-_zneCq9OQm8bHySOokLD9ZX/s16000/place-logo.png"/></a></div><h2 style="text-align: left;">Explaining Place Types</h2><p style="text-align: left;">As sometimes it can be a bit hard to determine the exact type from the icons shown on the map. And especially for more generic types, such as shops where we have dedicated icons for some, and a generic icon. We now show the type also in the place bubble (using the translations extracted from the iD OSM editor). <br/></p><p/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVy5CaCUixIlWqghXkYNrNgCcx52y36cMjtYJ-CvL2ky0OJ7R3OqJymljyJzmR_s7rkB_E4eMtrCv8IvAF-0Y0ScHsFRYH4UOdTQsOl4aOjK6jbT0KUxG6RqX9rHMH4oiI0OvH1HE7ohVCRjzHXBeIgMBDLQPbwsDkPIBceIutxDx1N0-ugRl8lJOl/s494/place-type-and-name.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVy5CaCUixIlWqghXkYNrNgCcx52y36cMjtYJ-CvL2ky0OJ7R3OqJymljyJzmR_s7rkB_E4eMtrCv8IvAF-0Y0ScHsFRYH4UOdTQsOl4aOjK6jbT0KUxG6RqX9rHMH4oiI0OvH1HE7ohVCRjzHXBeIgMBDLQPbwsDkPIBceIutxDx1N0-ugRl8lJOl/s16000/place-type-and-name.png"/></a></div><br/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhg90EFQOid7GmN61kJsCFH4-oSmq6HNjZ2EOkUEOaBwc_7lqtKm5wdnc1gMnFNCk3Iysjrgud8nMlsBhAbZJw9pjZEiUaZhsgYpnEj_vykf4lUn3iz_zbSiGLPaZfNyCGQh9m-NWUeJOukd8-JSa0UcyOxCUTVN2A7ErugtX6plirKxkril6NuVrFj/s610/place-type-and-wikipedia.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhg90EFQOid7GmN61kJsCFH4-oSmq6HNjZ2EOkUEOaBwc_7lqtKm5wdnc1gMnFNCk3Iysjrgud8nMlsBhAbZJw9pjZEiUaZhsgYpnEj_vykf4lUn3iz_zbSiGLPaZfNyCGQh9m-NWUeJOukd8-JSa0UcyOxCUTVN2A7ErugtX6plirKxkril6NuVrFj/s16000/place-type-and-wikipedia.png"/></a></div><p>Places with a name shows the icon and type description below the name, dimmed.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinnPm2tgNpf2abIT_va_Pr8F7ekE3DGe8dcyt2D4ZUGCv7L5ZGMwGb3uxPm9uaEt8q0AyE7m0ziszZ08wyhlKtKi0LOEMJ_gtClfTSVk6W-ya-0-JJ3WH2ojIWVRhKRMaNZmQUpYYg1B8l5ljGRIUT56zkO_Acm-pBWdlmhgeF9OKfQUH8iidJPhLD/s494/place-type-noname.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinnPm2tgNpf2abIT_va_Pr8F7ekE3DGe8dcyt2D4ZUGCv7L5ZGMwGb3uxPm9uaEt8q0AyE7m0ziszZ08wyhlKtKi0LOEMJ_gtClfTSVk6W-ya-0-JJ3WH2ojIWVRhKRMaNZmQUpYYg1B8l5ljGRIUT56zkO_Acm-pBWdlmhgeF9OKfQUH8iidJPhLD/s16000/place-type-noname.png"/></a></div><br/><p>For unnamed places we show the icon and type instead of the name, in the same bold style as the name would normally use.</p><h2 style="text-align: left;">Additional Things</h2><p style="text-align: left;">Another detail worth mentioning is that you can now clear the currently showing route from the context menu so you won't have to open the sidebar again and manually erase the filled in destinations.</p><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"/><div class="separator" style="clear: both; text-align: center;"> <br/></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZsa9n3djjL1ST82w6EzH4iKjr66FdtboLevb28K_Ns5yPC4CzasQukd1et5U2gT6LD9lsN9ds7BZNi3CLD0Y3mq7_8aNIQrkMHC61IKVylqVF2hv13j9Fy-DDb5a__ObME805QoX_w6UaD-ub_xBRnn1AX4hLWAucR3OAyh9GxG625s6JBD_lJ-AT/s655/clear-route2.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZsa9n3djjL1ST82w6EzH4iKjr66FdtboLevb28K_Ns5yPC4CzasQukd1et5U2gT6LD9lsN9ds7BZNi3CLD0Y3mq7_8aNIQrkMHC61IKVylqVF2hv13j9Fy-DDb5a__ObME805QoX_w6UaD-ub_xBRnn1AX4hLWAucR3OAyh9GxG625s6JBD_lJ-AT/s16000/clear-route2.png"/></a></div><p/><p>Another improvement is that if you already enter a starting point with ”Route from Here“, or enter an address in the sidebar and then use the “Directions”  button from a place bubble, that starting point will now be used instead of the current location.</p><p>Besides this, also some old commented-out code was removed… but there's no screenshots of that, I'm afraid ☺</p></div>
549.    </content>
550.    <updated>2024-05-11T13:23:00Z</updated>
551.    <published>2024-05-11T13:23:00Z</published>
552.    <category scheme="http://www.blogger.com/atom/ns#" term="gnome"/>
553.    <category scheme="http://www.blogger.com/atom/ns#" term="gnome maps"/>
554.    <category scheme="http://www.blogger.com/atom/ns#" term="maps"/>
555.    <author>
556.      <name>Marcus Lundblad</name>
557.      <email>noreply@blogger.com</email>
558.      <uri>http://www.blogger.com/profile/02923955229568787222</uri>
559.    </author>
560.    <source>
561.      <id>tag:blogger.com,1999:blog-5620128670216603593</id>
562.      <category term="gnome"/>
563.      <category term="maps"/>
564.      <category term="gnome maps"/>
565.      <category term="openstreetmap"/>
566.      <category term="routing"/>
567.      <category term="transit"/>
568.      <category term="FOSDEM"/>
569.      <category term="excursions"/>
570.      <category term="GNOME Maps 3.34"/>
571.      <category term="GNOME Maps 3.36"/>
572.      <category term="GNOME Maps 3.38"/>
573.      <category term="gpx"/>
574.      <category term="gtfs"/>
575.      <category term="gtk+"/>
576.      <category term="gtk4."/>
577.      <category term="libshumate"/>
578.      <category term="summer"/>
579.      <category term="travel"/>
580.      <author>
581.        <name>Marcus Lundblad</name>
582.        <email>noreply@blogger.com</email>
583.        <uri>http://www.blogger.com/profile/02923955229568787222</uri>
584.      </author>
585.      <link href="https://ml4711.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
586.      <link href="https://www.blogger.com/feeds/5620128670216603593/posts/default" rel="self" type="application/atom+xml"/>
587.      <link href="https://ml4711.blogspot.com/" rel="alternate" type="text/html"/>
588.      <link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
589.      <link href="https://www.blogger.com/feeds/5620128670216603593/posts/default?start-index=26&amp;max-results=25" rel="next" type="application/atom+xml"/>
590.      <title>The Maps and Geo Blog</title>
591.      <updated>2024-05-11T17:28:13Z</updated>
592.    </source>
593.  </entry>
594.  
595.  <entry>
596.    <id>https://medium.com/p/6d119cb1e981</id>
597.    <link href="https://medium.com/@txnmxy3/acrostic-generator-part-one-6d119cb1e981?source=rss-7808d13499aa------2" rel="alternate" type="text/html"/>
598.    <title>Acrostic Generator: Part one</title>
599.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>It’s been a while since my last blog post, which was about my Google Summer of Code project. Even though it has been months since I completed GSoC, I have continued working on the project, increasing acrostic support in Crosswords.</p><p>We’ve added support for loading Acrostic Puzzles in Crosswords, but now it’s time to create some acrostics.</p><p>Now that Crosswords has acrostic support, I can use screenshots to help explain what an acrostic is and how the puzzle works.</p><p>Let’s load an <a href="https://gitlab.gnome.org/jrb/crosswords/-/blob/master/puzzle-sets/devel-puzzles/acrostic-test.ipuz?ref_type=heads">Acrostic</a> in Crosswords first.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*1JvMKNGO1KCYOlkiQ7QJ7w.png"/><figcaption>Acrostic Puzzle loaded in Crosswords</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/461/1*TDB8DXsUFSfSTSbPr-PZRQ.png"/></figure><p>The main grid here represents the <strong>QUOTE</strong>: “<em>CARNEGIE VISITED PRINCETON…</em>” and if we read out the first letter of each clue answer (displayed on the right) it forms the <strong>SOURCE</strong>. For example, in the image above, name of the author is “<em>DAVID ….”</em>. <br/>Now, the interesting part is answers for the clues fit it in the SOURCE.</p><p>Let’s consider another small example:<br/><strong>QUOTE</strong>: <em>“To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.”</em><br/><strong>AUTHOR</strong>: “<em>Ralph Waldo Emerson”</em></p><p>If you see correctly, letters of SOURCE here are part of the QUOTE. One set of answers to clues could be:</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/111/1*p3cgNRJyQlBGHOzJtJsOkg.png"/><figcaption>Solutions generated using AcrosticGenerator. Read the first letter of each Answer from top to bottom. It forms ‘Ralph Waldo Emerson’.</figcaption></figure><p><strong>Coding the Acrostic Generator</strong></p><p>As seen above, to create an acrostic, we need two things: the QUOTE and the SOURCE string. These will be our inputs from the user.</p><p>Additionally, we need to set some constraints on the generated word size. By default, we have set <em>MIN_WORD_SIZE</em> to 3 and <em>MAX_WORD_SIZE</em> to 20.. The user is allowed to change it. However, users are allowed to change these settings.</p><p>Step 1: Check if we can create an acrostic from given input</p><p>You must have already guessed it. We check if the characters in the SOURCE are <strong>available</strong> in the QUOTE string. To do this, we utilize IPuzCharset data structure.<em><br/></em><strong> </strong>Without going in much detail, it simply stores characters and their frequencies.<br/>For example, for the string “MAX MIN”, it’s charset looks like <em>[{‘M’: 2}, {‘A’: 1}, {‘X’:1}, {‘I’: 1}, {’N’: 1}].</em></p><p>First, We build a charset of the source string and then iterate through it. For the source string to be valid, the count of every character in the source charset should be less than or equal to the count of that character in the quote charset.</p><pre>for (iter = ipuz_charset_iter_first (source_charset);<br/>       iter;<br/>       iter = ipuz_charset_iter_next (iter))<br/>    {<br/>      IPuzCharsetIterValue value;<br/>      value = ipuz_charset_iter_get_value (iter);<br/><br/>      if (value.count &gt; ipuz_charset_get_char_count (quote_charset, value.c))<br/>        {<br/>          // Source characters are missing in the provided quote<br/>          return FALSE;<br/>        }<br/>    }<br/><br/>return TRUE;</pre><p>Since, now we have a word size constraint, we need to add one more check.<br/>Let’s understand through this an example.</p><pre>QUOTE: LIFE IS TOO SHORT<br/>SOURCE: TOLSTOI<br/>MIN_WORD_SIZE: 3<br/>MAX_WORD_SIZE: 20</pre><p>Since, MIN_WORD_SIZE is set to 3, the generated answers should have a minimum of three letters in them.</p><pre>Possible solutions considering every solution<br/>has a length equal to the minimum word size:<br/>  T _ _<br/>  O _ _<br/>  L _ _<br/>  S _ _<br/>  T _ _<br/>  O _ _<br/>  O _ _</pre><p>If we take the sum of the number of letters in the above solutions, It’s 21. That is greater than number of letters in the QUOTE string (14). So, we can’t create an acrostic from the above input.</p><pre>if  ((n_source_characters * min_word_size) &gt; n_quote_characters)<br/>  {<br/>    //Quote text is too short to accomodate the specificed minimum word size for each clue<br/>    return FALSE;<br/>  }</pre><p>While writing this blog post, I found out we called this error “<em>SOURCE_TOO_SHORT</em>”. It should be “<em>QUOTE_TOO_SHORT</em>” / “<em>SOURCE_TOO_LARGE</em>”.</p><p>Stay tuned for further implementation in the next post!</p><img alt="" height="1" src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=6d119cb1e981" width="1"/></div>
600.    </content>
601.    <updated>2024-05-11T05:15:48Z</updated>
602.    <published>2024-05-11T05:15:48Z</published>
603.    <category term="crossword-puzzles"/>
604.    <category term="acrostic"/>
605.    <category term="algorithms"/>
606.    <category term="crossword"/>
607.    <category term="gnome"/>
608.    <author>
609.      <name>Tanmay</name>
610.    </author>
611.    <source>
612.      <id>https://medium.com/@txnmxy3?source=rss-7808d13499aa------2</id>
613.      <logo>https://cdn-images-1.medium.com/fit/c/150/150/1*EwqHW7z3bjWnHO3f7ZxZKA.jpeg</logo>
614.      <link href="https://medium.com/@txnmxy3?source=rss-7808d13499aa------2" rel="alternate" type="text/html"/>
615.      <link href="https://medium.com/@txnmxy3/feed" rel="self" type="application/rss+xml"/>
616.      <link href="http://medium.superfeedr.com" rel="hub" type="text/html"/>
617.      <subtitle>Stories by Tanmay on Medium</subtitle>
618.      <title>Stories by Tanmay on Medium</title>
619.      <updated>2024-05-19T08:52:32Z</updated>
620.    </source>
621.  </entry>
622.  
623.  <entry xml:lang="en-GB">
624.    <id>https://meeksfamily.uk/~michael/blog/2024/05/10/2024-05-10</id>
625.    <link href="https://meeksfamily.uk/~michael/blog/2024-05-10.html" rel="alternate" type="text/html"/>
626.    <title xml:lang="en-GB">2024-05-10 Friday</title>
627.    <content type="xhtml" xml:lang="en-GB"><div xmlns="http://www.w3.org/1999/xhtml"><ul> <!-- -->
628. <li>
629. Plugged away at another set of bgsave issues -
630. leftover tile renders getting called in the wrong process,
631. </li>
632. <li>
633. Picked up E. from Soham - 1st GCSE exam done - nice,
634. high spirits; a bit of lunch.
635. </li>
636. <li>
637. Wrote slides for a Tea Time Training on logging, realized
638. quite how verbose we are, and spent a while cleaning up the
639. logging code to make it friendlier; now if you do nothing,
640. nothing spews out in the log. Gave the talk.
641. </li>
642. <li>
643. Small fixes to truncate super-long JSON debug dumps, and
644. to stop the frenzy of 'fsync'ing that we do (NSS's sqlite for
645. certificate management) - as well as many files we write to;
646. sync 'fsync' is for us a successful up-load to the remote
647. storage, none of that is needed (and it is at least visible
648. on latency profiles).
649. </li>
650. </ul></div>
651.    </content>
652.    <updated>2024-05-10T21:00:00Z</updated>
653.    <published>2024-05-10T21:00:00Z</published>
654.    <source>
655.      <id>https://meeksfamily.uk/~michael/blog/index.atom</id>
656.      <author>
657.        <name>Michael Meeks</name>
658.        <email>michael.meeks@collabora.com</email>
659.        <uri>https://meeksfamily.uk/~michael/blog/index.atom</uri>
660.      </author>
661.      <link href="https://meeksfamily.uk/~michael/blog" rel="alternate" type="text/html"/>
662.      <link href="https://meeksfamily.uk/~michael/blog/index.atom" rel="self" type="application/atom+xml"/>
663.      <rights xml:lang="en-GB">Copyright 1999-2015 Michael Meeks</rights>
664.      <subtitle xml:lang="en-GB">things, of varying degrees of uselessness, that I did</subtitle>
665.      <title xml:lang="en-GB">Stuff Michael Meeks is doing</title>
666.      <updated>2024-05-10T21:00:00Z</updated>
667.    </source>
668.  </entry>
669.  
670.  <entry xml:lang="en">
671.    <id>https://thisweek.gnome.org/posts/2024/05/twig-147/</id>
672.    <link href="https://thisweek.gnome.org/posts/2024/05/twig-147/" rel="alternate" type="text/html"/>
673.    <title>#147 Secure Keys</title>
674.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Update on what happened across the GNOME project in the week from May 03 to May 10.</p>
675. <h1 id="sovereign-tech-fund">
676. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#sovereign-tech-fund"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Sovereign Tech Fund
677. </h1><p><a href="https://matrix.to/#/@sonny:gnome.org">Sonny</a> says</p>
678. <blockquote>
679. <p>As part of the GNOME STF (Sovereign Tech Fund) initiative, a number of community members are working on infrastructure related projects.</p>
680. <p>Here are the highlights for the past week</p>
681. <p>Andy is making progress on URL handling for apps. We are planning on advancing and using <a href="https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45">the freedesktop intent-apps proposal</a> which Andy implemented in <a href="https://github.com/flatpak/xdg-desktop-portal/pull/1313/commits/11c6af7a7a956c596c64fa1e7e19b49f0f86ac55">xdg-desktop-portal</a>.</p>
682. <p>Felix completed the work to <a href="https://gitlab.gnome.org/sophie-h/key-rack/-/merge_requests/14">add keyring collections support to Key Rack</a>.</p>
683. <p>Adrien worked on <a href="https://gitlab.gnome.org/GNOME/baobab/-/merge_requests/74">replacing deprecated and inaccessible <code>GtkTreeView</code> in Disk Usage Analyzer</a> (Baobab)</p>
684. <p>Adrien worked on <a href="https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1497">replacing deperecated and inaccessible <code>GtkEntryCompletion</code> in Files</a> (Nautilus)</p>
685. <p>Dhanuka <a href="https://github.com/bilelmoussaoui/oo7/pull/73">finalized the Keyring implementation in oo7</a>.</p>
686. <p>Dhanuka <a href="https://github.com/bilelmoussaoui/oo7/pull/77">landed rekeying support in oo7</a></p>
687. <p>Hubert made good progress on the USB portal and the portal is now able to display a permission dialog.</p>
688. <p>Julian <a href="https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4027">added notifications spec v2 support to GLib GNotification</a></p>
689. <p>Julian <a href="https://github.com/flatpak/xdg-desktop-portal-gtk/pull/478">created a draft merge request</a> for new notification specs against xdg-desktop-portal-gtk</p>
690. <p>Antonio finished preparing nautilus components for reuse in a new FileChooser window. <a href="https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1502">Ready for review</a>
691.  
692. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-147/bf770c356fee5516f85426e58405f225e60a84d61789006741359296512.png"/>
693. </p>
694. </blockquote>
695.  
696.  
697. <h1 id="gnome-core-apps-and-libraries">
698. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gnome-core-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Core Apps and Libraries
699. </h1>
700.  
701. <h3 id="glib">
702. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#glib"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GLib <a href="https://gitlab.gnome.org/GNOME/glib"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
703. </h3><p>The low-level core library that forms the basis for projects such as GTK and GNOME.</p>
704. <p><a href="https://matrix.to/#/@pwithnall:matrix.org">Philip Withnall</a> announces</p>
705. <blockquote>
706. <p>A series of fixes for a GDBus security issue with processes accepting spoofed signal senders has landed. Big thanks to Simon McVittie for putting together the fix (and an impressive set of regression tests), to Alicia Boya García for reporting the issue, and Ray Strode for reviews. <a href="https://discourse.gnome.org/t/security-fixes-for-signal-handling-in-gdbus-in-glib/20882">https://discourse.gnome.org/t/security-fixes-for-signal-handling-in-gdbus-in-glib/20882</a></p>
707. </blockquote>
708.  
709.  
710. <h1 id="gnome-circle-apps-and-libraries">
711. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gnome-circle-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Circle Apps and Libraries
712. </h1>
713.  
714. <h3 id="ear-tag">
715. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#ear-tag"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Ear Tag <a href="https://gitlab.gnome.org/World/eartag"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
716. </h3><p>Edit audio file tags.</p>
717. <p><a href="https://matrix.to/#/@knuxify:cybre.space">knuxify</a> says</p>
718. <blockquote>
719. <p>Ear Tag <a href="https://gitlab.gnome.org/World/eartag/-/releases/0.6.1">0.6.1</a> has been released, bringing a few minor quality-of-life improvements and a switch to the new AdwDialog widgets. You can get the latest release from <a href="https://flathub.org/apps/app.drey.EarTag">Flathub</a>.</p>
720. <p>(Sidenote - I am looking for contributors who would be willing to help with Ear Tag’s testing, bug-fixing and further development, with the goal of potentially finding co-maintainers - if you’re interested, see <a href="https://gitlab.gnome.org/World/eartag/-/issues/132">issue #132</a> for more details.)
721.  
722. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-147/wLZhaFfOlynCfMrJcNpbRGki.png"/>
723. </p>
724. </blockquote>
725.  
726.  
727. <h3 id="letterpress">
728. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#letterpress"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Letterpress <a href="https://gitlab.gnome.org/World/Letterpress"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
729. </h3><p>Create beautiful ASCII art</p>
730. <p><a href="https://matrix.to/#/@gregorni:gnome.org">Gregor Niehl</a> says</p>
731. <blockquote>
732. <p>A new minor release of <a href="https://flathub.org/apps/io.gitlab.gregorni.Letterpress">Letterpress</a> is out! No big UI changes in this 2.1 release, mostly small touches here and there:</p>
733. <ul>
734. <li>Images can now be pasted from the clipboard</li>
735. <li>Zoom is now more consistent between different factors</li>
736. <li>The Drag-n-Drop overlay was <del>stolen from Loupe</del> redesigned</li>
737. <li>The GNOME runtime was updated to version 46, which means the Tips Dialog now uses the new <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Dialog.html"><code>Adw.Dialog</code></a>, and the About Dialog is now truly an <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.AboutDialog.html"><code>About Dialog</code></a></li>
738. </ul>
739. <p>The app has also been translated to Simplified Chinese!</p>
740. <p>I’m happy to announce that, in the meantime, @FineFindus has joined the project as maintainer, so it’s no longer maintained by a single person.</p>
741. </blockquote>
742.  
743.  
744. <h1 id="third-party-projects">
745. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#third-party-projects"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Third Party Projects
746. </h1><p><a href="https://matrix.to/#/@a23_mh:matrix.org">Alain</a> announces</p>
747. <blockquote>
748. <p><strong>Planify 4.7.2 is here!</strong></p>
749. <p>We’re excited to announce the release of Planify version 4.7.2, with exciting new features and improvements to help you manage your tasks and projects even more efficiently!</p>
750. <p><strong>1. Inbox as Independent Project:</strong> We’ve completely rebuilt the functionality of Inbox. Now, it’s an independent project with the ability to move your tasks between different synchronized services. The Inbox is the default place to add new tasks, allowing you to quickly get your ideas out of your head and then plan them when you’re ready.</p>
751. <p><strong>2. Enhanced Task Duplication:</strong> When you duplicate a task now, all subtasks and labels are automatically duplicated, saving you time and effort in managing your projects.</p>
752. <p><strong>3. Duplication of Sections and Projects:</strong> You can now easily duplicate entire sections and projects, making it easier to create new projects based on existing structures.</p>
753. <p><strong>4. Improvements in Quick Add:</strong> We’ve improved the usability of Quick Add. Now, the “Create More” option is directly displayed in the user interface, making it easier to visualize and configure your new tasks.</p>
754. <p><strong>5. Improvements on Small Screens:</strong> For those working on devices with small screens, we’ve enhanced the user experience to ensure smooth and efficient navigation.</p>
755. <p><strong>6. Project Expiry Date:</strong> Your project’s expiry date now clearly shows the remaining days, helping you keep track of your deadlines more effectively.</p>
756. <p><strong>7. Enhanced Tag Panel:</strong> The tag panel now shows the number of tasks associated with each tag, rather than just the number of tags, giving you a clearer view of your tagged tasks.</p>
757. <p><strong>8. Archiving of Projects and Sections:</strong> You can now archive entire projects and sections! This feature helps you keep your workspace organized and clutter-free.</p>
758. <p><strong>9. New Task Preferences View and Task Details Sidebar:</strong> Introducing a new task preferences view! You can now customize your task preferences with ease. Additionally, we’ve enabled the option to view task details using the new sidebar view, providing quick access to all the information you need.</p>
759. <p><strong>10. Translation Updates:</strong> We thank @Scrambled777 for the Hindi translation update and @twlvnn for the Bulgarian translation update.</p>
760. <p>These are just some of the new features and improvements you’ll find in Planify version 4.7.2. We hope you enjoy using these new tools to make your task and project management even more efficient and productive.</p>
761. <p>Download the <a href="https://flathub.org/apps/io.github.alainm23.planify">update</a> today and take your productivity to the next level with Planify!</p>
762. <p>Thank you for being part of the Planify community!
763.  
764. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-147/MoHDeCNbVJvWRmOfTalzSiHe.png"/>
765.  
766. <video class="html-video" controls="" preload="auto" width="100%">
767.    <source src="https://thisweek.gnome.org/posts/2024/05/twig-147/CtAbRYCHziThspUkmusfyIgL.webm" type="video/webm"/>
768.  <span>Your browser doesn't support embedded videos, but don't worry, you can <a href="https://thisweek.gnome.org/posts/2024/05/twig-147/CtAbRYCHziThspUkmusfyIgL.webm">download it</a> and watch it with your favorite video player!</span>
769. </video>
770. <video class="html-video" controls="" preload="auto" width="100%">
771.    <source src="https://thisweek.gnome.org/posts/2024/05/twig-147/WbBOCwkYjILnSMdFwkbsvTWU.webm" type="video/webm"/>
772.  <span>Your browser doesn't support embedded videos, but don't worry, you can <a href="https://thisweek.gnome.org/posts/2024/05/twig-147/WbBOCwkYjILnSMdFwkbsvTWU.webm">download it</a> and watch it with your favorite video player!</span>
773. </video></p>
774. </blockquote>
775. <p><a href="https://matrix.to/#/@giantpinkrobots:matrix.org">Giant Pink Robots!</a> says</p>
776. <blockquote>
777. <p><a href="https://giantpinkrobots.github.io/varia/">Varia</a> download and torrent manager got a pretty big update.</p>
778. <ul>
779. <li>Powerful download scheduling feature that allows the user to specify what times in a week they would like to start or stop downloading, with an unlimited amount of custom timespans.</li>
780. <li>The ability to import a cookies.txt file exported from a browser to support downloads from restricted areas like many cloud storage services.</li>
781. <li>Support for remote timestamps if the user wants the downloaded file to have the original timestamp metadata.</li>
782. <li>Two new filtering options on the sidebar for seeding torrents and failed downloads.</li>
783. <li>An option to automatically quit the application when all downloads are completed.</li>
784. <li>An option to start the app in background mode whenever it’s started.</li>
785. <li>Support for Spanish, Persian and Hindi languages.</li>
786. </ul>
787. </blockquote>
788. <p><a href="https://matrix.to/#/@MateusRodCosta:matrix.org">Mateus R. Costa</a> announces</p>
789. <blockquote>
790. <p><a href="https://github.com/MateusRodCosta/bign-handheld-thumbnailer">bign-handheld-thumbnailer</a> (a Nintendo DS and 3DS files thumbnailer) version 0.9.0 was intended to appear on previous week’s TWIG but due to performance issues had to be postponed.</p>
791. <p>Version 0.9.0 is notable because it finally introduced CXI and CCI (which were deemed too hard to implement for the original 0.1.0 code) and there were a few misc improvements. However it was pointed that the thumbnailer was loading full games to the memory (official 3DS games can weight up to almost 4 GB) even though there were some suggestions on how to improve that I still failed to initiallly make it work.
792. At that point <a href="https://copr.fedorainfracloud.org/coprs/mateusrodcosta/bign-handheld-thumbnailer/">a COPR repo</a> also became available to help distributed the compiled RPM.</p>
793. <p>Version 1.0.0 was intended to fix the performance issue once for all, but for more details I recommend reading the blog post about this release at my personal blog: <a href="https://www.mateusrodcosta.dev/blog/bign-handheld-thumbnailer-what-i-learned-linux-thumbnailer-rust/">https://www.mateusrodcosta.dev/blog/bign-handheld-thumbnailer-what-i-learned-linux-thumbnailer-rust/</a>
794.  
795. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-147/bUlSMiLdeREtFjkOUxtbSiVH.png"/>
796. </p>
797. </blockquote>
798.  
799.  
800. <h3 id="gircore">
801. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gircore"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Gir.Core <a href="https://gircore.github.io/"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
802. </h3><p>Gir.Core is a project which aims to provide C# bindings for different GObject based libraries.</p>
803. <p><a href="https://matrix.to/#/@badcel:matrix.org">badcel</a> reports</p>
804. <blockquote>
805. <p><a href="https://github.com/gircore/gir.core/releases/tag/0.5.0">Gir.Core 0.5.0</a> was released. This is one of the biggest releases since the initial release:</p>
806. <ul>
807. <li>A lot of of new APIs are supported (especially records)</li>
808. <li>Bugs got squashed</li>
809. <li>The library versions were updated to GNOME SDK 46 and target .NET 8 in addition to .NET 6 and 7</li>
810. <li>New samples were added</li>
811. <li>The homepage got updated</li>
812. </ul>
813. <p>Anyone interested bringing C# / F# back into the Linux ecosystem is welcome to come by and try out the new version.</p>
814. </blockquote>
815.  
816.  
817. <h1 id="miscellaneous">
818. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#miscellaneous"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Miscellaneous
819. </h1><p><a href="https://matrix.to/#/@danyeaw:gnome.org">Dan Yeaw</a> says</p>
820. <blockquote>
821. <p><a href="https://github.com/wingtk/Gvsbuild">Gvsbuild</a>, the GTK stack for Windows, version 2024.5.0 is out. Along with the latest GTK version 4.14.4, we also released for the first time a pre-built version of the binaries. To set up a development environment for a GTK app on Windows, you can unzip the package, set a couple of environmental variables, and start coding.</p>
822. </blockquote>
823.  
824.  
825. <h1 id="thats-all-for-this-week">
826. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#thats-all-for-this-week"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>That’s all for this week!
827. </h1><p>See you next week, and be sure to stop by <a href="https://matrix.to/#/#thisweek:gnome.org">#thisweek:gnome.org</a> with updates on your own projects!</p></div>
828.    </summary>
829.    <updated>2024-05-10T00:00:00Z</updated>
830.    <published>2024-05-10T00:00:00Z</published>
831.    <source>
832.      <id>https://thisweek.gnome.org/author/felix/</id>
833.      <author>
834.        <name>Felix Häcker</name>
835.      </author>
836.      <link href="https://thisweek.gnome.org/author/felix/" rel="alternate" type="text/html"/>
837.      <link href="https://thisweek.gnome.org/author/felix/index.xml" rel="self" type="application/rss+xml"/>
838.      <subtitle>Recent content in Felix on This Week in GNOME</subtitle>
839.      <title>Felix on This Week in GNOME</title>
840.      <updated>2024-05-10T00:00:00Z</updated>
841.    </source>
842.  </entry>
843.  
844.  <entry xml:lang="en-GB">
845.    <id>https://meeksfamily.uk/~michael/blog/2024/05/09/2024-05-09</id>
846.    <link href="https://meeksfamily.uk/~michael/blog/2024-05-09.html" rel="alternate" type="text/html"/>
847.    <title xml:lang="en-GB">2024-05-09 Thursday</title>
848.    <content type="xhtml" xml:lang="en-GB"><div xmlns="http://www.w3.org/1999/xhtml"><ul> <!-- -->
849. <li>
850. Up early, took E. to school; tech. planning,
851. COOL community call, CODE 24.04 release retrospective.
852. </li>
853. <li>
854. Split callback processing and queueing out from
855. incoming message processing, collapsed classes, made the
856. message queueing code far cleaner and more efficient.
857. Avoided lots of message re-parsing / tokenizing.
858. </li>
859. <li>
860. Put hooks on external doors to hold them open against
861. the wind; more wire for J's roses put up in the garden.
862. </li>
863. </ul></div>
864.    </content>
865.    <updated>2024-05-09T21:00:00Z</updated>
866.    <published>2024-05-09T21:00:00Z</published>
867.    <source>
868.      <id>https://meeksfamily.uk/~michael/blog/index.atom</id>
869.      <author>
870.        <name>Michael Meeks</name>
871.        <email>michael.meeks@collabora.com</email>
872.        <uri>https://meeksfamily.uk/~michael/blog/index.atom</uri>
873.      </author>
874.      <link href="https://meeksfamily.uk/~michael/blog" rel="alternate" type="text/html"/>
875.      <link href="https://meeksfamily.uk/~michael/blog/index.atom" rel="self" type="application/atom+xml"/>
876.      <rights xml:lang="en-GB">Copyright 1999-2015 Michael Meeks</rights>
877.      <subtitle xml:lang="en-GB">things, of varying degrees of uselessness, that I did</subtitle>
878.      <title xml:lang="en-GB">Stuff Michael Meeks is doing</title>
879.      <updated>2024-05-10T21:00:00Z</updated>
880.    </source>
881.  </entry>
882.  
883.  <entry>
884.    <id>tag:blogger.com,1999:blog-6112936277054198647.post-254700240350278351</id>
885.    <link href="https://who-t.blogspot.com/feeds/254700240350278351/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
886.    <link href="https://www.blogger.com/comment.g?blogID=6112936277054198647&amp;postID=254700240350278351" rel="replies" title="0 Comments" type="text/html"/>
887.    <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default/254700240350278351" rel="edit" type="application/atom+xml"/>
888.    <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default/254700240350278351" rel="self" type="application/atom+xml"/>
889.    <link href="https://who-t.blogspot.com/2024/05/libwacom-and-huiongaomon-devices.html" rel="alternate" title="libwacom and Huion/Gaomon devices" type="text/html"/>
890.    <title>libwacom and Huion/Gaomon devices</title>
891.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>TLDR: Thanks to José Exposito, libwacom 2.12 will support all [1] Huion and Gaomon devices when running on a 6.10 kernel.
892. </p>
893.  
894. <p>
895.  libwacom, now almost 13 years old, is a C library that provides a bunch of <b>static</b> information about graphics tablets that is not otherwise available by looking at the kernel device. Basically, it's a set of APIs in the form of <i>libwacom_get_num_buttons</i> and so on. This is used by various components to be more precise about initializing devices, even though libwacom itself has <b>no effect on whether the device works</b>. It's only a library for historical reasons [2], if I were to rewrite it today, I'd probably ship libwacom as a set of static json or XML files with a specific schema.
896. </p>
897.  
898. <p>
899.  Here are a few examples on how this information is used: libinput uses libwacom to query information about tablet tools.The kernel event node always supports tilt but the individual tool that is currently in proximity may not. libinput can get the tool ID from the kernel, query libwacom and then initialize the tool struct correctly so the compositor and Wayland clients will get the right information. GNOME Settings uses libwacom's information to e.g. detect if a tablet is built-in or an external display (to show you the "Map to Monitor" button or not, if builtin), GNOME's mutter uses the SVGs provided by libwacom to show you an OSD where you can assign keystrokes to the buttons. All these features require that the tablet is supported by libwacom.
900. </p>
901. <p>
902.  Huion and Gamon devices [3] were not well supported by libwacom because they re-use USB ids, i.e. different tablets from seemingly different manufacturers have the same vendor and product ID. This is understandable, the 16-bit product id only allows for 65535 different devices and if you're a company that thinks about more than just the current quarterly earnings you realise that if you release a few devices every year (let's say 5-7), you may run out of product IDs in about 10000 years. Need to think ahead! So between the 140 Huion and Gaomon devices we now have in libwacom I only counted 4 different USB ids.
903.  Nine years ago we added name matching too to work around this (i.e. the vid/pid/name combo must match) but, lo and behold, we may run out of unique strings before the heat death of the universe so device names are re-used too! [4] Since we had no other information available to userspace this meant that if you plugged in e.g. a Gaomon M106 and it was detected as S620 and given wrong button numbers, a wrong SVG, etc.
904. </p>
905. <p>
906.  A while ago José got himself a tablet and started contributing to <a href="https://digimend.github.io/">DIGIMEND</a> (and upstreaming a bunch of things). At some point we realised that the kernel actually had the information we needed: the firmware version string from the tablet which conveniently gave us the tablet model too. With <a href="https://patchwork.kernel.org/project/linux-input/patch/20240322100210.107152-2-jose.exposito89@gmail.com/">this kernel patch scheduled for 6.10</a> this is now exported as the <b>uniq</b> property (<b>HID_UNIQ</b> in the uevent) and that means it's available to userspace. After a bit of rework in libwacom we can now match on the trifecta of vid/pid/uniq or the quadrella of vid/pid/name/uniq. So hooray, for the first time we can actually detect Huion and Gaomon devices correctly.
907. </p>
908. <p>
909.  The second thing Jose did was to extract all model names from the .deb packages Huion and Gaomon provide and auto-generate all libwacom descriptions for all supported devices. Which meant, in one <a href="https://github.com/linuxwacom/libwacom/pull/659">pull request</a> we added around 130 devices. Nice!
910. </p>
911. <p>
912.  As said above, this requires the future kernel 6.10 but you can apply the patches to your current kernel if you want. If you do have one of the newly added devices, please verify the <a href="https://github.com/linuxwacom/libwacom/tree/master/data">.tablet file</a> for your device and let us know so we can remove the "this is autogenerated" warnings and fix any issues with the file. Some of the new files may now take precedence over the old hand-added ones so over time we'll likely have to merge them. But meanwhile, for a brief moment in time, things may actually work.
913. </p>
914.  
915.  
916. <p>
917.  <small>
918.    [1] fsvo of all but should be all current and past ones provided they were supported by Huions driver<br/>
919.    [2] anecdote: in 2011 Jason Gerecke from Wacom and I sat down to and decided on a generic tablet handling library independent of the xf86-input-wacom driver. libwacom was supposed to be that library but it never turned into more than a static description library, libinput is now what our original libwacom idea was.<br/>
920.    [3] and XP Pen and UCLogic but we don't yet have a fix for those at the time of writing<br/>
921.    [4] names like "HUION PenTablet Pen"... <br/>
922.  </small>
923. </p></div>
924.    </content>
925.    <updated>2024-05-09T00:01:00Z</updated>
926.    <published>2024-05-09T00:01:00Z</published>
927.    <author>
928.      <name>Peter Hutterer</name>
929.      <email>noreply@blogger.com</email>
930.      <uri>https://www.blogger.com/profile/17204066043271384535</uri>
931.    </author>
932.    <source>
933.      <id>tag:blogger.com,1999:blog-6112936277054198647</id>
934.      <category term="git"/>
935.      <category term="kernel"/>
936.      <category term="compiz"/>
937.      <category term="gitlab"/>
938.      <category term="configuration"/>
939.      <category term="xkb"/>
940.      <category term="x"/>
941.      <category term="fedora"/>
942.      <category term="tig"/>
943.      <category term="multitouch"/>
944.      <category term="libratbag"/>
945.      <category term="tutorial"/>
946.      <category term="wayland"/>
947.      <category term="xorg.conf"/>
948.      <category term="input device properties"/>
949.      <category term="tuhi"/>
950.      <category term="workflow"/>
951.      <category term="hid"/>
952.      <category term="gnome-device-setup"/>
953.      <category term="mpx"/>
954.      <category term="outdoors"/>
955.      <category term="gnome"/>
956.      <category term="libevdev"/>
957.      <category term="xds"/>
958.      <category term="xi2"/>
959.      <category term="wacom"/>
960.      <category term="evemu"/>
961.      <category term="xorg"/>
962.      <category term="xlib"/>
963.      <category term="libinput"/>
964.      <category term="hal"/>
965.      <category term="synaptics"/>
966.      <category term="freedesktop.org"/>
967.      <category term="xts"/>
968.      <category term="evtest"/>
969.      <category term="evdev"/>
970.      <category term="libei"/>
971.      <category term="libinput. wayland"/>
972.      <author>
973.        <name>Peter Hutterer</name>
974.        <email>noreply@blogger.com</email>
975.        <uri>https://www.blogger.com/profile/17204066043271384535</uri>
976.      </author>
977.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
978.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default" rel="self" type="application/atom+xml"/>
979.      <link href="http://who-t.blogspot.com/" rel="alternate" type="text/html"/>
980.      <link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
981.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default?start-index=26&amp;max-results=25" rel="next" type="application/atom+xml"/>
982.      <title>Who-T</title>
983.      <updated>2024-05-09T00:02:05Z</updated>
984.    </source>
985.  </entry>
986.  
987.  <entry xml:lang="en-US">
988.    <id>https://blogs.gnome.org/chergert/?p=12004</id>
989.    <link href="https://blogs.gnome.org/chergert/2024/05/07/system-extensions-from-flatpak/" rel="alternate" type="text/html"/>
990.    <title>System Extensions from Flatpak</title>
991.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">I write about Sysprof here quite often. Mostly in hopes of encouraging readers to use it to improve Linux as a whole. An impediment to that is the intrusiveness to test out new features as they are developed. If only we had a Flatpak which you could install to test things right away. One major … <a class="more-link" href="https://blogs.gnome.org/chergert/2024/05/07/system-extensions-from-flatpak/">Continue reading <span class="screen-reader-text">System Extensions from Flatpak</span></a></div>
992.    </summary>
993.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>I <a href="https://blogs.gnome.org/chergert/2024/02/02/performance-profiling-for-fedora-magazine/">write</a> <a href="https://blogs.gnome.org/chergert/2022/12/31/frame-pointers-and-other-practical-near-term-solutions/">about</a> <a href="https://gitlab.gnome.org/GNOME/sysprof">Sysprof</a> here quite often. Mostly in hopes of encouraging readers to use it to improve Linux as a whole.</p>
994. <p>An impediment to that is the intrusiveness to test out new features as they are developed. If only we had a Flatpak which you could install to test things right away.</p>
995. <p>One major hurdle is how much information a profiler needs to be useful. The first obvious “impossible to sandbox” API you run into is the <code>perf</code> subsystem. It provides information about all processes running on the system and their memory mappings which would make snooping on other processes trivial. Both <code>perf</code> and <code>ptrace</code> are disabled in the Flatpak sandbox.</p>
996. <p>After that, you still need unredacted access to the kernel symbols and their address mappings (<code>kallsyms</code>). You also need to be in a PID namespaces that allows you to see all the processes running on the system and their associated memory mappings which essentially means <code>CAP_SYS_ADMIN</code>.</p>
997. <h2>Portable Services</h2>
998. <p>Years ago, portable services were introduced into systemd through <code>portablectl</code>. I had high-hopes for this because it meant that I could perhaps ship a <code>squashfs</code> and inject it as a transient service on the host.</p>
999. <p>However, Sysprof needs more integration than could be provided by this because portable services are still rather isolated from the host. We need to own a D-Bus name, policy-kit action integration, in addition to the systemd service.</p>
1000. <p>Even if that were all possible with portable services it wouldn’t get us access to some of the host information we need to properly decode symbols.</p>
1001. <h2>System Extensions</h2>
1002. <p>Then came along <code>systemd-sysext</code>. It provides a way to “layer” extensions on top of the host system’s <code>/usr</code> installation rather than in an isolated mount namespace.</p>
1003. <p>This sounds much more promising because it would allow us to install <code>.policy</code> for policy-kit, <code>.service</code> files for Systemd and D-Bus, or even udev rules.</p>
1004. <p>Though, with great power comes excruciating pain, or something like that.</p>
1005. <p>So if you need to provide binaries that run on the host you need to either static-link (<code>rust</code>, <code>go</code>, <code>zig</code> perhaps?) or use something you can reasonably expect to be there (<code>python</code>?).</p>
1006. <p>In the Sysprof case, everything is C so it can statically link almost everything by being clever with how it builds against glibc. Though this still requires glibc and quite frankly I’m fine with that. Potentially, one could use MUSL or ucLibc if they had high enough pain threshold for build tooling.</p>
1007. <h2>Bridging Flatpak and System Extensions</h2>
1008. <p>The next step would be to find a way to bridge system extensions and Flatpak.</p>
1009. <p>In the <a href="https://gitlab.gnome.org/GNOME/sysprof/-/tree/wip/chergert/sysext?ref_type=heads">wip/chergert/sysext</a> branch of Sysprof I’ve made it build a number of things statically so that I can provide a system extension directory tree at <code>/app/lib/extensions</code>. We can of course choose a different path for this but that seemed similar to <code>/var/lib/extensions</code>.</p>
1010. <p>Here we see the directory tree laid out. To do this right for <code>systemd-sysext</code> we also need to install an extension point file but I’ll save that for another day.</p>
1011. <h3>The Directory Tree</h3>
1012. <p><code>$ find /app/lib/extensions -type f<br/>
1013. /app/lib/extensions/usr/lib/systemd/system/sysprof3.service<br/>
1014. /app/lib/extensions/usr/share/polkit-1/actions/org.gnome.sysprof3.policy<br/>
1015. /app/lib/extensions/usr/share/dbus-1/system-services/org.gnome.Sysprof3.service<br/>
1016. /app/lib/extensions/usr/share/dbus-1/system.d/org.gnome.Sysprof3.conf<br/>
1017. /app/lib/extensions/usr/libexec/sysprofd</code></p>
1018. <h3>Registering the Service</h3>
1019. <p>First we need to symlink our system extension into the appropriate place for <code>systemd-sysext</code> to pick it up. Typically <code>/var/lib/extensions</code> is used for transient services so if this were being automated we might use another directory for this.</p>
1020. <p><code># mkdir -p /var/lib/extensions<br/>
1021. # ln -s /var/lib/flatpak/org.gnome.Sysprof.Devel/current/active/files/lib/extensions/ org.gnome.Sysprof.Devel</code></p>
1022. <p>Now we need to merge the extension so it overlays into <code>/usr</code>. We must use <code>--force</code> because we didn’t yet provide an appropriate extension point file for systemd.</p>
1023. <p><code># systemd-sysext merge --force<br/>
1024. Using extensions 'org.gnome.Sysprof.Devel'.<br/>
1025. Merged extensions into '/usr'.</code></p>
1026. <p>And now make sure our service was installed to the approriate location.</p>
1027. <p><code># ls /usr/lib/systemd/systemd/sysprof3.service<br/>
1028. -rw-r--r-- 2 root root 115 Dec 31  1969 /usr/lib/systemd/system/sysprof3.service</code></p>
1029. <p>Next we need to reload the systemd daemon, but newer versions of systemd do this automatically.</p>
1030. <p><code># systemctl daemon-reload</code></p>
1031. <p>Here is where things are a bit tricky because they are somewhat specific to the system. I think we should make this better in the appropriate upstream projects to avoid this altogether but also easily handled with a flatpak installation trigger.</p>
1032. <p>First make sure that policy-kit reloads our installed policy file.</p>
1033. <p><code># systemctl restart polkit.service</code></p>
1034. <p>With <code>dbus-broker</code>, we also need to reload configuration to pick up our new service file. I’m not sure if <code>dbus-daemon</code> would require this, I haven’t tested that. Though I wouldn’t be surprised if this is related to inotify file-monitors and introducing a merged <code>/usr</code>.</p>
1035. <p><code># gdbus call -y -d org.freedesktop.DBus \<br/>
1036.  -o /org/freedesktop/DBus \<br/>
1037.  -m org.freedesktop.DBus.ReloadConfig</code></p>
1038. <p>At this point, the service should be both systemd and D-Bus activatable. We can verify that with another <code>gdbus</code> call quick.</p>
1039. <p><code># gdbus call -y -d org.gnome.Sysprof3 \<br/>
1040.  -o /org/gnome/Sysprof3 \<br/>
1041.  -m org.freedesktop.DBus.Peer.Ping<br/>
1042. ()</code></p>
1043. <p>Now I can run the Flatpak as normal and it should be able to use the system extension to get profiling and system data from the host as if it were package installed.</p>
1044. <p><code>$ flatpak run org.gnome.Sysprof.Devel</code></p>
1045. <p>The following screenshots come from GNOME OS using yesterdays build with what I’ve described in this post. However, it also works on Fedora Rawhide (and probably Fedora 40) if you boot with <code>selinux=0</code>. More on that in the FAQ below.</p>
1046. <p><a href="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-28-01.png"><img alt="" class="aligncenter size-large wp-image-12082" height="501" src="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-28-01-1024x777.png" width="660"/></a></p>
1047. <p><a href="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-28-12.png"><img alt="" class="aligncenter size-large wp-image-12085" height="501" src="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-28-12-1024x777.png" width="660"/></a></p>
1048. <p><a href="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-29-38.png"><img alt="" class="aligncenter size-large wp-image-12091" height="501" src="http://blogs.gnome.org/chergert/files/2024/05/Screenshot-from-2024-05-07-11-29-38-1024x777.png" width="660"/></a></p>
1049. <h2>Flatpak Integration</h2>
1050. <p>So obviously nobody would want to do all the work above just to make their Flatpak work. The user-facing goal here would be for the appropriate triggers to be provided by Flatpak to handle this automatically.</p>
1051. <p>Making this happen in an automated fashion from flatpak installation triggers on the <code>--system</code> installation does not seem terribly out-of-scope. It’s possible that we might want to do it from within the <code>flatpak</code> binary itself but I don’t think that is necessary yet.</p>
1052. <h2>FAQ</h2>
1053. <h3>What about non-system installations?</h3>
1054. <p>It would be expected that system extensions require installing to a system installation.</p>
1055. <p>It does not make sense to allow for a <code>--user</code> installation, controllable by an unprivileged user or application, to be merged onto the host.</p>
1056. <h3>Does SELinux affect this?</h3>
1057. <p>In fact it does.</p>
1058. <p>While all of this works out-of-the-box on GNOME OS, systems like Fedora will need work to ensure their SELinux policy to not prevent system extentions from functioning. Of course you can boot with <code>selinux=0</code> but that is not viable/advised on end-user installations.</p>
1059. <p>In the Sysprof case, AVC denials would occur when trying to exec <code>/usr/libexec/sysprofd</code>.</p>
1060. <h3>Does /usr become read-only?</h3>
1061. <p>If you have <code>systemd &lt;= 255</code> then system-sysext will most definitely leave <code>/usr</code> read-only. This is problematic if you want to modify your system after merging but makes sense because <code>sysext</code> was designed for immutable systems.</p>
1062. <p>For example, say you wanted to <code>sudo dnf install a-package</code> on Fedora. That would fail because <code>/usr</code> becomes read-only after <code>systemd-sysext merge</code>.</p>
1063. <p>In <code>systemd &gt;= 256</code> there is effort underway to make <code>/usr</code> writable by redirecting writes to the top-most writable layer. Though my early testing of Fedora Rawhide with systemd <code>256~rc1</code> still shows this is not yet working.</p>
1064. <h3>So why not a Portal?</h3>
1065. <p>One could write a portal for profilers alone but that portal would essentially be <code>sysprofd</code> and likely to be extremely application specific.</p>
1066. <h3>Can I use this for udev rules?</h3>
1067. <p>You could.</p>
1068. <p>Though you might be better served by using the new Device and/or USB portals which will both save you code and systems integration hassle.</p>
1069. <h3>Can I have different binaries per OS?</h3>
1070. <p>Yes.</p>
1071. <p>The <code>systemd-sysext</code> subsystem has a directory layout which allows for matching on some specific information in <code>/etc/os-release</code>. You could, for example, have a different system extension for specific Debian or CentOS Stream versions.</p>
1072. <h3>Can they be used at boot?</h3>
1073. <p>If we choose to symlink into a persistent <code>systemd-sysext</code> location (perhaps <code>/etc/extensions</code>) then they would be available at boot.</p>
1074. <h3>Can services run independent of user app?</h3>
1075. <p>Yes.</p>
1076. <p>It would be possible to have a system service that could run independently of the user facing application.</p></div>
1077.    </content>
1078.    <updated>2024-05-07T19:26:35Z</updated>
1079.    <published>2024-05-07T19:26:35Z</published>
1080.    <category term="Flatpak"/>
1081.    <category term="Sysprof"/>
1082.    <author>
1083.      <name>chergert</name>
1084.    </author>
1085.    <source>
1086.      <id>https://blogs.gnome.org/chergert</id>
1087.      <link href="https://blogs.gnome.org/chergert/feed/" rel="self" type="application/rss+xml"/>
1088.      <link href="https://blogs.gnome.org/chergert" rel="alternate" type="text/html"/>
1089.      <subtitle>Details of Christian's work on GNOME</subtitle>
1090.      <title>Happenings in GNOME</title>
1091.      <updated>2024-05-15T20:35:43Z</updated>
1092.    </source>
1093.  </entry>
1094.  
1095.  <entry xml:lang="en-US">
1096.    <id>https://foundation.gnome.org/?p=18839</id>
1097.    <link href="https://foundation.gnome.org/2024/05/07/2023-annual-report/" rel="alternate" type="text/html"/>
1098.    <title>2023 Annual Report</title>
1099.    <summary>2023 brought many updates to the GNOME Foundation! We’re excited to share our progress and journey over the last year along with some of our best moments and achievements in our 2022-2023 annual report. Highlights For more details please see our annual report. 2023 was a success thanks to all of you! Your contributions and donations support GNOME and allow us […]</summary>
1100.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>2023 brought many updates to the GNOME Foundation! We’re excited to share our progress and journey over the last year along with some of our best moments and achievements in our <a href="https://foundation.gnome.org/reports/" rel="noreferrer noopener" target="_blank">2022-2023 annual report</a>.</p>
1101.  
1102.  
1103.  
1104. <h3 class="wp-block-heading">Highlights</h3>
1105.  
1106.  
1107.  
1108. <ul>
1109. <li>The GNOME project had two new releases, GNOME 44 and 45</li>
1110.  
1111.  
1112.  
1113. <li>GUADEC returned to Europe with a conference in Riga, Latvia</li>
1114.  
1115.  
1116.  
1117. <li>GNOME Asia returned to in-person events in Kuala Lumpur, Malaysia</li>
1118.  
1119.  
1120.  
1121. <li>We co-host another Linux App Summit with KDE in Brno, Czech Republic</li>
1122.  
1123.  
1124.  
1125. <li>We hosted 11 interns through Google Summer of Code and Outreachy</li>
1126.  
1127.  
1128.  
1129. <li>We brought on a new Executive Director, Holly Million</li>
1130. </ul>
1131.  
1132.  
1133.  
1134. <p>For more details please see our <a href="https://foundation.gnome.org/reports/" rel="noreferrer noopener" target="_blank">annual report</a>.</p>
1135.  
1136.  
1137.  
1138. <p>2023 was a success thanks to all of you! Your <a href="https://welcome.gnome.org/" rel="noreferrer noopener" target="_blank">contributions</a> and <a href="https://www.gnome.org/donate/" rel="noreferrer noopener" target="_blank">donations</a> support GNOME and allow us to continue working towards a world where everyone is empowered by technology they can trust. We look forward to continuing this work with you in the coming years.</p></div>
1139.    </content>
1140.    <updated>2024-05-07T16:46:58Z</updated>
1141.    <published>2024-05-07T16:46:58Z</published>
1142.    <category term="News"/>
1143.    <author>
1144.      <name>chenriksen</name>
1145.    </author>
1146.    <source>
1147.      <id>https://foundation.gnome.org</id>
1148.      <logo>https://foundation.gnome.org/wp-content/uploads/sites/12/2020/08/cropped-icon-32x32.jpg</logo>
1149.      <link href="https://foundation.gnome.org/news/feed/" rel="self" type="application/rss+xml"/>
1150.      <link href="https://foundation.gnome.org" rel="alternate" type="text/html"/>
1151.      <subtitle>Building a diverse and sustainable free software ecosystem</subtitle>
1152.      <title>News – The GNOME Foundation</title>
1153.      <updated>2024-05-07T16:46:59Z</updated>
1154.    </source>
1155.  </entry>
1156.  
1157.  <entry>
1158.    <id>https://olea.org/diario/2024/05/06/GDPR_statistics_with_librecounder.html</id>
1159.    <link href="https://olea.org/diario/2024/05/06/GDPR_statistics_with_librecounder.html" rel="alternate" type="text/html"/>
1160.    <title>This website now has GPDR friendly statistics</title>
1161.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><img alt="Libre Counter logotype" class="pull-right" src="https://librecounter.org/counter.svg" width="50"/></p>
1162.  
1163. <p>Now this website uses a simple statistics system which is GDPR compatible and privacy friendly. It uses <a href="https://librecounter.org/">Libre Counter</a> which not need user registration neither configuration beyond adding some code like this:</p>
1164.  
1165. <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">&lt;a</span> <span class="na">href=</span><span class="s">"https://librecounter.org/referer/show"</span> <span class="na">target=</span><span class="s">"_blank"</span><span class="nt">&gt;</span>
1166.    <span class="nt">&lt;img</span> <span class="na">src=</span><span class="s">"https://librecounter.org/unique.svg"</span> <span class="na">alt=</span><span class="s">"GPDR friendly statistics"</span> <span class="na">width=</span><span class="s">"14"</span> <span class="na">style=</span><span class="s">"filter: grayscale(1);"</span> <span class="na">title=</span><span class="s">"GPDR friendly statistics"</span> <span class="na">referrerpolicy=</span><span class="s">"unsafe-url title="</span><span class="nt">/&gt;</span>
1167. <span class="nt">&lt;/a&gt;</span>
1168. </code></pre></div></div>
1169.  
1170. <p>No cookies also.</p>
1171.  
1172. <p>Thanks <a href="https://pinchito.es/">Pinchito</a>!</p></div>
1173.    </summary>
1174.    <updated>2024-05-05T22:00:00Z</updated>
1175.    <published>2024-05-05T22:00:00Z</published>
1176.    <category term="web"/>
1177.    <category term="opensource"/>
1178.    <category term="GPDR"/>
1179.    <category term="privacy"/>
1180.    <source>
1181.      <id>https://olea.org/</id>
1182.      <author>
1183.        <name>Ismael Olea</name>
1184.      </author>
1185.      <link href="https://olea.org/" rel="alternate" type="text/html"/>
1186.      <link href="https://olea.org/feed-en.xml" rel="self" type="application/rss+xml"/>
1187.      <subtitle>Pastoreando procomunes desde 1994 — Shepherding the commons since 1994
1188. - just the English posts</subtitle>
1189.      <title>Ismael Olea — web personal</title>
1190.      <updated>2024-05-17T09:17:24Z</updated>
1191.    </source>
1192.  </entry>
1193.  
1194.  <entry xml:lang="en">
1195.    <id>https://thisweek.gnome.org/posts/2024/05/twig-146/</id>
1196.    <link href="https://thisweek.gnome.org/posts/2024/05/twig-146/" rel="alternate" type="text/html"/>
1197.    <title>#146 Editing Markdown</title>
1198.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Update on what happened across the GNOME project in the week from April 26 to May 03.</p>
1199. <h1 id="sovereign-tech-fund">
1200. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#sovereign-tech-fund"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Sovereign Tech Fund
1201. </h1><p><a href="https://matrix.to/#/@tbernard:gnome.org">Tobias Bernard</a> announces</p>
1202. <blockquote>
1203. <p>As part of the <a href="https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/">GNOME STF (Sovereign Tech Fund)</a> initiative, a number of community members are working on infrastructure related projects.</p>
1204. <p>Here are the highlights for the past two weeks:</p>
1205. <p>Dorota <a href="https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2485">created a standalone dialog in GNOME Control Center</a> to let users choose/approve/reject when an app requests a Global Shortcuts</p>
1206. <p>Dhanuka landed <a href="https://github.com/bilelmoussaoui/oo7/pull/77">Add rekeying support for oo7::portal::Keyring</a> in oo7.</p>
1207. <p>Hub <a href="https://github.com/hfiguiere/ashpd/tree/usb-portal">implemented the in-progress USB portal in ashpd</a> to demo and test</p>
1208. <p>Sophie landed <a href="https://gitlab.gnome.org/sophie-h/glycin/-/merge_requests/68">libglycin: Add C/glib/gir API for glycin crate</a>. This will let language bindings use Glycin. A first version of the C-API is for glycin is available <a href="https://sophie-h.pages.gitlab.gnome.org/glycin/c-api/">https://sophie-h.pages.gitlab.gnome.org/glycin/c-api/</a>. Via GObject introspections (<a href="https://developer.gnome.org/documentation/guidelines/programming/introspection.html">https://developer.gnome.org/documentation/guidelines/programming/introspection.html</a>) it is also usable with GJS, Python, and Vala.</p>
1209. <p>Antonio is making great progress on <a href="https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402">using Nautilus as file picker</a>.</p>
1210. <p>Julian <a href="https://github.com/flatpak/xdg-desktop-portal/pull/1298">finalized the notification portal specs</a>, reviews welcome!</p>
1211. <p>Jonas landed a fix for a long-standing touch bug</p>
1212. <ul>
1213. <li><a href="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2946">https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2946</a></li>
1214. <li><a href="https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5782">https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5782</a></li>
1215. </ul>
1216. <p>Jonas <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278">opened a merge request</a> to improve GNOME Shell layout on smaller displays</p>
1217. <p>
1218. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/7c67ecc267527fb71ced2e5f44e4df4b7671c2591786457382692323328.png"/>
1219. </p>
1220. <p>Adrien opened an MR to <a href="https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1497">replace deprecated and inaccessible GtkEntryCompletion</a> in Nautilus.</p>
1221. <p>The recording for Matt’s talk from <a href="https://ossna2024.sched.com/event/1aBO1/modernizing-accessibility-for-desktop-linux-matt-campbell-gnome-foundation">Open Source Summit North America</a> is now available, you can watch it on <a href="https://www.youtube.com/watch?v=w9psDfEFf9c">Youtube</a>.</p>
1222. </blockquote>
1223.  
1224.  
1225. <h1 id="gnome-circle-apps-and-libraries">
1226. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gnome-circle-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Circle Apps and Libraries
1227. </h1>
1228.  
1229. <h3 id="apostrophe">
1230. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#apostrophe"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Apostrophe <a href="https://gitlab.gnome.org/World/apostrophe"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1231. </h3><p>A distraction free Markdown editor.</p>
1232. <p><a href="https://matrix.to/#/@somas95:gnome.org">Manu</a> says</p>
1233. <blockquote>
1234. <p>After two years of development, I’m glad to announce that Apostrophe 3.0 is here! Almost every aspect of the application has seen improvements, from the obvious ones like the port to GTK4 and the refined interface, to several improvements under the hood. Among the new features are:</p>
1235. <ul>
1236. <li>A new toolbar so you don’t have to remember markdown syntax</li>
1237. <li>A more secure approach when opening and rendering files</li>
1238. <li>Autoindentation and autocompletion for lists and braces</li>
1239. <li>An improved Hemingway mode</li>
1240. <li>The document stats will also show stats for the selected text</li>
1241. </ul>
1242. <p>You can download it in <a href="https://flathub.org/apps/org.gnome.gitlab.somas.Apostrophe">Flathub</a>
1243.  
1244. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/1e116d532e04dc04e3ef8f25d524c15335a3c73b1786047647170166784.png"/>
1245.  
1246.  
1247. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/3bf087de8f76d809c7705f740cc51dd767e97e7d1786047443134054400.png"/>
1248. </p>
1249. </blockquote>
1250.  
1251.  
1252. <h3 id="workbench">
1253. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#workbench"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Workbench <a href="https://github.com/sonnyp/Workbench/"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1254. </h3><p>A sandbox to learn and prototype with GNOME technologies.</p>
1255. <p><a href="https://matrix.to/#/@sonny:gnome.org">Sonny</a> says</p>
1256. <blockquote>
1257. <p>Workbench 46.1 is out!</p>
1258. <p>See what’s new and details at <a href="https://blog.sonny.re/workbench-46-1">https://blog.sonny.re/workbench-46-1</a>
1259.  
1260. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/1e7d8b3c0d7225853a66b6f218fbce386f18b7c31785589596881420288.png"/>
1261.  
1262.  
1263. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/f8298ceed4d7546b492b8d002c4b2271de8b6e211785589616410099712.png"/>
1264. </p>
1265. </blockquote>
1266.  
1267.  
1268. <h3 id="railway">
1269. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#railway"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Railway <a href="https://gitlab.com/schmiddi-on-mobile/railway"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1270. </h3><p>Travel with all your train information in one place.</p>
1271. <p><a href="https://matrix.to/#/@schmiddi:matrix.org">schmiddi</a> announces</p>
1272. <blockquote>
1273. <p>Railway version 2.5.0 was  released. It contains updates to the GNOME 46 runtime, as well as the addition of the PKP provider (and removal of the INSA provider due to the API failing to search for locations). It furthermore now tries to query the remarks of journeys in the system-language, fixes a crash for the Spanish translation of the app and provides a fix for the RMV provider throwing an error.</p>
1274. </blockquote>
1275.  
1276.  
1277. <h1 id="gnome-core-apps-and-libraries">
1278. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gnome-core-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Core Apps and Libraries
1279. </h1>
1280.  
1281. <h3 id="vala">
1282. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#vala"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Vala <a href="https://gitlab.gnome.org/GNOME/vala"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1283. </h3><p>An object-oriented programming language with a self-hosting compiler that generates C code and uses the GObject system.</p>
1284. <p><a href="https://matrix.to/#/@lw64:gnome.org">lwildberg</a> reports</p>
1285. <blockquote>
1286. <p>Last month Reuben Thomas completed his port of <a href="https://abiword.github.io/enchant/">Enchant</a> to <a href="https://vala.dev">Vala</a>! Enchant is a spellchecking library also used in GNOME. Read the blog post about it and also his experience on porting another project (Zile) to Vala <a href="https://vala.dev/blog/c-off-ramp/">here</a>.</p>
1287. </blockquote>
1288.  
1289.  
1290. <h3 id="tracker">
1291. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#tracker"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Tracker <a href="https://gitlab.gnome.org/GNOME/tracker/"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1292. </h3><p>A filesystem indexer, metadata storage system and search tool.</p>
1293. <p><a href="https://matrix.to/#/@ssssam:matrix.org">Sam Thursfield</a> announces</p>
1294. <blockquote>
1295. <p>The Tracker SPARQL developers are very happy to welcome rachle08 and Demigod who will be joining the team as part of Google Summer of Code, working on a project to add a <a href="https://gitlab.gnome.org/GNOME/tracker/-/issues/421">web-based query editor</a> and generally improve the developer experience.</p>
1296. </blockquote>
1297. <p><a href="https://matrix.to/#/@ssssam:matrix.org">Sam Thursfield</a> reports</p>
1298. <blockquote>
1299. <p>In Tracker SPARQL, Carlos Garnacho worked around a non-backwards compatible change released in SQLite 3.45.3. This change causes errors that look like <code>ambiguous column name: ROWID (0)</code>. The fix will be in the next stable release - see <a href="https://discourse.gnome.org/t/tracker-sparql-affected-by-behaviour-change-in-sqlite-3-45-3/20772">Discourse</a> for more details.</p>
1300. </blockquote>
1301.  
1302.  
1303. <h3 id="software">
1304. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#software"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Software <a href="https://gitlab.gnome.org/GNOME/gnome-software/"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1305. </h3><p>Lets you install and update applications and system extensions.</p>
1306. <p><a href="https://matrix.to/#/@pwithnall:matrix.org">Philip Withnall</a> reports</p>
1307. <blockquote>
1308. <p>Automeris naranja has made headway into porting gnome-software to the shiny new <code>AdwDialog</code> (and other related new libadwaita APIs)</p>
1309. </blockquote>
1310.  
1311.  
1312. <h1 id="third-party-projects">
1313. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#third-party-projects"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Third Party Projects
1314. </h1><p><a href="https://matrix.to/#/@halfmexican:matrix.org">José</a> reports</p>
1315. <blockquote>
1316. <p>I’ve released my first app on Flathub! Mingle is a simple app
1317. to play with Google’s Emoji Kitchen and copy them to your clipboard. It is written in Vala and has been my little pet project these past few months as a learning exercise.
1318.  
1319. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/OpleAVcALIhGrIMZckXsGudN.png"/>
1320.  
1321.  
1322. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/dBHjQgpKJwQkoxldklORvVkR.png"/>
1323. </p>
1324. </blockquote>
1325. <p><a href="https://matrix.to/#/@slomo:matrix.org">slomo</a> reports</p>
1326. <blockquote>
1327. <p>The <a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/video/gtk4">GStreamer GTK4 video sink</a> got <a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1547">support</a> for directly importing video frames as dmabufs on Linux when using GStreamer 1.24 / GTK 4.14, in addition to the already existing support for importing OpenGL textures or video frames in normal system memory. This new feature is available in version 0.12.4 of the sink plugin.</p>
1328. <p>This is especially useful for video players using hardware decoders or applications that display a video stream from a camera (via v4l2 or pipewire), and allows side-stepping the GL/Vulkan rendering of the video frames inside GTK under certain conditions and let the composition be done by the Wayland compositor or even directly pass the dmabufs to the GPU kernel driver. Doing so would reduce GPU utilization and by that frees resources for other tasks and reduces power consumption. See <a href="https://blog.gtk.org/2024/04/17/graphics-offload-revisited/">Matthias' blog post</a> on the GTK blog for more details about the dmabuf and graphics offloading support in GTK.</p>
1329. </blockquote>
1330. <p><a href="https://matrix.to/#/@a23_mh:matrix.org">Alain</a> reports</p>
1331. <blockquote>
1332. <p>Planify 4.7 is Here! Discover the New Features and Improvements
1333. We’re thrilled to announce the arrival of Planify 4.7! This version brings a host of exciting enhancements and new features that will make your task and project management experience smoother and more efficient than ever. Let’s take a look at what we’ve added:</p>
1334. <p><strong>Advanced Filtering Function</strong>
1335. Now in Planify, you can filter your tasks within a project based on priority, due date, and assigned tags. Take control of your tasks like never before!</p>
1336. <p><strong>Custom Sorting in Today View</strong>
1337. Personalize the Today view by sorting your tasks the way you prefer. Make your day more productive by organizing tasks your way!</p>
1338. <p><strong>Instant Task Details</strong>
1339. With our new task detail view in the sidebar, you can quickly access all relevant task information while in the Board view. Keep your workflow uninterrupted!</p>
1340. <p><strong>Efficient Management of Completed Tasks</strong>
1341. Now, deleting completed tasks is easier than ever. Keep your workspace clean and organized with just a few clicks!</p>
1342. <p><strong>Attach Files to Your Tasks</strong>
1343. Never lose track of important files related to your tasks. With the file attachment feature, keep all relevant information in one place.</p>
1344. <p><strong>Celebrate Achievements with Sound</strong>
1345. Want a fun way to celebrate your achievements? Now you can play a sound when completing a task. Make every accomplishment even more satisfying!</p>
1346. <p><strong>Bug Fixes and Performance Improvements</strong>
1347. We’ve addressed a number of errors, from project duplication to issues with animation when adding subtasks. Additionally, we’ve updated translations in various languages, including Hindi, Bulgarian, Brazilian Portuguese, and Spanish.</p>
1348. <p>Download the latest version of Planify on <a href="https://flathub.org/apps/io.github.alainm23.planify">Flathub</a> now and take your task management to the next level!
1349. For any feedback, suggestions or bug reports, please file an issue at the <a href="https://github.com/alainm23/planify/issues">Github</a> issue tracker.
1350.  
1351. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/koPhupZHebLuxBZQrTKSCUtG.png"/>
1352.  
1353.  
1354. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/cqwkmxIGCKlYmbwsFNPeueGI.png"/>
1355. </p>
1356. </blockquote>
1357. <p><a href="https://matrix.to/#/@subpop:matrix.org">Link Dupont</a> says</p>
1358. <blockquote>
1359. <p>Version 0.2.2 of Damask is here. This release has been in the works for a while,
1360. so contains a lot of bug fixes and UI improvements.</p>
1361. <ul>
1362. <li>Wallhaven: correctly set aspect ratio in search query</li>
1363. <li>Reset the refresh timer after a manual refresh</li>
1364. <li>Wallhaven: refresh wallpaper when preferences change</li>
1365. <li>Refresh wallpaper preview only when a preview is available</li>
1366. <li>Set active source by selecting the row in the source list</li>
1367. <li>NASA: rename row title to “NASA Astronomy”</li>
1368. <li>Sort source list alphabetically</li>
1369. <li>Add a setting to disable automatic refresh</li>
1370. <li>Improve support for a default “no source” application state</li>
1371. <li>Fix preview image dimensions</li>
1372. <li>Remove the “manual” source (disable automatic refresh instead)</li>
1373. <li>NASA: replace user-defined API key with a value supplied at compilation</li>
1374. <li>Unsplash: replace user-defined API key with a value supplied at compilation</li>
1375. <li>Wallhaven: add explanatory text for the API key field</li>
1376. <li>EarthView: update photo source</li>
1377. <li>Slideshow: allow any image type when filtering files</li>
1378. </ul>
1379. <p>Download it on <a href="https://flathub.org/apps/app.drey.Damask">Flathub</a> today!
1380.  
1381. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/HvZjITLyXVxrKQRHiFjDfHmC.png"/>
1382.  
1383.  
1384. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/QMcstnECwAmLOegkikDXXvOU.png"/>
1385.  
1386.  
1387. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/CzGRbboScWhbKlLHsIeZfnmS.png"/>
1388. </p>
1389. </blockquote>
1390. <p><a href="https://matrix.to/#/@tchx84:matrix.org">Martín Abente Lahaye</a> reports</p>
1391. <blockquote>
1392. <p>Gameeky 0.6.4 is now available on <a href="https://flathub.org/apps/dev.tchx84.Gameeky">Flathub</a>. This new release brings minor fixes for running Gameeky on other platforms and it’s now fully available in Brazilian Portuguese 🇧🇷, thanks to Rafael Fontenelle. As a result of Rafael efforts, the offline documentation can now be translated using regular gettext-based tools and therefore much easier to do so.
1393.  
1394. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/voJfDCQRqCUmCZGgjhYwivyq.png"/>
1395.  
1396.  
1397. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/qNRfgRGcwEADhvjuDnIkZMny.png"/>
1398. </p>
1399. </blockquote>
1400.  
1401.  
1402. <h3 id="turtle">
1403. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#turtle"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Turtle <a href="https://gitlab.gnome.org/philippun1/turtle"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1404. </h3><p>Manage git repositories in Nautilus.</p>
1405. <p><a href="https://matrix.to/#/@philippun:matrix.org">Philipp</a> reports</p>
1406. <blockquote>
1407. <p><a href="https://gitlab.gnome.org/philippun1/turtle">Turtle</a> 0.8 has been released.</p>
1408. <p>Retrieving the log commits and calculating the graph is now much faster. Opening up the log for, i.e. the gnome-shell repo, will now only take some seconds, if “Show all branches” is checked it will take roughly 15 seconds. Before it took roughly 1 minute 40 seconds, depending on your hardware of course.</p>
1409. <p>There is now also a merge dialog available to merge a branch or commit into the current head. It is also possible to start a merge directly from the log context menu.</p>
1410. <p>For easier usage, a help output has been added to both the turtle_cli and the turtlevcs python package, a bash completion file has been added and an emblem dialog has been added to the settings dialog.</p>
1411. <p>And there are many more minor fixes and tweaks, see the <a href="https://gitlab.gnome.org/philippun1/turtle/-/releases/0.8">full changelog</a>.
1412.  
1413. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/iLjdMEWYfGfDhbWWueuCTbGU.png"/>
1414.  
1415.  
1416. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/cljTRutvCQhUJkpCcgoKgYWQ.png"/>
1417. </p>
1418. </blockquote>
1419.  
1420.  
1421. <h3 id="mahjongg">
1422. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#mahjongg"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Mahjongg <a href="https://gitlab.gnome.org/GNOME/gnome-mahjongg"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1423. </h3><p>A solitaire version of the classic Eastern tile game.</p>
1424. <p><a href="https://matrix.to/#/@mat:mathias.is">Mat</a> announces</p>
1425. <blockquote>
1426. <p>Mahjongg has received a whole slew of improvements in the last few weeks:</p>
1427. <ul>
1428. <li>Complete dark/light mode support with separate backgrounds for each tileset</li>
1429. <li>Faster loading times (almost instant, compared to the previous ~5 seconds for some tile layouts)</li>
1430. <li>Moved tile layout switcher to the main menu, for easier access</li>
1431. <li>Ported to newer GTK/libadwaita widgets, such as Gtk.ColumnView and Adw.Dialog</li>
1432. <li>All known bugs addressed (issue tracker is empty!)</li>
1433. </ul>
1434. <p>These changes are not released yet, but are available for testing in the <a href="https://nightly.gnome.org/">nightly Flatpak package</a>:<br/>
1435. <code>flatpak install gnome-nightly org.gnome.Mahjongg.Devel</code>
1436.  
1437. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/efkqZJALYZLfdlnFaYtXrleE.png"/>
1438.  
1439.  
1440. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/xcGxzPhbeNDFwuDUozCuvAkf.png"/>
1441. </p>
1442. </blockquote>
1443.  
1444.  
1445. <h3 id="fractal">
1446. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#fractal"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Fractal <a href="https://gitlab.gnome.org/World/fractal"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
1447. </h3><p>Matrix messaging app for GNOME written in Rust.</p>
1448. <p><a href="https://matrix.to/#/@zecakeh:tedomum.net">Kévin Commaille</a> reports</p>
1449. <blockquote>
1450. <p>Here comes <del>the bride</del> Fractal 7, with extended encryption support and improved accessibility. Server-side key backup and account recovery have been added, bringing greater security. Third-party verification has received some bug fixes and improvements. Amongst the many accessibility improvements, navigability has increased, especially in the room history. But that’s not all we’ve been up to in the past three months:</p>
1451. <ul>
1452. <li>Messages that failed to send can now be retried or discarded.</li>
1453. <li>Messages can be reported to server admins for moderation.</li>
1454. <li>Room details are now considered complete, with the addition of room address management, permissions, and room upgrade.</li>
1455. <li>A new member menu appears when clicking on an avatar in the room history. It offers a quick way to do many actions related to that person, including opening a direct chat with them and moderating them.</li>
1456. <li>Pills are clickable and allow to directly go to a room or member profile.</li>
1457. </ul>
1458. <p>As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.</p>
1459. <p>We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you’ve done. If you want to help with this effort, head over to <a href="https://l10n.gnome.org/">Damned Lies</a>.</p>
1460. <p>It is available right now on <a href="https://flathub.org/apps/org.gnome.Fractal">Flathub</a>.</p>
1461. <p>We are already hard at work for our next release, so if you want to give us a hand you can start by looking at our <a href="https://gitlab.gnome.org/World/fractal/-/issues/?state=opened&amp;label_name%5B%5D=4.%20Newcomers">Newcomer issues</a> or just come say hello in <a href="https://matrix.to/#/#fractal:gnome.org">our Matrix room</a>.
1462.  
1463. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/81089d6351aa86b14333b74e5e8e07bbc35f06061786319054823227392.png"/>
1464. </p>
1465. </blockquote>
1466.  
1467.  
1468. <h1 id="miscellaneous">
1469. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#miscellaneous"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Miscellaneous
1470. </h1><p><a href="https://matrix.to/#/@sophieherold:gnome.org">Sophie (she/her)</a> announces</p>
1471. <blockquote>
1472. <p><a href="https://gitlab.gnome.org/sophie-h/glycin">Glycin</a> is gaining support for other programming languages. Glycin is a library that features sandboxed and extendable image loading and is used by Image Viewer. It is written in Rust and so far only provided a <a href="https://docs.rs/glycin/latest/glycin/">Rust API</a>. As part of my work for GNOME STF, it has now gained initial support for being used with other languages. The basis for this is <a href="https://sophie-h.pages.gitlab.gnome.org/glycin/c-api/">the C-API</a>. Via <a href="https://developer.gnome.org/documentation/guidelines/programming/introspection.html">GObject introspections</a> it is now also usable with GJS, Python, and Vala (untested).</p>
1473. <p>The advantages of Glycin over the well-proven GdkPixbuf are improved security, more reliable and dynamically adjusted memory usage limits, and reliable termination of loading processes. Currently, the drawbacks include a slightly increased overhead and missing support for anything but Linux.</p>
1474. </blockquote>
1475.  
1476.  
1477. <h1 id="google-summer-of-code">
1478. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#google-summer-of-code"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Google Summer of Code
1479. </h1><p><a href="https://matrix.to/#/@toluene:matrix.org">Pedro Sader Azevedo</a> announces</p>
1480. <blockquote>
1481. <p>We are happy to announce that GNOME was assigned eight slots for <a href="https://summerofcode.withgoogle.com/">Google Summer of Code (GSoC)</a> projects this year!</p>
1482. <p>GSoC is a program focused on bringing new contributors into open source software development. A number of long term GNOME developers are former GSoC interns, making the program a very valuable entry point for new members in our community.</p>
1483. <p>In 2024, we will be mentoring the following projects:
1484.  
1485. <img alt="" src="https://thisweek.gnome.org/posts/2024/05/twig-146/tuXkVbKtYjrHyPXSXGtvFVSD.png"/>
1486. </p>
1487. </blockquote>
1488.  
1489.  
1490. <h1 id="gnome-foundation">
1491. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#gnome-foundation"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Foundation
1492. </h1><p><a href="https://matrix.to/#/@chenriksen:gnome.org">Caroline Henriksen</a> announces</p>
1493. <blockquote>
1494. <p>The GNOME Asia 2024 Call for Locations is open! If you are interested in hosting this year’s conference in your city make sure to submit an intent to bid by May 15, and a final proposal by June 6. More details about how to submit a proposal can be found here: <a href="https://foundation.gnome.org/2024/04/30/call-for-gnome-asia-2024-location-proposals/">https://foundation.gnome.org/2024/04/30/call-for-gnome-asia-2024-location-proposals/</a></p>
1495. <p>The GUADEC 2025 Call for Locations is also open! For next year’s conference, we’re accepting bids from anywhere in the world. If you would like to bring GUADEC to your city make sure to submit an intent to bid today (May 3) and your full proposal by May 31. More details can be found here: <a href="https://foundation.gnome.org/2024/04/18/call-for-guadec-2025-location-proposals/">https://foundation.gnome.org/2024/04/18/call-for-guadec-2025-location-proposals/</a></p>
1496. <p>Registration is open for GUADEC 2024. This year’s conference takes place on July 19-24 in Denver, Colorado, USA. Let us know if you’ll be attending, remotely or in person, by registering on <a href="https://events.gnome.org/event/209/">guadec.org</a>. For anyone attending in person, we’ve organized a social outing to a Colorado Rockies baseball game! You can learn more and register to attend here: <a href="https://events.gnome.org/event/209/page/331-colorado-rockies-baseball-game">https://events.gnome.org/event/209/page/331-colorado-rockies-baseball-game</a></p>
1497. </blockquote>
1498.  
1499.  
1500. <h1 id="thats-all-for-this-week">
1501. <a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/author/felix/index.xml#thats-all-for-this-week"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>That’s all for this week!
1502. </h1><p>See you next week, and be sure to stop by <a href="https://matrix.to/#/#thisweek:gnome.org">#thisweek:gnome.org</a> with updates on your own projects!</p></div>
1503.    </summary>
1504.    <updated>2024-05-03T00:00:00Z</updated>
1505.    <published>2024-05-03T00:00:00Z</published>
1506.    <source>
1507.      <id>https://thisweek.gnome.org/author/felix/</id>
1508.      <author>
1509.        <name>Felix Häcker</name>
1510.      </author>
1511.      <link href="https://thisweek.gnome.org/author/felix/" rel="alternate" type="text/html"/>
1512.      <link href="https://thisweek.gnome.org/author/felix/index.xml" rel="self" type="application/rss+xml"/>
1513.      <subtitle>Recent content in Felix on This Week in GNOME</subtitle>
1514.      <title>Felix on This Week in GNOME</title>
1515.      <updated>2024-05-10T00:00:00Z</updated>
1516.    </source>
1517.  </entry>
1518.  
1519.  <entry xml:lang="en-US">
1520.    <id>https://blog.jwf.io/?p=2908</id>
1521.    <link href="https://blog.jwf.io/2024/05/outreachy-may-2024-letter-fedora-applicants/" rel="alternate" type="text/html"/>
1522.    <title>Outreachy May 2024: A letter to Fedora applicants</title>
1523.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The post <a href="https://blog.jwf.io/2024/05/outreachy-may-2024-letter-fedora-applicants/">Outreachy May 2024: A letter to Fedora applicants</a> appeared first on <a href="https://blog.jwf.io">/home/jwf/</a>.</p>
1524. <p><a href="https://blog.jwf.io">/home/jwf/ - Free &amp; Open Source, technology, travel, and life reflections</a></p>
1525. <p>To all Outreachy May 2024 applicants to the Fedora Project, Today is May 2nd, 2024. The Outreachy May 2024 round results will be published in a few short hours. This year, the participation in Fedora for Outreachy May 2024 was record-breaking. Fedora will fund three internships this year. During the</p></div>
1526.    </summary>
1527.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The post <a href="https://blog.jwf.io/2024/05/outreachy-may-2024-letter-fedora-applicants/">Outreachy May 2024: A letter to Fedora applicants</a> appeared first on <a href="https://blog.jwf.io">/home/jwf/</a>.</p>
1528. <p><a href="https://blog.jwf.io">/home/jwf/ - Free &amp; Open Source, technology, travel, and life reflections</a></p>
1529.  
1530. <p><em>To all Outreachy May 2024 applicants to the Fedora Project</em>,</p>
1531.  
1532.  
1533.  
1534. <p>Today is May 2nd, 2024. The Outreachy May 2024 round results will be published in a few short hours. This year, the participation in Fedora for Outreachy May 2024 was record-breaking. <a href="https://blog.jwf.io/category/foss/fedora/">Fedora</a> will fund three internships this year. During the application and contribution phase, over 150 new contributors appeared in our Mentored Project contribution channels. For the project I am mentoring specifically, 38 applicants recorded contributions and 33 applicants submitted final applications. This is my third time mentoring, but this Outreachy May 2024 round has been a record-breaker for all the projects I have mentored until now.</p>
1535.  
1536.  
1537.  
1538. <p>But breaking records is not what this letter is about.</p>
1539.  
1540.  
1541.  
1542. <span id="more-2908"/>
1543.  
1544.  
1545.  
1546. <p>This day can be either enormously exciting and enormously disappointing. It is a tough day for me. There are so many Outreachy applicants who are continuing to contribute after the final applications were due. I see several applicants from my project who are contributing across the Fedora community, and actually leveling up to even bigger contributions than the application period. It is exciting to see people grow in their confidence and capabilities in an <a href="https://blog.jwf.io/category/foss/">Open Source community</a> like Fedora. Mentoring is a rewarding task for me, and I feel immensely proud of the applicants we have had in the Fedora community this round.</p>
1547.  
1548.  
1549.  
1550. <p>But the truth is difficult. Fedora has funding for three interns, hard and simple. Hard decisions have to be made. If I had unlimited funding, I would have hired so many of our applicants. But funding is not unlimited. Three people will receive great news today, and most people will receive sad news. Throughout this entire experience in the application phase, I wanted to design me and Joseph Gayoso’s project so that even folks who were not selected would have an enriching experience. We wanted to <a href="https://blog.jwf.io/2024/03/win-win-for-all-outreachy/">put something real in the hands of our applicants</a> at the end. We also wanted to boost their confidence in showing up in a community and guide them on how to roll up your sleeves and get started. Looking at the portfolios that applicants to our project submitted, I admire how far our applicants came since the day that projects were announced. Most applicants never participated in an open source community before. And for some, you would never have known that either!</p>
1551.  
1552.  
1553.  
1554. <p>So, if you receive the disappointing news today, remember that it does not reflect badly on you. The Outreachy May 2024 round was incredibly competitive. <em>Literally</em>, record-breaking. We have to say no to many people who <em>have</em> proved that they have what it takes to be a capable Fedora Outreachy intern. I hope you can look at all the things you learned and built over these past few months, and use this as a step-up to the next opportunity awaiting you. Maybe it is an Outreachy internship in a future round, or maybe it is something else. If there is anything I have learned, it is that life takes us on the most unexpected journeys sometimes. And whatever is meant to happen, will happen. I believe that there is a reason for everything, but we may not realize what that reason is until much later in the future.</p>
1555.  
1556.  
1557.  
1558. <p>Thank you to all of the Fedora applicants who put in immense effort over the last several months. I understand if you choose to stop contributing to Fedora. I hope that you will not be discouraged from open source generally though, and that you will keep trying. If you do choose to continue contributing to Fedora, I promise we will find a place for you to continue on. Regardless of your choice in contributing, keep shining and be persistent. Don’t give up easily, and remember that what you learned in these past few months can give a leading edge on that next opportunity waiting around the corner for you.</p>
1559.  
1560.  
1561.  
1562. <p>Freedom, Friends, Features, First!</p>
1563.  
1564.  
1565.  
1566. <p>— Justin</p></div>
1567.    </content>
1568.    <updated>2024-05-02T13:05:05Z</updated>
1569.    <published>2024-05-02T13:05:05Z</published>
1570.    <category term="Fedora Linux"/>
1571.    <category term="Open Source"/>
1572.    <category term="Red Hat"/>
1573.    <category term="2020s"/>
1574.    <category term="Fedora Planet"/>
1575.    <category term="internship"/>
1576.    <category term="open source communities"/>
1577.    <category term="Outreachy"/>
1578.    <category term="reflections"/>
1579.    <author>
1580.      <name>Justin W. Flory</name>
1581.    </author>
1582.    <source>
1583.      <id>https://blog.jwf.io/tag/fedora-planet/</id>
1584.      <logo>https://i0.wp.com/blog.jwf.io/wp-content/uploads/2023/08/favicon.png?fit=16%2C16&amp;ssl=1</logo>
1585.      <link href="https://blog.jwf.io/tag/fedora-planet/feed/" rel="self" type="application/rss+xml"/>
1586.      <link href="https://blog.jwf.io/tag/fedora-planet/" rel="alternate" type="text/html"/>
1587.      <subtitle>Free &amp; Open Source, technology, travel, and life reflections</subtitle>
1588.      <title>Fedora Planet Archives – /home/jwf/</title>
1589.      <updated>2024-05-02T13:05:13Z</updated>
1590.    </source>
1591.  </entry>
1592.  
1593.  <entry xml:lang="en-US">
1594.    <id>https://feborg.es/?p=10444</id>
1595.    <link href="https://feborg.es/gnome-will-be-mentoring-8-new-contributors-for-google-summer-of-code-2024/" rel="alternate" type="text/html"/>
1596.    <title>GNOME will be mentoring 8 new contributors for Google Summer of Code 2024</title>
1597.    <summary>We are happy to announce that GNOME was assigned eight slots for Google Summer of Code projects this year! GSoC is a program focused on bringing new contributors into open source software development. A number of long term GNOME developers are former GSoC interns, making the program a very valuable entry point for new members […]</summary>
1598.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>We are happy to announce that GNOME was assigned eight slots for <a href="https://summerofcode.withgoogle.com/" rel="noopener nofollow ugc">Google Summer of Code</a> projects this year!</p>
1599. <p>GSoC is a program focused on bringing new contributors into open source software development. A number of long term GNOME developers are former GSoC interns, making the program a very valuable entry point for new members in our project.</p>
1600. <p>In 2024 we will mentoring the following projects:</p>
1601. <ul>
1602. <li>“Add TypeScript Support to Workbench” by Angelo Verlain Shema, mentored by Sonny Piers</li>
1603. <li>“Port Workbench demos to Vala, build a new Workbench Library, and replace the current code search” by Bharat Tyagi, mentored by Sonny Piers</li>
1604. <li>“Improve Tracker SPARQL developer experience by creating a ‘web IDE’ for developing queries” by Demigod, mentored by Carlos Garnacho</li>
1605. <li>“Papers’ small screen and touch support for mobile and tablet” by Markus Göllnitz, mentored by Pablo Correa Gomez</li>
1606. <li>“More durable synching for FlatSync” by Mattia Formichetti, mentored by Rasmus Thomsen</li>
1607. <li>“Port libipuz to Rust” by pranjal_, mentored by Jonathan Blandford</li>
1608. <li>“Improve Tracker SPARQL developer experience by creating ‘web IDE’ for developing queries” by rachle08, mentored by Carlos Garnacho</li>
1609. <li>“Add support for the latest GIR attributes and gi-docgen formatting to Valadoc” by sudhanshuv1, mentored by Lorenz Wildberg</li>
1610. </ul>
1611. <p>As part of the contributor’s acceptance into GSoC they are expected to actively participate in the <a href="https://developers.google.com/open-source/gsoc/timeline#may_1_-_26">Community Bonding period</a><strong> (May 1 – 26)</strong>. The Community Bonding period is intended to help prepare contributors to start contributing at full speed starting <a href="https://developers.google.com/open-source/gsoc/timeline#may_27">May 27</a>.</p>
1612. <p>The new contributors will soon get their blogs added to <a href="https://planet.gnome.org/" rel="noopener nofollow ugc">Planet GNOME</a> making it easy for the GNOME community to get to know them and the projects that they will be working on.</p>
1613. <p>We would like to also thank our mentors for supporting GSoC and helping new contributors enter our project.</p>
1614. <p>If you have any doubts, feel free to reply to <a href="https://discourse.gnome.org/t/gnome-will-be-mentoring-8-new-contributors-for-google-summer-of-code-2024/20768">this Discourse topic</a> or message us privately at <a href="mailto:soc-admins@gnome.org">soc-admins@gnome.org</a></p>
1615. <p> </p></div>
1616.    </content>
1617.    <updated>2024-05-02T10:25:12Z</updated>
1618.    <published>2024-05-02T10:25:12Z</published>
1619.    <category term="gnome"/>
1620.    <category term="GSoC"/>
1621.    <category term="gsoc"/>
1622.    <author>
1623.      <name>Felipe Borges</name>
1624.    </author>
1625.    <source>
1626.      <id>https://feborg.es</id>
1627.      <logo>https://feborg.es/files/2023/12/cropped-avatar-32x32.jpg</logo>
1628.      <link href="https://feborg.es/feed/" rel="self" type="application/rss+xml"/>
1629.      <link href="https://feborg.es" rel="alternate" type="text/html"/>
1630.      <subtitle>Felipe Borges' blog about GNOME</subtitle>
1631.      <title>Felipe Borges</title>
1632.      <updated>2024-05-03T14:53:57Z</updated>
1633.    </source>
1634.  </entry>
1635.  
1636.  <entry>
1637.    <id>https://blog.sonny.re/workbench-46-1</id>
1638.    <link href="https://blog.sonny.re/workbench-46-1?pk_campaign=rss-feed" rel="alternate" type="text/html"/>
1639.    <title>Workbench 46.1</title>
1640.    <summary>&lt;![CDATA[International Workers' Day marks the release of Workbench 46.1
1641.  
1642. a href='https://flathub.org/apps/re.sonny.Workbench'img width='240' alt='Download on Flathub' src='https://flathub.org/api/badge?locale=en'//a
1643.  
1644. This new release comes with
1645.  
1646. Save/restore window state and dimensions for each session/project. I couldn't use the method defined in Saving and restoring state into GSettings because resizing manually with the mouse triggers a lot of blocking disk writes and cause the user action to appear sluggish. So I debounce the events and write to gsettings manually.
1647.  
1648. Find text in the current editor. The keyboard shortcut is Ctrl+F. This is a feature started by Sriyansh Shivam during their GSoC 2023 internship and finished by UrtsiSantsi. Thanks!
1649.  
1650. SVG Library entry. Gtk (via gdk-pixbuf) draws SVGs at their intrisic sizes (what is defined in the svg document). If you use different dimensions for example using GtkImage.pixel-size then it is the pixmap that gets upscaled resulting in pixelated / blurry images. This new Library entry showcases how to render an SVG at arbitrary dimensions using librsvg. We may need a better primitive in the future, if you need an SVG Paintable; GTK Demo contains an example. See also this conversation.
1651.  
1652. A screenshot of the "SVG" Library entry
1653.  
1654. Reveal In Files. This is a new option available in the menu that will reveal the session/project in Files. You can use it to add assets to your project and load them using workbench.resolve or as icons.
1655.  
1656. Import icons into your projects. Using the “Reveal In Files” option you can now add custom icons to your projects. It's just a matter of dropping the files in the right folder. See the “Using Icons” Library entry.
1657.  
1658. A screenshot of the "Using Icons" Library entry
1659.  
1660. Workbench included an Icon Library and icon-development-kit for a while but in an effort to simplify Workbench and since we already have an Icon Library app, I decided to remove both in favor of per project icons.
1661.  
1662. I'm quite happy with the developer experience there and I hope we can provide something similar in the future to move beyond GtkIconTheme. We probably need to keep icon-name as suggested in Updates from inside GTK but I'd be very interested supporting relative paths in GTK Builder. Thankefully we already have GResource to allow for something like
1663.  
1664. Gtk.Image {
1665.  src: "./smile-symbolic.svg";
1666. }
1667.  
1668. 7 new Library entries ported to Vala
1669.  
1670. Radio Buttons
1671. Switch
1672. Revealer
1673. Styling with CSS
1674. Separator
1675. Level Bars
1676. Link Button
1677.  
1678. Also
1679.  
1680. "Animation" Library entry ported to Python
1681. Split "List View Widget" Library entry into "List View" and "Grid View"
1682. Fix Vala and Rust extensions detection on "Run"
1683. List editor shortcuts in Shortcuts
1684.  
1685. Thank you contributors and GSoC applicants.]]&gt;</summary>
1686.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>International Workers' Day marks the release of <a href="https://apps.gnome.org/Workbench/">Workbench</a> 46.1</p>
1687.  
1688. <p><a href="https://flathub.org/apps/re.sonny.Workbench"><img alt="Download on Flathub" src="https://flathub.org/api/badge?locale=en" width="240"/></a></p>
1689.  
1690. <p>This new release comes with</p>
1691.  
1692. <p><strong>Save/restore window state and dimensions</strong> for each session/project. I couldn't use the method defined in <a href="https://developer.gnome.org/documentation/tutorials/save-state.html#saving-and-restoring-state-into-gsettings">Saving and restoring state into GSettings</a> because resizing manually with the mouse triggers a lot of blocking disk writes and cause the user action to appear sluggish. So I <a href="https://github.com/sonnyp/troll/blob/89e0c822fc6c0d58e7a57ed1f7a8affc05113815/src/util.js#L76-L89">debounce the events and write to gsettings manually</a>.</p>
1693.  
1694. <p><strong>Find text</strong> in the current editor. The keyboard shortcut is Ctrl+F. This is a feature started by Sriyansh Shivam during their <a href="https://sonichere.hashnode.dev/gsoc-2023-final-report#heading-codefind-feature">GSoC 2023 internship</a> and <a href="https://github.com/workbenchdev/Workbench/pull/853">finished</a> by UrtsiSantsi. Thanks!</p>
1695.  
1696. <p><strong>SVG Library entry</strong>. Gtk (via gdk-pixbuf) draws SVGs at their intrisic sizes (what is defined in the svg document). If you use different dimensions for example using <code>GtkImage.pixel-size</code> then it is the pixmap that gets upscaled resulting in pixelated / blurry images. This new Library entry showcases how to render an SVG at arbitrary dimensions using librsvg. We may need a better primitive in the future, if you need an SVG <a href="https://docs.gtk.org/gdk4/iface.Paintable.html">Paintable</a>; GTK Demo contains an example. See also <a href="https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4828">this conversation</a>.</p>
1697.  
1698. <p><img alt="A screenshot of the " src="https://i.snap.as/7LHa8abR.png"/></p>
1699.  
1700. <p><strong>Reveal In Files</strong>. This is a new option available in the menu that will reveal the session/project in Files. You can use it to add assets to your project and load them using <code>workbench.resolve</code> or as icons.</p>
1701.  
1702. <p><strong>Import icons into your projects</strong>. Using the “Reveal In Files” option you can now add custom icons to your projects. It's just a matter of dropping the files in the right folder. See the “Using Icons” Library entry.</p>
1703.  
1704. <p><img alt="A screenshot of the " src="https://i.snap.as/ZW7wEOjG.png"/></p>
1705.  
1706. <p>Workbench included an Icon Library and <a href="https://gitlab.gnome.org/Teams/Design/icon-development-kit">icon-development-kit</a> for a while but in an effort to simplify Workbench and since we already have an <a href="https://flathub.org/apps/org.gnome.design.IconLibrary">Icon Library app</a>, I decided to remove both in favor of per project icons.</p>
1707.  
1708. <p>I'm quite happy with the developer experience there and I hope we can provide something similar in the future to move beyond <code>GtkIconTheme</code>. We probably need to keep <code>icon-name</code> as suggested in <a href="https://blog.gtk.org/2023/02/09/updates-from-inside-gtk/">Updates from inside GTK</a> but I'd be very interested supporting relative paths in GTK Builder. Thankefully we already have GResource to allow for something like</p>
1709.  
1710. <pre><code>Gtk.Image {
1711.  src: "./smile-symbolic.svg";
1712. }
1713. </code></pre>
1714.  
1715. <p><strong>7 new Library entries ported to Vala</strong></p>
1716. <ul><li>Radio Buttons</li>
1717. <li>Switch</li>
1718. <li>Revealer</li>
1719. <li>Styling with CSS</li>
1720. <li>Separator</li>
1721. <li>Level Bars</li>
1722. <li>Link Button</li></ul>
1723.  
1724. <p>Also</p>
1725. <ul><li>“Animation” Library entry ported to Python</li>
1726. <li>Split “List View Widget” Library entry into “List View” and “Grid View”</li>
1727. <li>Fix Vala and Rust extensions detection on “Run”</li>
1728. <li>List editor shortcuts in Shortcuts</li></ul>
1729.  
1730. <p>Thank you contributors and GSoC applicants.</p></div>
1731.    </content>
1732.    <updated>2024-05-01T07:51:52Z</updated>
1733.    <published>2024-05-01T07:51:52Z</published>
1734.    <source>
1735.      <id>https://blog.sonny.re/</id>
1736.      <logo>https://i.snap.as/W5pFkgq1.jpg</logo>
1737.      <author>
1738.        <name>Sonny Piers</name>
1739.      </author>
1740.      <link href="https://blog.sonny.re/" rel="alternate" type="text/html"/>
1741.      <link href="https://blog.sonny.re/feed/" rel="self" type="application/rss+xml"/>
1742.      <title>Sonny's</title>
1743.      <updated>2024-05-19T08:03:38Z</updated>
1744.    </source>
1745.  </entry>
1746.  
1747.  <entry xml:lang="en-US">
1748.    <id>https://foundation.gnome.org/?p=18815</id>
1749.    <link href="https://foundation.gnome.org/2024/04/30/call-for-gnome-asia-2024-location-proposals/" rel="alternate" type="text/html"/>
1750.    <title>Call for GNOME Asia 2024 Location Proposals</title>
1751.    <summary>The GNOME Foundation invites bids for hosting GNOME Asia 2024. This is your chance to bring GNOME Asia to your city! If you are interested in submitting a proposal to host GNOME Asia in your city, please submit an intent to bid by filling out this short form. Intent to Bid submissions are due by […]</summary>
1752.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><strong>The GNOME Foundation invites bids for hosting GNOME Asia 2024. This is your chance to bring GNOME Asia to your city!</strong></p>
1753.  
1754.  
1755.  
1756. <p>If you are interested in submitting a proposal to host GNOME Asia in your city, please submit an intent to bid by filling out this <a href="https://surveys.gnome.org/955854?lang=en">short form</a>. Intent to Bid submissions are due by end-of-day May 15, 2024.</p>
1757.  
1758.  
1759.  
1760. <p>Final proposals should be submitted using our <a href="https://surveys.gnome.org/151549?lang=en">online form</a> and are due by June 6, 2024.</p>
1761.  
1762.  
1763.  
1764. <p>Be prepared to include the following details in your proposal:</p>
1765.  
1766.  
1767.  
1768. <ul>
1769. <li>Location information</li>
1770.  
1771.  
1772.  
1773. <li>A list of local team members</li>
1774.  
1775.  
1776.  
1777. <li>Information about local support (GNOME or open source communities, universities, government or businesses affiliated with GNOME or open source)</li>
1778.  
1779.  
1780.  
1781. <li>Ideas about local sponsors</li>
1782.  
1783.  
1784.  
1785. <li>Venue information</li>
1786.  
1787.  
1788.  
1789. <li>Proposed dates</li>
1790.  
1791.  
1792.  
1793. <li>Travel information (local airports, trains, etc.)</li>
1794.  
1795.  
1796.  
1797. <li>Local transportation (how will attendees get around the city)</li>
1798.  
1799.  
1800.  
1801. <li>Accommodation and dining options</li>
1802.  
1803.  
1804.  
1805. <li>Social event options</li>
1806.  
1807.  
1808.  
1809. <li>Group activity options</li>
1810.  
1811.  
1812.  
1813. <li>Estimated costs and budget for hosting in this location</li>
1814. </ul>
1815.  
1816.  
1817.  
1818. <p><strong>Deadlines</strong><br/>Intention to bid: May 15, 2024<br/>Final proposal submission: June 6, 2024</p>
1819.  
1820.  
1821.  
1822. <p>Proposals from previous years are available for reference and you can talk to the Foundation Board and previous GNOME Asia organizers to find out more about what is involved. If you need more time to finalize your bid please contact <a href="mailto:kprogri@gnome.org">kprogri@gnome.org</a>.</p>
1823.  
1824.  
1825.  
1826. <p>Organizing GNOME ASIA is a large undertaking but local teams will have help from Foundation Staff members and Engagement Team contributors!</p>
1827.  
1828.  
1829.  
1830. <p>If you have any questions, don’t hesitate to contact Kristi at <a href="mailto:kprogri@gnome.org">kprogri@gnome.org</a> or the GNOME Asia team at <a href="mailto:asia@gnome.org">asia@gnome.org</a>.</p>
1831.  
1832.  
1833.  
1834. <p><a href="https://surveys.gnome.org/955854?lang=en">Submit an Intent to Bid</a><br/><a href="https://surveys.gnome.org/151549?lang=en">Submit a Proposal</a></p></div>
1835.    </content>
1836.    <updated>2024-04-30T17:51:41Z</updated>
1837.    <published>2024-04-30T17:51:41Z</published>
1838.    <category term="Events"/>
1839.    <category term="News"/>
1840.    <category term="GNOME.Asia"/>
1841.    <author>
1842.      <name>chenriksen</name>
1843.    </author>
1844.    <source>
1845.      <id>https://foundation.gnome.org</id>
1846.      <logo>https://foundation.gnome.org/wp-content/uploads/sites/12/2020/08/cropped-icon-32x32.jpg</logo>
1847.      <link href="https://foundation.gnome.org/news/feed/" rel="self" type="application/rss+xml"/>
1848.      <link href="https://foundation.gnome.org" rel="alternate" type="text/html"/>
1849.      <subtitle>Building a diverse and sustainable free software ecosystem</subtitle>
1850.      <title>News – The GNOME Foundation</title>
1851.      <updated>2024-05-07T16:46:59Z</updated>
1852.    </source>
1853.  </entry>
1854.  
1855.  <entry>
1856.    <id>https://hansdegoede.dreamwidth.org/28291.html</id>
1857.    <link href="https://hansdegoede.dreamwidth.org/28291.html" rel="alternate" type="text/html"/>
1858.    <title>Moving GPU drivers out of the initramfs</title>
1859.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">The firmware which drm/kms drivers need is becoming bigger and bigger and there is a push to move to generating a generic initramfs on distro's builders and signing the initramfs with the distro's keys for security reasons. When targetting desktops/laptops (as opposed to VMs) this means including firmware for all possible GPUs which leads to a very big initramfs.<br/><br/>This has made me think about dropping the GPU drivers from the initramfs  and instead make plymouth work well/better with simpledrm (on top of efifb). A while ago I discussed making this change for Fedora with the Red Hat graphics team spoiler: For now nothing is going to change.<br/><br/>Let me repeat that: For now there are no plans to implement this idea so if you believe you would be impacted by such a change: Nothing is going to change.<br/><br/>Still this is something worthwhile to explore further.<br/><br/><span style="font-size: large;">Advantages:</span><br/><br/>1. Smaller initramfs size:<br/><br/>* E.g. a host specific initramfs with amdgpu goes down from 40MB to 20MB<br/>* No longer need to worry about Nvidia GSP firmware size in initrd<br/>* This should also significantly shrink the initrd used in liveimages<br/><br/>2. Faster boot times:<br/><br/>* Loading + unpacking the initrd can take a surprising amount of time. E.g. on my old AMD64 embedded PC (with BobCat cores) the reduction of 40MB -&gt; 20MB in initrd size shaves approx. 3 seconds of initrd load time + 0.6s seconds from the time it takes to unpack the initrd<br/>*  Probing drm connectors can be slow and plymouth blocks the initrd -&gt; rootfs transition while it is busy probing<br/><br/>3. Earlier showing of splash. By using simpledrm for the splash the splash can be shown earlier, avoiding the impression the machine is hanging during boot. An extreme example of this is my old AMD64 embedded PC, where the time to show the first frame of the splash goes down from 47 to 9 seconds.<br/><br/>4. One less thing to worry about when trying to create a uniform  desktop pre-generated and signed initramfs (these would still need  support for nvme + ahci and commonly used rootfs + lvm +  luks).<br/><div> </div><span style="font-size: large;">Disadvantages:<br/><br/></span>Doing this will lead to user visible changes in the boot process:<br/><br/>1. Secondary monitors not lit up by the efifb will stay black during full-disk encryption password entry, since the GPU drivers will now only load after switching to the encrypted root. This includes any monitors connected to the non boot GPU in dual GPU setups.<br/><br/><div>Generally speaking this is not really an issue, the secondary monitors will light up pretty quickly after the switch to the real rootfs. However when booting a docked laptop, with the lid closed and the only visible monitor(s) are connected to the non boot GPU, then the full-disk encryption password dialog will simply not be visible at all.<br/><br/>This is the main deal-breaker for not implementing this change. <br/><br/>Note because of the strict version lock between kernel driver and userspace with nvidia binary drivers, the nvidia binary drivers are usually already not part of the initramfs, so this problem already exists and moving the GPU drivers out of the initramfs does not really make this worse.</div><br/>2. With simpledrm plymouth does not get the physical size of the monitor, so plymouth will need to switch to using <a href="https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/01702de71a93d9a0a4ddbed697fb14b9ad6ed4bf">heuristics on the resolution</a> instead of DPI info to decide whether or not to use hidpi (e.g. 2x size) rendering and even when switching to the real GPU driver plymouth needs to stay with its initial heuristics based decision to avoid the scaling changing when switching to the real driver which would lead to a big visual glitch / change halfway through the boot.<br/><br/>This may result in a different scaling factor for some setups, but I do not expect this really to be an issue.<br/><br/>3. On some (older) systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768.<br/><br/>This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600.<br/><br/>One possible workaround here is to add: 'video=efifb:auto' to the kernel commandline which will make the efistub switch to the highest available resolution before starting the kernel. But it seems that the native modes are simply not there on systems which come up at 800x600 / 1024x768 so this does not really help.<br/><br/>This does not actually break anything but it does look a bit ugly. So we will just need to document this as an unfortunate side-effect of the change and then we (and our users) will have to live with this (on affected hardware).<br/><br/>4. On systems where a full modeset is done the monitor going briefly black from the modeset will move from being just before plymouth starts to the switch from simpledrm drm to the real driver. So that is slightly worse. IMHO the answer here is to try and get fast modesets working on more systems.<br/><br/>5. On systems where the efifb comes up in the panel's native mode and a fast modeset can be done, the spinner will freeze for a (noticeable) fraction of a second as the switch to the real driver happens.<br/><span style="font-size: larger;"><br/></span><span style="font-size: large;">Preview:</span><br/><br/>To get an impression what this will look / feel like on your own systems, you can implement this right now on Fedora 40 with some manual configuration changes:<br/><br/>1. Create /etc/dracut.conf.d/omit-gpu-drivers.conf with:<br/><br/>omit_drivers+=" amdgpu radeon nouveau i915 "<br/><br/>And then run "sudo dracut -f" to regenerate your current initrd.<br/><br/>2. Add to kernel commandline: "plymouth.use-simpledrm"<br/><br/>3. Edit /etc/selinux/config, set SELINUX=permissive this is necessary because ATM plymouth has <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1945685">issues with accessing drm devices</a> after the chroot from the initrd to the rootfs.<br/><br/>Note this all assumes EFI booting with efifb used to show the plymouth boot splash. For classic BIOS booting it is probably best to stick with having the GPU drivers inside the initramfs.<br/><br/><img alt="comment count unavailable" height="12" src="https://www.dreamwidth.org/tools/commentcount?user=hansdegoede&amp;ditemid=28291" style="vertical-align: middle;" width="30"/> comments</div>
1860.    </summary>
1861.    <updated>2024-04-29T13:13:02Z</updated>
1862.    <published>2024-04-29T13:13:02Z</published>
1863.    <category term="plymouth"/>
1864.    <category term="fedora"/>
1865.    <category term="initramfs"/>
1866.    <source>
1867.      <id>https://hansdegoede.dreamwidth.org/</id>
1868.      <logo>https://v.dreamwidth.org/16479769/3892031</logo>
1869.      <author>
1870.        <name>Hans de Goede</name>
1871.      </author>
1872.      <link href="https://hansdegoede.dreamwidth.org/" rel="alternate" type="text/html"/>
1873.      <link href="https://hansdegoede.dreamwidth.org/data/rss" rel="self" type="application/rss+xml"/>
1874.      <subtitle>Hans de Goede - Dreamwidth Studios</subtitle>
1875.      <title>Hans de Goede</title>
1876.      <updated>2024-04-29T13:13:02Z</updated>
1877.    </source>
1878.  </entry>
1879.  
1880.  <entry xml:lang="en-US">
1881.    <id>https://ramcq.net/?p=278</id>
1882.    <link href="https://ramcq.net/2024/04/26/update-from-the-gnome-board/" rel="alternate" type="text/html"/>
1883.    <title>Update from the GNOME board</title>
1884.    <summary>It’s been around 6 months since the GNOME Foundation was joined by our new Executive Director, Holly Million, and the board and I wanted to update members on the Foundation’s current status and some exciting upcoming changes. Finances As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a […]</summary>
1885.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>It’s been around 6 months since the GNOME Foundation was joined by our new Executive Director, Holly Million, and the board and I wanted to update members on the Foundation’s current status and some exciting upcoming changes.</p>
1886.  
1887.  
1888.  
1889. <h1 class="wp-block-heading">Finances</h1>
1890.  
1891.  
1892.  
1893. <p>As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a loss – ie spending more than we’ve been raising each year) for over three years, essentially running the Foundation on reserves from some substantial donations received 4-5 years ago. The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We’ve now “hit the buffers” of this reserves policy, meaning the Board can’t approve any more deficit budgets – to keep spending at the same level we must increase our income.</p>
1894.  
1895.  
1896.  
1897. <p>One of the board’s top priorities in hiring Holly was therefore her experience in communications and fundraising, and building broader and more diverse support for our mission and work. Her goals since joining – as well as building her familiarity with the community and project – have been to set up better financial controls and reporting, develop a strategic plan, and start fundraising. You may have noticed the Foundation being more cautious with spending this year, because Holly prepared a break-even budget for the Board to approve in October, so that we can steady the ship while we prepare and launch our new fundraising initiatives.</p>
1898.  
1899.  
1900.  
1901. <h1 class="wp-block-heading">Strategy &amp; Fundraising</h1>
1902.  
1903.  
1904.  
1905. <p>The biggest prerequisite for fundraising is a clear strategy – we need to explain what we’re doing and why it’s important, and use that to convince people to support our plans. I’m very pleased to report that Holly has been working hard on this and meeting with many stakeholders across the community, and has prepared a detailed and insightful five year strategic plan. The plan defines the areas where the Foundation will prioritise, develop and fund initiatives to support and grow the GNOME project and community. The board has approved a draft version of this plan, and over the coming weeks Holly and the Foundation team will be sharing this plan and running a consultation process to gather feedback input from GNOME foundation and community members.</p>
1906.  
1907.  
1908.  
1909. <p>In parallel, Holly has been working on a fundraising plan to stabilise the Foundation, growing our revenue and ability to deliver on these plans. We will be launching a variety of fundraising activities over the coming months, including a development fund for people to directly support GNOME development, working with professional grant writers and managers to apply for government and private foundation funding opportunities, and building better communications to explain the importance of our work to corporate and individual donors.</p>
1910.  
1911.  
1912.  
1913. <h1 class="wp-block-heading">Board Development</h1>
1914.  
1915.  
1916.  
1917. <p>Another observation that Holly had since joining was that we had, by general nonprofit standards, a very small board of just 7 directors. While we do have some committees which have (very much appreciated!) volunteers from outside the board, our officers are usually appointed from within the board, and many board members end up serving on multiple committees and wearing several hats. It also means the number of perspectives on the board is limited and less representative of the diverse contributors and users that make up the GNOME community.</p>
1918.  
1919.  
1920.  
1921. <p>Holly has been working with the board and the governance committee to reduce how much we ask from individual board members, and improve representation from the community within the Foundation’s governance. Firstly, the board has decided to increase its size from 7 to 9 members, effective from the upcoming elections this May &amp; June, allowing more voices to be heard within the board discussions. After that, we’re going to be working on opening up the board to more participants, creating non-voting officer seats to represent certain regions or interests from across the community, and take part in committees and board meetings. These new non-voting roles are likely to be appointed with some kind of application process, and we’ll share details about these roles and how to be considered for them as we refine our plans over the coming year.</p>
1922.  
1923.  
1924.  
1925. <h1 class="wp-block-heading">Elections</h1>
1926.  
1927.  
1928.  
1929. <p>We’re really excited to develop and share these plans and increase the ways that people can get involved in shaping the Foundation’s strategy and how we raise and spend money to support and grow the GNOME community. This brings me to my final point, which is that we’re in the run up to the annual board elections which take place in the run up to GUADEC. Because of the expansion of the board, and four directors coming to the end of their terms, we’ll be electing 6 seats this election. It’s really important to Holly and the board that we use this opportunity to bring some new voices to the table, leading by example in growing and better representing our community.</p>
1930.  
1931.  
1932.  
1933. <p>Allan wrote in the past about <a href="https://blogs.gnome.org/aday/2021/05/24/gnome-foundation-board-elections-2021/">what the board does</a> and what’s expected from directors. As you can see we’re working hard on reducing what we ask from each individual board member by increasing the number of directors, and bringing additional members in to committees and non-voting roles. If you’re interested in seeing more diverse backgrounds and perspectives represented on the board, I would strongly encourage you consider standing for election and reach out to a board member to discuss their experience.</p>
1934.  
1935.  
1936.  
1937. <p>Thanks for reading! Until next time.</p>
1938.  
1939.  
1940.  
1941. <p>Best Wishes,<br/>Rob<br/>President, GNOME Foundation</p>
1942.  
1943.  
1944.  
1945. <p><strong>Update 2024-04-27</strong>: It was <a href="https://discourse.gnome.org/t/update-from-the-board/20653/2">suggested in the Discourse thread</a> that I clarify the interaction between the break-even budget and the <a href="https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/">1M EUR committed by the STF project</a>. This money is received in the form of a contract for services rather than a grant to the Foundation, and must be spent on the development areas agreed during the planning and application process. It’s included within this year’s budget (October 23 – September 24) and is all expected to be spent during this fiscal year, so it doesn’t have an impact on the Foundation’s reserves position. The Foundation retains a small % fee to support its costs in connection with the project, including the new requirement to have our accounts externally audited at the end of the financial year. We are putting this money towards recruitment of an administrative assistant to improve financial and other operational support for the Foundation and community, including the STF project and future development initiatives.</p>
1946.  
1947.  
1948.  
1949. <p><em>(also posted to <a href="https://discourse.gnome.org/t/update-from-the-board/20653">GNOME Discourse</a>, please head there if you have any questions or comments)</em></p></div>
1950.    </content>
1951.    <updated>2024-04-26T10:39:06Z</updated>
1952.    <published>2024-04-26T10:39:06Z</published>
1953.    <category term="GNOME"/>
1954.    <category term="gnome"/>
1955.    <author>
1956.      <name>ramcq</name>
1957.    </author>
1958.    <source>
1959.      <id>https://ramcq.net</id>
1960.      <link href="https://ramcq.net/feed/" rel="self" type="application/rss+xml"/>
1961.      <link href="https://ramcq.net" rel="alternate" type="text/html"/>
1962.      <subtitle>The personal blog of Robert McQueen</subtitle>
1963.      <title>Robotic Tendencies</title>
1964.      <updated>2024-04-27T08:16:35Z</updated>
1965.    </source>
1966.  </entry>
1967.  
1968.  <entry>
1969.    <id>https://olea.org/diario/2024/04/26/Small_GLAM_Slam_project__update.html</id>
1970.    <link href="https://olea.org/diario/2024/04/26/Small_GLAM_Slam_project__update.html" rel="alternate" type="text/html"/>
1971.    <title>Small GLAM Slam Pilot 1 project update</title>
1972.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><img alt="Wikibase logotype" class="pull-right" src="https://olea.org/recursos/Wikibase.png" width="250"/></p>
1973.  
1974. <p>This is a project update for the SGS Pilot 1 project. This is a WMF funded project  (<a href="https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Community_Fund/Rapid_Fund/SMALL_GLAM_SLAM_Pilot_1_(ID:_22444585)" title="Grants:Programs/Wikimedia Community Fund/Rapid Fund/SMALL GLAM SLAM Pilot 1 (ID: 22444585)">ID: 22444585</a>).</p>
1975.  
1976. <p>They have been created two relevant places:</p>
1977.  
1978. <ul>
1979.  <li>Phabricator: <a href="https://phabricator.wikimedia.org/tag/verysmallglam/">VerySmallGLAM · Workboard</a></li>
1980.  <li>Meta: <a href="https://meta.wikimedia.org/wiki/Very_Small_GLAM">Very Small GLAM</a></li>
1981. </ul>
1982.  
1983. <p>You can observe que are now using the coined term «Very Small GLAM». This will be the activity scope from now as we consider it short and and precise. The Small GLAM Slam denomination will be kept for the ID: 22444585 project.</p>
1984.  
1985. <p>What the Very Small GLAM term refers to? It identifies GLAM entities of very small size. How small? We got the inspiration from the concept of VSE (very small entities) coined for the <a href="https://committee.iso.org/sites/jtc1sc7/home/projects/flagship-standards/isoiec-29110-series.html">ISO/IEC 29110 Series</a> for software development entities up to 25 members. To set a focus we, a bit arbitrarily, chose the number 5 as <strong>«up to 5» members</strong> an institution or team working in GLAM. Very Small GLAM non circunscribes to Open GLAM, but Open GLAM would probably be the best approach or complement for this teams with not so much resources.</p>
1986.  
1987. <p><img alt="Wikimedia LEADS logotype" class="pull-right" src="https://olea.org/recursos/Wikimedia_LEADS-logo.png" width="80"/></p>
1988.  
1989. <h2 id="wikimedia-leads-spin-off">Wikimedia LEADS spin-off</h2>
1990.  
1991. <p>An unexpected spin-off has been the conceptualization of the new initiative, <a href="https://laoficinacultural.org/wikimedia-leads/">Wikimedia LEADS</a> (Learning Ecosystems and Ameliorating Data Space) when attending EU’s Next Generation Internet (NGI) funding call.  The goal is to develop an advanced learning free/open data space and software ecosystem for the <strong><a href="https://meta.wikimedia.org/wiki/Wikimedia_movement/">Wikimedia Movement</a></strong>.</p>
1992.  
1993. <p>Wikimedia LEADS first goal is to attend the <strong><a href="https://meta.wikimedia.org/wiki/GLAM">GLAM Wiki</a></strong> learning needs. GLAM Wiki also shares a lot of commonalities with the <strong><a href="https://europeana.eu/">Europeana</a></strong> community.</p>
1994.  
1995. <p>By extension, all practices, tools and many of the specific contents will be applicable to all other areas of the human knowledge.</p>
1996.  
1997. <h2 id="projects-activity-areas">Project’s activity areas</h2>
1998.  
1999. <p>The SGS Pilot 1 is now structured in these work-packages:</p>
2000.  
2001. <ul>
2002.  <li>WP1—IT system developed with the <a href="https://forums.serverbuilds.net/search?q=NAS%20Killer">NAS killer concept</a> with a free software stack for GLAM;</li>
2003.  <li>WP2—configuration for a locally installed Wikibase suite;</li>
2004.  <li>WP3—GLAM ontologies and vocabularies;</li>
2005.  <li>WP4—GLAM practices.</li>
2006.  <li>WP5—data import.</li>
2007. </ul>
2008.  
2009. <h2 id="wp1it-system-update">WP1—IT system, update</h2>
2010.  
2011. <p>The selected operating system is UNRAID. The technical justifications are:</p>
2012.  
2013. <ul>
2014.  <li>it’s a Linux distribution;</li>
2015.  <li>it features the ZFS file system, probably the best alternative for data preservation;</li>
2016.  <li>has a graphic administration interface</li>
2017.  <li>and run on any PC compatible hardware.</li>
2018. </ul>
2019.  
2020. <p>At this point the most important update about UNRAID is, since the grant approval, it changed their licensing model and fees.</p>
2021.  
2022. <p>Current project hardware details are:</p>
2023.  
2024. <ul>
2025.  <li>a received a donated <a href="https://support.hp.com/us-en/document/c01709672">HP Z400 system</a>, which happily includes an SSD disk;</li>
2026.  <li>procured 24 GB of ECC RAM, PC3-10600E, the maximum supported by the board.</li>
2027. </ul>
2028.  
2029. <p>In the next days we’ll buy the three HGST hard drives and other minor components for the firsts tests.</p>
2030.  
2031. <p>For the system configuration development phase, we’ll use another lend computer as a test server.</p>
2032.  
2033. <h3 id="software-systems">Software systems</h3>
2034.  
2035. <p>This is a proposal of software architecture for a local installation of Wikibase in a GLAM context:</p>
2036.  
2037. <p/>
2038.  
2039. <p>There is not advances to report about software.</p>
2040.  
2041. <h2 id="wp2wikibase-suite-configuration-update">WP2—Wikibase suite configuration, update</h2>
2042.  
2043. <p>As we are not still familiar with the Wikibase ecosystem we are practicing setting up some instances in <a href="https://wikibase.cloud/">Wikibase.cloud</a>.
2044. Also, we are starting to identify relevant Wikibase features. We are using <a href="https://wikibase.world/">wikibase.world</a> as inventory of:</p>
2045.  
2046. <ul>
2047.  <li><a href="https://wikibase.world/query/#PREFIX%20wd%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fentity%2F%3E%0APREFIX%20wdt%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fprop%2Fdirect%2F%3E%0A%0ASELECT%20%3Fitem%20%3FitemLabel%20WHERE%20%7B%0A%20%20%20%20%3Fitem%20wdt%3AP3%20wd%3AQ95%20.%0A%20%20%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D">gadgets</a></li>
2048.  <li><a href="https://wikibase.world/query/#PREFIX%20wd%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fentity%2F%3E%0APREFIX%20wdt%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fprop%2Fdirect%2F%3E%0A%0ASELECT%20%3Fitem%20%3FitemLabel%20WHERE%20%7B%0A%20%20%20%20%3Fitem%20wdt%3AP3%20wd%3AQ222%20.%0A%20%20%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D">Wikibase extensions</a></li>
2049.  <li><a href="https://wikibase.world/query/#PREFIX%20wd%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fentity%2F%3E%0APREFIX%20wdt%3A%20%3Chttps%3A%2F%2Fwikibase.world%2Fprop%2Fdirect%2F%3E%0A%0ASELECT%20%3Fitem%20%3FitemLabel%20WHERE%20%7B%0A%20%20%20%20%3Fitem%20wdt%3AP3%20wd%3AQ61%20.%0A%20%20%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D">Mediawiki extensions</a></li>
2050. </ul>
2051.  
2052. <h2 id="wp3glam-ontologies-and-vocabularies-update">WP3—GLAM ontologies and vocabularies, update</h2>
2053.  
2054. <p>Here we have the most juicy results for the moment. After a papers research we identified the  <strong>CIDOC Conceptual Reference Model</strong> (CIDOC-CRM) as an international reference model for museums. It’s more relevant when you find it’s being used as a reference for mapping or extending to other domains like <strong>CRMdig</strong> (digitalization) and <strong>CRMsoc</strong> (social phenomena and constructs), which are relevant for the «Memorias del Cine» archive. Very relevant is the availability of a <a href="https://raw.githubusercontent.com/erlangen-crm/ecrm/master/ecrm_current.owl">CRM OWL ontology</a> (non official, but apparently up to date) and some minor Wikidata mapping (<a href="https://w.wiki/9r$s">https://w.wiki/9r$s</a>, 24 items)
2055. Also, we identified the <strong>Records in Contexts–Conceptual Model</strong>  (RiC-CM), whose ontology is also published in OWL format. RiC-CM is a reference for archival and we found initial works for CRM &lt;-&gt; RiC-CM mapping. The current mapping with Wikidata is anecdotal (<a href="https://w.wiki/9sAh">https://w.wiki/9sAh</a>, 4 items).</p>
2056.  
2057. <p>In the context of models of practices we are learning about SEMAT Essence. The formal specifications are expressed in text and in a UML metamodel file (.xmi). The concept of metamodel is practically equivalent to the LOD ontology. It took a while but now we know more about how to manage this XMI formats using Magic Draw. The plan is to import the ontology to Wikibase using the same tools than for CRM and related. We found the Essence «Package Competency» model is relevant for populating a map of competences/abilities for the Movement, as Wikimedia LEADS proposes.</p>
2058.  
2059. <p>For managing this information we are getting familiar with tools like Protégé, Fuseki, Magic Draw and some others.</p>
2060.  
2061. <p>A very happily discovery has been a couple set of tools for mapping and importing to Wikibase ontologies based in CIDOC-CRM. They are output of the projects SAF-Lux and GeoKB. We expect we’ll make intensive use of them or their derivatives.</p>
2062.  
2063. <p>An open question is, do we need to create a new Wikidata property for <em>CRM identifier</em>? Probably yes. I’m <a href="https://www.wikidata.org/wiki/User:Olea/Things_about_archives">keeping some notes about ontologies for archival</a> in my Wikidata user page.</p>
2064.  
2065. <h2 id="wp4glam-practices-update">WP4—GLAM practices, update</h2>
2066.  
2067. <p>There is not so much real work on this side, since we are not ready to work modeling with Essence. But we are collecting some relevant bibliography for the project scope:</p>
2068.  
2069. <ul>
2070.  <li>C. Matos, Manual práctico para la digitalización de colecciones para difusión digital, 2022.</li>
2071.  <li>A. Salvador Benítez, Ed., Patrimonio fotográfico: de la visibilidad a la gestión. en Biblioteconomía y administración cultural, no. 280. Gijón: Trea, 2015.</li>
2072.  <li>J. M. Sánchez Vigil, A. Salvador Benítez, y M. Olivera Zaldua, Colecciones y fondos fotográficos: criterios metodológicos, estrategias y protocolos de actuación, Primera edición. en Museología y patrimonio cultural. Gijón: Ediciones Trea, 2022.</li>
2073.  <li>Collections Trust, Spectrum 5.1: UK Collections Management Standard, 2022.</li>
2074.  <li>Centro de Fotografía de Motevideo, Guía del archivo fotográfico, 2017.</li>
2075.  <li>L. Bountouri, Archives in the digital age: standards, policies and tools. en Chandos Information Professional Series. Cambridge, MA: Chandos Publishing, an imprint of Elsevier, 2017.</li>
2076. </ul>
2077.  
2078. <h2 id="wp5data-import-update">WP5—data import, update</h2>
2079.  
2080. <p>There have been not activity. We’ll start the data import when we have a first server operating.</p>
2081.  
2082. <h2 id="dissemination">Dissemination</h2>
2083.  
2084. <p>Strictly focused in the SGS Pilot 1:</p>
2085.  
2086. <ul>
2087.  <li><a href="https://olea.org/diario/2024/04/16/taller_Wikibase_Murcia.html">Wikibase workshop</a> at the University of Murcia;</li>
2088.  <li>a poster session proposal for Wikimania: <a href="https://wikimania.eventyay.com/2024/talk/review/NE78XASWLEDSN3LUUDYZWHA9KWMDQDHR">Towards a Very Small GLAM entities solution</a>;</li>
2089.  <li>and some proposed activities for the <a href="https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024">Wikimedia Hackathon 2024</a>:
2090.    <ul>
2091.      <li><a href="https://phabricator.wikimedia.org/T363562">Towards a Very Small GLAM entities solution</a>, presentation;</li>
2092.      <li><a href="https://phabricator.wikimedia.org/T363556">curate features for Wikibase</a>, a hacking session;</li>
2093.      <li><a href="https://phabricator.wikimedia.org/T363555">importing ontologies/vocabularies into Wikibase and Wikidata</a>, another hacking session.</li>
2094.    </ul>
2095.  </li>
2096. </ul>
2097.  
2098. <p>Related to Wikimedia LEADS:</p>
2099.  
2100. <ul>
2101.  <li>a poster session proposal for Wikimania: <a href="https://wikimania.eventyay.com/2024/talk/review/38BD8Z7UARM8NXQKA9R9VNJS8SHHARHM">Wikimedia LEADS a Learning Ecosystem and Ameliorating Data Space</a>;</li>
2102.  <li>and a session proposal for the Wikimedia Hackathon:  <a href="https://phabricator.wikimedia.org/T363570">Wikimedia LEADS a Learning Ecosystem and Ameliorating Data Space</a>.</li>
2103. </ul>
2104.  
2105. <h2 id="whats-next">What’s next</h2>
2106.  
2107. <p>In the next days we’ll procure the pending hardware component to set up the server prototype. Then we’ll define the configuration and procedure to set up an UNRAID server instance ready for data preservation tasks. Then we’ll migrate the multimedia archive of «Memorias del Cine» to the server. The fun part of cataloging the archive in Wikibase would start as soon as we have an stable ontology model for digital archives.</p>
2108.  
2109. <p>Also, in May I’ll be attending the <a href="https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024">Wikimedia Hackathon</a> in Tallinn and the <a href="https://meta.wikimedia.org/wiki/AI_Sauna">AI Sauna</a>  in Helskinki. Reach me there in person if you are interested in our work.</p>
2110.  
2111. <p>PS: Adding references to WP5 (20240430).</p></div>
2112.    </summary>
2113.    <updated>2024-04-25T22:00:00Z</updated>
2114.    <published>2024-04-25T22:00:00Z</published>
2115.    <category term="Wikimedia_Movement"/>
2116.    <category term="LaOficina"/>
2117.    <category term="SMALL_GLAM_SLAM"/>
2118.    <category term="GLAM"/>
2119.    <category term="Very_Small_GLAM"/>
2120.    <source>
2121.      <id>https://olea.org/</id>
2122.      <author>
2123.        <name>Ismael Olea</name>
2124.      </author>
2125.      <link href="https://olea.org/" rel="alternate" type="text/html"/>
2126.      <link href="https://olea.org/feed-en.xml" rel="self" type="application/rss+xml"/>
2127.      <subtitle>Pastoreando procomunes desde 1994 — Shepherding the commons since 1994
2128. - just the English posts</subtitle>
2129.      <title>Ismael Olea — web personal</title>
2130.      <updated>2024-05-17T09:17:24Z</updated>
2131.    </source>
2132.  </entry>
2133.  
2134.  <entry>
2135.    <id>https://tirania.org/blog/archive/2024/Apr-23.html</id>
2136.    <link href="https://tirania.org/blog/archive/2024/Apr-23.html" rel="alternate" type="text/html"/>
2137.    <title>23 Apr 2024</title>
2138.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><h1 id="embeddable-game-engine">Embeddable Game Engine</h1>
2139. <p><img align="right" src="https://migueldeicaza.github.io/SwiftGodotDocs/images/SwiftGodot%20Header.png" width="240"/>
2140. Many years ago, when working at Xamarin, where we were building cross-platform
2141. libraries for mobile developers, we wanted to offer both 2D and 3D gaming
2142. capabilities for our users in the form of adding 2D or 3D content to their
2143. mobile applications.</p>
2144. <p>For 2D, we contributed and developed assorted Cocos2D-inspired libraries.</p>
2145. <p>For 3D, the situation was more complex. We funded a few over the years, and we
2146. contributed to others over the years, but nothing panned out (the
2147. history of this is worth a dedicated post).</p>
2148. <p>Around 2013, we looked around, and there were two contenders at the
2149. time, one was an embeddable engine with many cute features but not great UI
2150. support called Urho, and the other one was a <a href="https://en.wikipedia.org/wiki/Godot_(game_engine)">Godot</a>, which had a great IDE, but
2151. did not support being embedded.</p>
2152. <p>I reached out to Juan at the time to discuss whether Godot could be turned into
2153. such engine.   While I tend to take copious notes of all my meetings, those
2154. notes sadly were gone as part of the Microsoft acquisition, but from what I can
2155. remember Juan told me, "Godot is not what you are looking for" in two dimensions,
2156. there were no immediate plans to turn it into an embeddable library, and it was
2157. not as advanced as Urho, so he recommended that I go with Urho.</p>
2158. <p>We invested heavily in binding Urho and created
2159. <a href="https://github.com/xamarin/urho">UrhoSharp</a> that would go into becoming a <a href="https://devblogs.microsoft.com/xamarin/bring-3d-models-life-augmented-reality-urhosharp/">great
2160. 3D library for our C# users</a> and worked not only on every desktop and mobile
2161. platform, but we did a ton of work to make it great for AR and VR headsets.
2162. Sadly, Microsoft's management left UrhoSharp to die.</p>
2163. <p>Then, the maintainer of Urho stepped down, and Godot became one of the most
2164. popular open-source projects in the world.</p>
2165. <p>Last year, @Faolan-Rad <a href="https://github.com/godotengine/godot/pull/72883">contributed a patch to Godot</a> to turn it into a library
2166. that could be embedded into applications.   I used this library to build
2167. <a href="https://github.com/migueldeicaza/SwiftGodotKit">SwiftGodotKit</a> and have been
2168. very happy with it ever since - allowing people to embed Godot content into
2169. their application.</p>
2170. <p>However, the patch had severe limitations; it could only ever run one Godot game as
2171. an embedded system and could not do much more.   The folks at <a href="https://www.smirk.gg">Smirk
2172. Software</a> wanted to take this further. They wanted to host
2173. independent Godot scenes in their app and have more control over those so
2174. they could sprinkle Godot content at their heart's content on their mobile app (<a href="https://x.com/JoshBromberg1/status/1721564103859114132">demo</a>)</p>
2175. <p>They funded some initial work to do this and hired <a href="https://migeran.com">Gergely
2176. Kis's company</a> to do this work.</p>
2177. <p>Gergely demoed this work at GodotCon last year.   I came back very excited from
2178. GodotCon and I decided to turn my <a href="https://x.com/migueldeicaza/status/1723765594653167892">prototype Godot on iPad</a> into a <a href="https://blog.la-terminal.net/igodot/">complete
2179. product</a>.</p>
2180. <p>One of the features that I needed was the ability to embed chunks of Godot in
2181. discrete components in my iPad UI, so we worked with Gergely to productize and
2182. polish this patch for general consumption.</p>
2183. <p>Now, there is a <a href="https://github.com/godotengine/godot/pull/90510">complete patch under review</a> to allow people to embed arbitrary
2184. Godot scenes into their apps.   For SwiftUI users, this means that you can embed a Godot scene into a <code>View</code> and display and control it at will.</p>
2185. <p>Hopefully, the team will accept this change into Godot, and once this is done, I will
2186. update SwiftGodotKit to get these new capabilities to Swift users (bindings for
2187. other platforms and languages are left as an exercise to the reader).</p>
2188. <p>It only took a decade after talking to Juan, but I am back firmly in Godot land.</p></div>
2189.    </summary>
2190.    <updated>2024-04-24T01:41:00Z</updated>
2191.    <published>2024-04-24T01:41:00Z</published>
2192.    <author>
2193.      <name>Miguel de Icaza</name>
2194.      <email>miguel.de.icaza@gmail.com</email>
2195.    </author>
2196.    <source>
2197.      <id>https://tirania.org/blog//index.html</id>
2198.      <author>
2199.        <name/>
2200.        <email>miguel.de.icaza@gmail.com</email>
2201.      </author>
2202.      <link href="https://tirania.org/blog//index.html" rel="alternate" type="text/html"/>
2203.      <link href="http://www.tirania.org/blog/miguel.rss2" rel="self" type="application/rss+xml"/>
2204.      <rights>Miguel de Icaza</rights>
2205.      <subtitle>Miguel de Icaza's Blog</subtitle>
2206.      <title>Miguel de Icaza</title>
2207.      <updated>2024-04-23T21:41:00Z</updated>
2208.    </source>
2209.  </entry>
2210.  
2211.  <entry xml:lang="en-US">
2212.    <id>https://blogs.gnome.org/shell-dev/?p=3094</id>
2213.    <link href="https://blogs.gnome.org/shell-dev/2024/04/23/notifications-46-and-beyond/" rel="alternate" type="text/html"/>
2214.    <link href="https://blogs.gnome.org/shell-dev/files/2024/04/threads-white.webm" length="1931355" rel="enclosure" type="video/webm"/>
2215.    <title>Notifications in 46 and beyond</title>
2216.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">One of the things we’re tackling as part of the STF infrastructure initiative is improving notifications. Other platforms have advanced significantly in this area over the past decade, while we still have more or less the same notifications we had since the early GNOME 3 days, both in terms of API and feature set. There’s … <p class="link-more"><a class="more-link" href="https://blogs.gnome.org/shell-dev/2024/04/23/notifications-46-and-beyond/">Continue reading<span class="screen-reader-text"> "Notifications in 46 and beyond"</span></a></p></div>
2217.    </summary>
2218.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><div class="markdown-body container-fluid" id="doc">
2219. <p>One of the things we’re tackling as part of the <a href="https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure" rel="noopener" target="_blank">STF infrastructure initiative</a> is improving notifications. Other platforms have advanced significantly in this area over the past decade, while we still have more or less the same notifications we had since the early GNOME 3 days, both in terms of API and feature set. There’s plenty to do here <img alt="&#x1F642;" class="wp-smiley" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f642.png" style="height: 1em;"/></p>
2220. <figure class="wp-caption alignnone" id="attachment_3106" style="width: 948px;"><a href="https://blogs.gnome.org/shell-dev/files/2024/04/notifications-45.png"><img alt="" class="wp-image-3106 size-full" height="949" src="https://blogs.gnome.org/shell-dev/files/2024/04/notifications-45.png" width="948"/></a><figcaption class="wp-caption-text" id="caption-attachment-3106">The notification drawer on GNOME 45</figcaption></figure>
2221. <h2 id="Modern-needs">Modern needs</h2>
2222. <p>As part of the effort to port GNOME Shell to mobile Jonas looked into the delta between what we currently support and what we’d need for a more modern notification experience. Some of these limitations are specific to GNOME’s implementation, while others are relevant to all desktops.</p>
2223. <h4 id="Tie-notifications-to-apps">Tie notifications to apps</h4>
2224. <p>As of GNOME 45 there’s no clear identification on notification bubbles which app they were sent by. Sometimes it’s hard to tell where a notification is coming from, which can be annoying when managing notifications in Settings. This also has potential security implications, since the lack of identification makes it trivial to impersonate other apps.</p>
2225. <p>We want all notifications to be clearly identified as coming from a specific app.</p>
2226. <h4 id="Global-notification-sounds">Global notification sounds</h4>
2227. <p>GNOME Shell can’t play notification sounds in all cases, depending on the API the app is using (see below). Apps not primarily targeting GNOME Shell directly tend to play sounds themselves because they can’t rely on the system always doing it (it’s an optional feature of the XDG Notification API which different desktops handle differently). This works, but it’s messy for app developers because it’s hard to test and they have to implement a fallback sound played by the app. From a user perspective it’s annoying that you can’t always tell where sounds are coming from because they’re not necessarily tied to a notification bubble. There’s also no central place to manage the notification behavior and it doesn’t respect Do Not Disturb.</p>
2228. <h4 id="A-single-messy-list">Notification grouping</h4>
2229. <p>Currently all notifications are just added to a single chronological list, which gets messy very quickly. In order to limit the length of the list we only keep the latest 3 notifications for every app, so notifications can disappear before you have a chance to act on them.</p>
2230. <p>Other platforms solve this by grouping notifications by app, or even by message thread, but we don’t have anything like this at the moment.</p>
2231. <figure class="wp-caption alignnone" id="attachment_3145" style="width: 380px;"><img alt="" class="wp-image-3145" height="495" src="https://blogs.gnome.org/shell-dev/files/2024/04/ios-grouping.png" width="380"/><figcaption class="wp-caption-text" id="caption-attachment-3145">Notifications grouped by app on the iOS lock screen</figcaption></figure>
2232. <h4 id="Limited-media-support">Expand media support</h4>
2233. <p>Currently each notification bubble can only contain one (small) image. It’s mostly used for user avatars (for messages, emails, and the like), but sometimes also for actual content (e.g. a thumbnail for the image someone sent).</p>
2234. <p>Ideally what we want is to be able to show larger images in addition to avatars, as the actual content of the notification.</p>
2235. <figure class="wp-caption alignnone" id="attachment_3100" style="width: 550px;"><img alt="" class="wp-image-3100 size-full" height="152" src="https://blogs.gnome.org/shell-dev/files/2024/04/rich-45.png" width="550"/><figcaption class="wp-caption-text" id="caption-attachment-3100">As of GNOME 45 we only have a single slot for images on notifications, and it’s too small for actual content.</figcaption></figure>
2236. <figure class="wp-caption alignnone" id="attachment_3103" style="width: 360px;"><img alt="" class="wp-image-3103 size-full" height="415" src="https://blogs.gnome.org/shell-dev/files/2024/04/rich-android.png" width="360"/><figcaption class="wp-caption-text" id="caption-attachment-3103">Other platforms have multiple slots (app icon, user avatar, and content image), and media can be expanded to much larger sizes.</figcaption></figure>
2237. <p>There’s also currently no way to include descriptive text for images in notifications, so they are inaccessible to screen readers. This isn’t as big a deal with the current icons since they’re small and mostly used for ornamental purposes, but will be important when we add larger images in the body.</p>
2238. <h4 id="Updating-notification-content">Updating notification content</h4>
2239. <p>It’s not possible for apps to update the content inside notifications they sent earlier. This is needed to show progress bars in notifications, or updating the text if a chat message was modified.</p>
2240. <h2 id="How-do-we-get-there">How do we get there?</h2>
2241. <p>Unfortunately, it turns out that improving notifications is not just a matter of standardizing a few new features and implementing them in GNOME Shell. The way notifications work today has grown organically over the years and the status quo is messy. There are three different APIs used by apps today: <a href="https://https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html" rel="noopener" target="_blank">XDG Notification</a>, <a href="https://docs.gtk.org/gio/class.Notification.html" rel="noopener" target="_blank">Gio.Notification</a>, and <a href="https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Notification.html" rel="noopener" target="_blank">XDG Portal</a>.</p>
2242. <figure class="wp-caption alignnone" id="attachment_3265" style="width: 950px;"><img alt="" class="wp-image-3265 size-full" height="660" src="https://blogs.gnome.org/shell-dev/files/2024/04/apis-old.png" width="950"/><figcaption class="wp-caption-text" id="caption-attachment-3265">How different notification APIs are used today</figcaption></figure>
2243. <h4 id="XDG-Notification">XDG Notification</h4>
2244. <p>This is the Freedesktop specification for a DBus interface for apps to send notifications to the system. It’s the oldest notification API still in use. Other desktops mostly use this API, e.g. KDE’s KNotification implements this spec.</p>
2245. <p>Somewhat confusingly, this standard has never actually been finalized and is still marked as a draft today, despite not having seen significant changes in the past decade.</p>
2246. <h4 id="GioNotification">Gio.Notification</h4>
2247. <p>This is an API in GLib/Gio to send notifications, so it’s only used by GTK apps. It abstracts over different OS notification APIs, primarily the XDG one mentioned above, a <a href="https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI#org.gtk.Notification" rel="noopener" target="_blank">private GNOME Shell API</a>, the portal API, and Cocoa (macOS).</p>
2248. <p>The primary one being used is the private DBus interface with GNOME Shell. This API was introduced in the early GNOME 3 days because the XDG standard API was deemed too complicated and was missing some features (in particular notifications were not tied to a specific app).</p>
2249. <p>When using Gio.Notification apps can’t know which backend is used, and how a notification will be displayed or behave. For example, notifications can only persist after the app is closed if the private GNOME Shell API is used. These differences are specific to GNOME Shell, since the private API is only implemented there.</p>
2250. <h4 id="XDG-Portal">XDG Portal</h4>
2251. <p><a href="https://flatpak.github.io/xdg-desktop-portal" rel="noopener" target="_blank">XDG portals</a> are secure, standardized system APIs for the Linux desktop. They were introduced as part of the push for app sandboxing around Flatpak, but can (and should) be used by non-sandboxed apps as well.</p>
2252. <p>The XDG notification portal was inspired by the private GNOME Shell API, with some additional features from the XDG API mixed in.</p>
2253. <p>XDG portals consist of a frontend and a backend. In the case of the notification portal, apps talk to the frontend using the portal API, while the backend talks to the system notification API. Backends are specific to the desktop environment, e.g. GNOME or KDE. On GNOME, the backend uses the private GNOME Shell API when possible.</p>
2254. </div>
2255. <div class="markdown-body container-fluid" id="doc">
2256. <h2 id="The-plan">The plan</h2>
2257. <p>From the GNOME Shell side we have the XDG API (used by non-GNOME apps), and the private API (used via Gio.Notification by GNOME apps). From the app side we additionally have the XDG portal API. Neither of these can easily supersede the others, because they all have different feature sets and are widely used. This makes improving our notifications tricky, because it’s not obvious which of the APIs we should extend.</p>
2258. <p>After several discussions over the past few months we now have consensus that it makes the most sense to invest in the XDG portal API. Portals are the future of system APIs on the free desktop, and enable app sandboxing. Neither of the other APIs can fill this role.</p>
2259. <div class="markdown-body container-fluid" id="doc">
2260. <figure class="wp-caption alignnone" id="attachment_3262" style="width: 950px;"><img alt="" class="wp-image-3262 size-full" height="640" src="https://blogs.gnome.org/shell-dev/files/2024/04/apis-new.png" width="950"/><figcaption class="wp-caption-text" id="caption-attachment-3262">Our plan for notification APIs going forward: Focus on the portal API</figcaption></figure>
2261. <div class="mceTemp"/>
2262. </div>
2263. <p>This requires work in a number of different modules, including the XDG portal spec, the XDG portal backend for GNOME, GNOME Shell, and client libraries such as Gio.Notification (in GLib), <a href="https://github.com/flatpak/libportal" rel="noopener" target="_blank">libportal</a>, <a href="https://gitlab.gnome.org/GNOME/libnotify" rel="noopener" target="_blank">libnotify</a>, and <a href="https://github.com/bilelmoussaoui/ashpd" rel="noopener" target="_blank">ashpd</a>.</p>
2264. <p>In the XDG portal spec, we are adding support for a number of missing features:</p>
2265. <ul>
2266. <li>Tying notifications to apps</li>
2267. <li>Grouping by message thread</li>
2268. <li>Larger images in the notification body</li>
2269. <li>Special notifications for e.g. calls and alarms</li>
2270. <li>Clearing up some instances of undefined behavior (e.g. markup in the body, playing sounds, whether to show notifications on the lock screen, etc.)</li>
2271. </ul>
2272. <p>This is the <a href="https://github.com/flatpak/xdg-desktop-portal/pull/1304" rel="noopener" target="_blank">draft XDG desktop portal proposal</a> for the spec changes.</p>
2273. <p>On the GNOME Shell side, these are the primary things we’re doing (some already done in 46):</p>
2274. <ul>
2275. <li>Cleanups and refactoring to make the code easier to work on</li>
2276. <li>Improve keyboard navigation and screen reader accessibility</li>
2277. <li>Header with app name and icon</li>
2278. <li>Show full notification body and buttons in the drawer</li>
2279. <li>Larger notification icons (e.g. user avatars on chat notifications)</li>
2280. <li>Group notifications from the same app as a stack</li>
2281. <li>Allow message threads to be grouped in a single notification bubbles</li>
2282. <li>Larger images in the notification body</li>
2283. </ul>
2284. <figure class="wp-caption alignnone" id="attachment_3109" style="width: 900px;"><a href="https://blogs.gnome.org/shell-dev/files/2024/04/grouping-mockups.png"><img alt="" class="wp-image-3109" height="504" src="https://blogs.gnome.org/shell-dev/files/2024/04/grouping-mockups-1024x574.png" width="900"/></a><figcaption class="wp-caption-text" id="caption-attachment-3109"><a href="https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/notifications-calendar/notifications-grouping.png">Mockups</a> of what we’d ideally want, including grouping by app, threading, etc.</figcaption></figure>
2285. </div>
2286. <p>There are also <a href="https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/notifications-grouping">animated mockups</a> for some of this, courtesy of <a href="https://jimmac.eu">Jakub Steiner</a>.</p>
2287. <div class="wp-video" style="width: 525px;"><!--[if lt IE 9]><script>document.createElement('video');</script><![endif]-->
2288. <video class="wp-video-shortcode" controls="" height="394" id="video-3094-1" preload="metadata" width="525"><source src="https://blogs.gnome.org/shell-dev/files/2024/04/threads-white.webm?_=1" type="video/webm"/><a href="https://blogs.gnome.org/shell-dev/files/2024/04/threads-white.webm">https://blogs.gnome.org/shell-dev/files/2024/04/threads-white.webm</a></video></div>
2289. <div class="markdown-body container-fluid" id="doc">
2290. <p>The long-term goal is for apps to switch to the portal API and deprecate both of the others as application-facing APIs. Internally we will still need something to communicate between the portal backend and GNOME Shell, but this isn’t public API so we’re much more flexible here. We might expand either the XDG API or the private GNOME Shell protocol for this purpose, but it has not been decided yet how we’ll do this.</p>
2291. <h2 id="What-we-did-in-GNOME-46">What we did in GNOME 46</h2>
2292. <p>When we started the STF project late last year we thought we could just pull the trigger on a draft proposal Jonas for an API with the new capabilities needed for mobile. However, as we started discussing things in more detail we realized that this was the the wrong place to start. GNOME Shell already didn’t implement a number of features that are in the XDG notification spec, so standardizing new features was not the main blocker.</p>
2293. <p>The code around notifications in GNOME Shell has grown historically and has seen multiple major UI redesigns since GNOME 3.0. Additional complexity comes from the fact that we try to avoid breaking extensions, which means it’s difficult to e.g. change function names or signatures. Over time this has resulted in technical debt, such as weird anachronistic structures and names. It was also not using many of the more recent GJS features which didn’t exist yet when this code was written originally.</p>
2294. <figure class="wp-caption alignnone" id="attachment_3172" style="width: 800px;"><img alt="" class="wp-image-3172 size-full" height="500" src="https://blogs.gnome.org/shell-dev/files/2024/04/activities-3-6.png" width="800"/><figcaption class="wp-caption-text" id="caption-attachment-3172">Anyone remember that notifications used to be on the bottom? This is what they looked like in GNOME 3.6 (2012).</figcaption></figure>
2295. <p>As a first step we restructured and cleaned up legacy code, ported it to the most recent GJS features, updated the coding style, and so on. This unfortunately means extensions need to be updated, but it puts us on much firmer ground for the future.</p>
2296. <p>With this out of the way we added the first batch of features from our list above, namely adding <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103" rel="noopener" target="_blank">notification headers</a>, <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173" rel="noopener" target="_blank">expanding notifications</a> in the drawer, <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103/diffs?commit_id=8fdea10e3327d85ddf637adddd6855c36f3e19fb" rel="noopener" target="_blank">larger icons</a>, and some <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3066" rel="noopener" target="_blank">style fixes to icons</a>. We also fixed a very annoying issue with “App is ready” notifications not working as expected when clicking a notification (<a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198" rel="noopener" target="_blank">!3198</a> and <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3199" rel="noopener" target="_blank">!3199</a>).</p>
2297. <p>We also worked on a few other things that didn’t make it in time for 46, most notably grouping notifications by app (which there’s a <a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012" rel="noopener" target="_blank">draft MR</a> for), and additionally grouping them by thread (prototype only).</p>
2298. <p>Throughout the cycle we also continued to <a href="https://github.com/flatpak/xdg-desktop-portal/pull/1304" rel="noopener" target="_blank">discuss the portal spec</a>, as mentioned above. There are MRs against against <a href="https://github.com/flatpak/xdg-desktop-portal/pull/1298" rel="noopener" target="_blank">XDG desktop portal</a> and the <a href="https://github.com/flatpak/libportal/pull/147" rel="noopener" target="_blank">libportal</a> client library implementing the spec changes. There’s also a draft implementation for the <a href="https://github.com/jsparber/xdg-desktop-portal-gtk/tree/implement_notification_v2" rel="noopener" target="_blank">GTK portal backend</a>.</p>
2299. <h2 id="Future-work">Future work</h2>
2300. <p>With all the groundwork laid in GNOME 46 and the spec draft mostly ready we’re in a good position to continue iterating on notifications in 47 and beyond. In GNOME 47 we want to add some of the first newly spec’d features, in particular notification sounds, markup support in the body, and display hints (e.g. showing on the lock screen or not).</p>
2301. <p>We also want to continue work on the UI to unlock even more improvements in the future. In particular, grouping by app will allow us to drop the “only keep 3 notifications per app” behavior and will generally make notifications easier to manage, e.g. allowing to dismiss all notifications from a given app. We’re also planning to work on improving keyboard navigation and ensuring all content is accessible to screen readers.</p>
2302. <p>Due to the complex nature of the UI for grouping by app and the many moving parts with moving forward on the spec it’s unclear if we’ll be able to do more than this in the scope of STF and within the 47 cycle. This means that additional features that require the new spec and/or lots of UI work, such as grouping by thread and custom UI for call or alarm notifications will probably be 48+ material.</p>
2303. <h2 id="Conclusion">Conclusion</h2>
2304. <p>As we hope this post has illustrated, notifications are way more complex than they might appear. Improving them requires untangling decades of legacy stuff across many different components, coordinating with other projects, and engaging with standards bodies. That complexity has made this hard to work on for volunteers, and there has not been any recent corporate interest in the area, which is why it has been stagnant for some time.</p>
2305. <p>The <a href="https://www.sovereigntechfund.de" rel="noopener" target="_blank">Sovereign Tech Fund</a> investment has allowed us to take the time to properly work through the problem, clean up technical debt, and make a plan for the future. We hope to leverage this momentum over the coming releases, for a best-in-class notification experience on the free desktop. Stay tuned <img alt="&#x1F642;" class="wp-smiley" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f642.png" style="height: 1em;"/></p>
2306. </div></div>
2307.    </content>
2308.    <updated>2024-04-23T13:01:29Z</updated>
2309.    <published>2024-04-23T13:01:29Z</published>
2310.    <category term="Uncategorized"/>
2311.    <category term="Notifications"/>
2312.    <author>
2313.      <name>jsparber</name>
2314.    </author>
2315.    <source>
2316.      <id>https://blogs.gnome.org/shell-dev</id>
2317.      <link href="https://blogs.gnome.org/shell-dev/feed/" rel="self" type="application/rss+xml"/>
2318.      <link href="https://blogs.gnome.org/shell-dev" rel="alternate" type="text/html"/>
2319.      <subtitle>Development blog for GNOME Shell and Mutter</subtitle>
2320.      <title>GNOME Shell &amp; Mutter</title>
2321.      <updated>2024-04-24T16:17:56Z</updated>
2322.    </source>
2323.  </entry>
2324.  
2325.  <entry>
2326.    <id>tag:blogger.com,1999:blog-5968355124473522212.post-4205566450549309916</id>
2327.    <link href="https://nibblestew.blogspot.com/feeds/4205566450549309916/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
2328.    <link href="https://nibblestew.blogspot.com/2024/04/c-is-dead-long-live-c-apis.html#comment-form" rel="replies" title="0 Comments" type="text/html"/>
2329.    <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/4205566450549309916" rel="edit" type="application/atom+xml"/>
2330.    <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/4205566450549309916" rel="self" type="application/atom+xml"/>
2331.    <link href="https://nibblestew.blogspot.com/2024/04/c-is-dead-long-live-c-apis.html" rel="alternate" title="C is dead, long live C (APIs)" type="text/html"/>
2332.    <title>C is dead, long live C (APIs)</title>
2333.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>In the 80s and 90s software development landscape was quite different from today (or so I have been told). Everything that needed performance was written in C and things that did not were written in Perl. Because computers of the time were really slow, almost everything was in C. If you needed performance and fast development, you could write a C extension to Perl.</p><p>As C was the only game in town, anyone could use pretty much any other library directly. The number of dependencies available was minuscule compared to today, but you could use all of them fairly easily. Then things changed, as they have a tendency to do. First Python took over Perl. Then more and more languages started eroding C's dominant position. This lead to a duplication of effort. For example if you were using Java and wanted to parse XML (which was the coolness of its day), you'd need an XML parser written in Java. Just dropping libxml in your Java source tree would not cut it (you could still use native code libs but most people chose not to).</p><p>The number of languages and ecosystems kept growing and nowadays we have dozens of them. But suppose you want to provide a library that does something useful and you'd like it to be usable by as many people as possible. This is especially relevant for providing closed source libraries but the same applies to open source libs as well. You especially do not want to rewrite and maintain multiple implementations of the code in different languages. So what do you do?</p><p>Let's start by going through a list of programming languages and seeing what sort of dependencies they can use natively (i.e. the toolchain or stdlib provides this support out of the box rather than requiring an addon, code generator, IDL tool or the like)</p><p/><ul style="text-align: left;"><li><b>C</b>: C</li><li><b>Perl</b>: Perl and C</li><li><b>Python</b>: Python and C</li><li><b>C++</b>: C++ and C</li><li><b>Rust</b>: Rust and C</li><li><b>Java</b>: Java and C</li><li><b>Lua</b>: Lua and C</li><li><b>D</b>: D, subset of C++ and C</li><li><b>Swift</b>: Swift, Objective C, C++ (eventually?) and C</li><li><b>PrettyMuchAnyNewLanguage</b>: itself and C</li></ul>The message is quite clear. The only thing in common is C, so that is what you have to use. The alternative is maintaining an implementation per language leaving languages you explicitly do not support out in the cold.<p/><p>So even though C as a language is (most likely) going away, C APIs are not. In fact, designing C APIs is a skill that might even see a resurgence as the language ecosystem fractures even further. Note that providing a library with a C API does not mean having to implement it in C. All languages have ways of providing libraries whose external API is compatible with C. As an extreme example, Visual Studio's C runtime libraries are nowadays written in C++.</p><h1 style="text-align: left;">CapyPDF's design and things picked up along the way</h1><p style="text-align: left;">One of the main design goals of <a href="https://github.com/jpakkane/capypdf">CapyPDF</a> was that it should provide a C API and be usable from any language. It should also (eventually) provide a stable API <i>and</i> ABI. This means that the ground truth of the library's functionality is the C header. This turns out to have design implications to the library's internals that might be difficult to add in after the fact.</p><h2 style="text-align: left;">Hide everything</h2><p style="text-align: left;">Perhaps the most important declaration in widely usable C headers is this.</p><div><span style="font-family: courier;">typedef struct _someObject SomeObject;</span></div><p style="text-align: left;">In C parlance this means "there is a struct type <span style="font-family: courier;">_someObject</span> somewhere, create an alias to it called <span style="font-family: courier;">SomeObjectType</span>". This means that the caller can create pointers to structs of type <span style="font-family: courier;">SomeObject</span> but do nothing else with them. This leads to the common "opaque structs" C API way of doing things:</p><div style="text-align: left;"><span style="font-family: courier;">SomeObject *o = some_object_new();</span></div><div style="text-align: left;"><span style="font-family: courier;">some_object_do_something(o, "hello");<br/>some_object_destroy(o);</span></div><p style="text-align: left;">This permits you to change the internal representation of the object while still maintaining stable public API and ABI. Avoid exposing the internals of structs whenever possible, because once made public they can never be changed.</p><h2 style="text-align: left;">Objects exposed via pointers must never move in memory</h2><p style="text-align: left;">This one is fairly obvious when you think about it. Unfortunately it means that if you want to give users access to objects that are stored in an <span style="font-family: courier;">std::vector</span>, you can't do it with pointers, which is the natural way of doing things in C. Pushing more entries in the vector will eventually cause the capacity to be exceeded so the storage will be reallocated and entries moved to the new backing store. This invalidates all pointers.</p><p style="text-align: left;">There are several solutions to this, but the simplest one is to access those objects via type safe indices instead. They are defined like this:</p><div style="text-align: left;"><span style="font-family: courier;">typedef struct { int32_t id; } SomeObjectId;</span></div><p style="text-align: left;">This struct behaves "like an integer" in that you can pass it around as an int but it does not implicitly convert to any other "integer" type.</p><h2 style="text-align: left;">Objects must be destructable in any order</h2><p style="text-align: left;">It is easy to write into documentation that "objects of type X must be destroyed before any object Y that they use". Unfortunately garbage collected languages do not read your docs and thus provide no guarantee whatsoever on object destruction order. When used in this way any object must be destructable at any time regardless of the state of any other object.</p><p style="text-align: left;">This is the opposite of how modern languages want to work. For the case of CapyPDF especially page draw contexts were done in an RAII style where they would submit their changes upon destruction. For an internal API this is nice and usable but for a public C API it is not. The implicit action had to be replaced with an explicit function to add the page that takes both object pointers (the draw context and document) as arguments. This ensures that they both must exist and be valid at the point of call.</p><h2 style="text-align: left;">Use transactionality whenever possible</h2><p style="text-align: left;">It would be nice if all objects were immutable but sadly that would mean that you can't actually do anything. A library must provide ways for end users to create, mutate and destroy objects. When possible try to do this with a builder object. That is, the user creates a "transactional change" that they want to do. They can call setters and such as much as they want, but they don't affect the "actual document". All of this new state is isolated in the builder object. Once the user is finished they submit the change to the main object which is then validated and either rejected or accepted as a whole. The builder object then becomes an empty shell that can be either reused or discarded.</p><p style="text-align: left;">CapyPDF is an append only library. Once something has been "committed" it can never be taken out again. This is also something to strive towards, because removing things is a lot harder than adding them.</p><h2 style="text-align: left;">Prefer copying to sharing</h2><p style="text-align: left;">When the library is given some piece of data, it makes a private copy of it. Otherwise it would need to coordinate the life cycle of the shared piece of data with the caller. This is where bugs lie. Copying does cost some performance but makes a whole class of difficult bugs just go away. In the case of CapyPDF the performance hit turned out not to be an issue since most of the runtime is spent compressing the output with zlib.</p><h2 style="text-align: left;">Every function call can fail, even those that can't</h2><p style="text-align: left;">Every function in the library returns an error code. Even those that have no way of failing, because circumstances can change in the future. Maybe some input that could be anything somehow needs to be validated now and you can't change the function definition as it would break API. Thus every function returns an error code (except the function that converts an error code into an error string). Sadly this means that all "return values" must be handled via out parameters.</p><div style="text-align: left;"><span style="font-family: courier;">ErrorCode some_object_new(SomeObject **out_ptr);</span></div><p style="text-align: left;">This is not great, but such is life. </p><h1 style="text-align: left;">Think of C APIs as "in-process RPC"</h1><div>When designing the API of CapyPDF it was helpful to think of it like a call to a remote endpoint somewhere out there on the Internet. This makes you want to design functions that are as high level as possible and try to ignore all implementation details you can, almost as if the C API was a slightly cumbersome DSL. </div></div>
2334.    </content>
2335.    <updated>2024-04-21T13:39:00Z</updated>
2336.    <published>2024-04-21T13:39:00Z</published>
2337.    <author>
2338.      <name>Jussi</name>
2339.      <email>noreply@blogger.com</email>
2340.      <uri>http://www.blogger.com/profile/03370287682352908292</uri>
2341.    </author>
2342.    <source>
2343.      <id>tag:blogger.com,1999:blog-5968355124473522212</id>
2344.      <author>
2345.        <name>Jussi</name>
2346.        <email>noreply@blogger.com</email>
2347.        <uri>http://www.blogger.com/profile/03370287682352908292</uri>
2348.      </author>
2349.      <link href="https://nibblestew.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
2350.      <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default" rel="self" type="application/atom+xml"/>
2351.      <link href="https://nibblestew.blogspot.com/" rel="alternate" type="text/html"/>
2352.      <link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
2353.      <link href="https://www.blogger.com/feeds/5968355124473522212/posts/default?start-index=26&amp;max-results=25" rel="next" type="application/atom+xml"/>
2354.      <subtitle>A gathering of development thoughts of Jussi Pakkanen. Some of you may know him as the creator of the Meson build system. jpakkane at gmail dot com</subtitle>
2355.      <title>Nibble Stew</title>
2356.      <updated>2024-05-17T14:06:49Z</updated>
2357.    </source>
2358.  </entry>
2359.  
2360.  <entry>
2361.    <id>tag:blogger.com,1999:blog-6112936277054198647.post-6156149132305853287</id>
2362.    <link href="https://who-t.blogspot.com/feeds/6156149132305853287/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
2363.    <link href="https://www.blogger.com/comment.g?blogID=6112936277054198647&amp;postID=6156149132305853287" rel="replies" title="0 Comments" type="text/html"/>
2364.    <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default/6156149132305853287" rel="edit" type="application/atom+xml"/>
2365.    <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default/6156149132305853287" rel="self" type="application/atom+xml"/>
2366.    <link href="https://who-t.blogspot.com/2024/04/udev-hid-bpf-quickstart-tooling-to-fix.html" rel="alternate" title="udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF" type="text/html"/>
2367.    <title>udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF</title>
2368.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>
2369.  For the last few months, Benjamin Tissoires and I have been working on and polishing a little tool called <a href="https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html">udev-hid-bpf</a> [1]. This is the scaffolding required quickly and easily write, test and eventually fix your HID input devices (mouse, keyboard, etc.) via a BPF program instead of a full-blown custom kernel driver or a semi-full-blown kernel patch. To understand how it works, you need to know two things: HID and BPF [2].
2370. </p>
2371. <h2>Why BPF for HID?</h2>
2372. <p>
2373.  HID is the Human Interface Device standard and the most common way input devices communicate with the host (HID over USB, HID over Bluetooth, etc.). It has two core components: the "report descriptor" and "reports", both of which are byte arrays. The report descriptor is a fixed burnt-in-ROM byte array that (in rather convoluted terms) tells us what we'll find in the reports. Things like "bits 16 through to 24 is the delta x coordinate" or "bit 5 is the binary button state for button 3 in degrees celcius". The reports themselves are sent at (usually) regular intervals and contain the data in the described format, as the devices perceives reality. If you're interested in more details, see <a href="https://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html" target="_blank">Understanding HID report descriptors</a>.
2374. </p>
2375. <p>
2376.  BPF or more correctly eBPF is a Linux kernel technology to write programs in a subset of C, compile it and load it into the kernel. The magic thing here is that the kernel will <a href="https://docs.kernel.org/bpf/verifier.html">verify it</a>, so once loaded, the program is "safe". And because it's safe it can be run in kernel space which means it's fast. eBPF was originally written for network packet filters but as of kernel v6.3 and thanks to Benjamin, we have BPF in the HID subsystem. HID actually lends itself really well to BPF because, well, we have a byte array and to fix our devices we need to do complicated things like "toggle that bit to zero" or "swap those two values".
2377. </p>
2378. <p>
2379.  If we want to fix our devices we usually need to do one of two things: fix the report descriptor to enable/disable/change some of the values the device pretends to support. For example, we can say we support 5 buttons instead of the supposed 8. Or we need to fix the report by e.g. inverting the y value for the device. This can be done in a custom kernel driver but a HID BPF program is quite a lot more convenient.
2380. </p>
2381.  
2382. <h2>HID-BPF programs</h2>
2383. <p>
2384.  For illustration purposes, here's the example program to flip the y coordinate. HID BPF programs are usually device specific, we need to know that the e.g. the y coordinate is 16 bits and sits in bytes 3 and 4 (little endian):
2385.  </p><pre>SEC("fmod_ret/hid_bpf_device_event")
2386. int BPF_PROG(hid_y_event, struct hid_bpf_ctx *hctx)
2387. {
2388. s16 y;
2389. __u8 *data = hid_bpf_get_data(hctx, 0 /* offset */, 9 /* size */);
2390.  
2391. if (!data)
2392. return 0; /* EPERM check */
2393.  
2394. y = data[3] | (data[4] << 8);
2395. y = -y;
2396.  
2397. data[3] = y & 0xFF;
2398. data[4] = (y >> 8) & 0xFF;
2399.  
2400. return 0;
2401. }
2402.  </pre>
2403. That's it. HID-BPF is invoked before the kernel handles the HID report/report descriptor so to the kernel the modified report looks as if it came from the device.
2404. <p/>
2405. <p>
2406.  As said above, this is device specific because where the coordinates is in the report depends on the device (the report descriptor will tell us). In this example we want to ensure the BPF program is only loaded for our device (vid/pid of 04d9/a09f), and for extra safety we also double-check that the report descriptor matches.
2407. </p><pre>// The bpf.o will only be loaded for devices in this list
2408. HID_BPF_CONFIG(
2409. HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, 0x04D9, 0xA09F)
2410. );
2411.  
2412. SEC("syscall")
2413. int probe(struct hid_bpf_probe_args *ctx)
2414. {
2415. /*
2416. * The device exports 3 interfaces.
2417. * The mouse interface has a report descriptor of length 71.
2418. * So if report descriptor size is not 71, mark as -EINVAL
2419. */
2420. ctx->retval = ctx->rdesc_size != 71;
2421. if (ctx->retval)
2422. ctx->retval = -EINVAL;
2423.  
2424. return 0;
2425. }
2426. </pre>
2427. Obviously the check in probe() can be as complicated as you want.
2428. <p/>
2429. <p>
2430.  This is pretty much it, the <a href="https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/blob/main/src/bpf/userhacks/10-mouse_invert_y.bpf.c?ref_type=heads">full working program</a> only has a few extra includes and boilerplate. So it mostly comes down to compiling and running it, and this is where udev-hid-bpf comes in.
2431. </p>
2432.  
2433. <h2>udev-hid-bpf as loader</h2>
2434. <p>
2435.   udev-hid-bpf is a tool to make the <i>development and testing</i> of HID BPF programs simple, and collect HID BPF programs. You basically run <i>meson compile</i> and <i>meson install</i> and voila, whatever BPF program applies to your devices will be auto-loaded next time you plug those in. If you just want to test a single bpf.o file you can <i>udev-hid-bpf install /path/to/foo.bpf.o</i> and it will install the required udev rule for it to get loaded whenever the device is plugged in. If you don't know how to compile, you can grab a tarball from our CI and test the pre-compiled bpf.o. Hooray, even simpler.
2436. </p>
2437. <p>
2438.  udev-hid-bpf is written in Rust but you don't need to know Rust, it's just the scaffolding. The BPF programs are all in C. Rust just gives us a relatively easy way to provide a static binary that will work on most tester's machines.
2439. </p>
2440. <p>
2441.  The documentation for udev-hid-bpf is <a href="https://libevdev.pages.freedesktop.org/udev-hid-bpf/">here</a>. So if you have a device that needs a hardware quirk or just has an annoying behaviour that you always wanted to fix, well, now's the time. Fixing your device has never been easier! [3].
2442. </p>
2443. <p>
2444.  <small>
2445.  [1] Yes, the name is meh but you're welcome to come up with a better one and go back in time to suggest it a few months ago. <br/>
2446.  [2] Because I'm lazy the terms eBPF and BPF will be used interchangeably in this article. Because the difference doesn't really matter in this context, it's all eBPF anyway but nobody has the time to type that extra "e".<br/>
2447.  [3] Citation needed
2448.  </small>
2449. </p></div>
2450.    </content>
2451.    <updated>2024-04-18T04:17:00Z</updated>
2452.    <published>2024-04-18T04:17:00Z</published>
2453.    <author>
2454.      <name>Peter Hutterer</name>
2455.      <email>noreply@blogger.com</email>
2456.      <uri>https://www.blogger.com/profile/17204066043271384535</uri>
2457.    </author>
2458.    <source>
2459.      <id>tag:blogger.com,1999:blog-6112936277054198647</id>
2460.      <category term="git"/>
2461.      <category term="kernel"/>
2462.      <category term="compiz"/>
2463.      <category term="gitlab"/>
2464.      <category term="configuration"/>
2465.      <category term="xkb"/>
2466.      <category term="x"/>
2467.      <category term="fedora"/>
2468.      <category term="tig"/>
2469.      <category term="multitouch"/>
2470.      <category term="libratbag"/>
2471.      <category term="tutorial"/>
2472.      <category term="wayland"/>
2473.      <category term="xorg.conf"/>
2474.      <category term="input device properties"/>
2475.      <category term="tuhi"/>
2476.      <category term="workflow"/>
2477.      <category term="hid"/>
2478.      <category term="gnome-device-setup"/>
2479.      <category term="mpx"/>
2480.      <category term="outdoors"/>
2481.      <category term="gnome"/>
2482.      <category term="libevdev"/>
2483.      <category term="xds"/>
2484.      <category term="xi2"/>
2485.      <category term="wacom"/>
2486.      <category term="evemu"/>
2487.      <category term="xorg"/>
2488.      <category term="xlib"/>
2489.      <category term="libinput"/>
2490.      <category term="hal"/>
2491.      <category term="synaptics"/>
2492.      <category term="freedesktop.org"/>
2493.      <category term="xts"/>
2494.      <category term="evtest"/>
2495.      <category term="evdev"/>
2496.      <category term="libei"/>
2497.      <category term="libinput. wayland"/>
2498.      <author>
2499.        <name>Peter Hutterer</name>
2500.        <email>noreply@blogger.com</email>
2501.        <uri>https://www.blogger.com/profile/17204066043271384535</uri>
2502.      </author>
2503.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
2504.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default" rel="self" type="application/atom+xml"/>
2505.      <link href="http://who-t.blogspot.com/" rel="alternate" type="text/html"/>
2506.      <link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
2507.      <link href="https://www.blogger.com/feeds/6112936277054198647/posts/default?start-index=26&amp;max-results=25" rel="next" type="application/atom+xml"/>
2508.      <title>Who-T</title>
2509.      <updated>2024-05-09T00:02:05Z</updated>
2510.    </source>
2511.  </entry>
2512.  
2513.  <entry xml:lang="en-US">
2514.    <id>https://blog.gtk.org/?p=10129</id>
2515.    <link href="https://blog.gtk.org/2024/04/17/graphics-offload-revisited/" rel="alternate" type="text/html"/>
2516.    <title>Graphics offload revisited</title>
2517.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">We first introduced support for dmabufs and graphics offload last fall, and it is included in GTK 4.14. Since then, some improvements have happened, so it is time for an update. Improvements down the stack The GStreamer 1.24 release has improved support for explicit modifiers, and the GStreamer media backend in GTK has been updated … <a class="more-link" href="https://blog.gtk.org/2024/04/17/graphics-offload-revisited/">Continue reading<span class="screen-reader-text"> "Graphics offload revisited"</span></a></div>
2518.    </summary>
2519.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>We first introduced support for dmabufs and <a href="https://blog.gtk.org/2023/11/15/introducing-graphics-offload/">graphics offload</a> last fall, and it is included in GTK 4.14. Since then, some improvements have happened, so it is time for an update.</p>
2520. <h3>Improvements down the stack</h3>
2521. <p>The GStreamer 1.24 <a href="https://gstreamer.freedesktop.org/releases/1.24/">release</a> has improved support for explicit modifiers, and the GStreamer media backend in GTK has been updated to request dmabufs from GStreamer.</p>
2522. <p>Another thing that happens on the GStreamer side is that dmabufs sometimes come with padding: in that case GStreamer will give us a buffer with a <em>viewport</em> and expect us to only show that part of the buffer. This is sometimes necessary to accommodate stride and size requirements of hardware decoders.</p>
2523. <p>GTK 4.14 supports this when offloading, and only shows the part of the dmabuf indicated by the viewport.</p>
2524. <h3>Improvements inside GTK</h3>
2525. <p>We’ve merged new <a href="https://blog.gtk.org/2024/01/28/new-renderers-for-gtk/">GSK renderers</a> for GTK 4.14. The new renderers support dmabufs in the same way as the old gl renderer. In addition, the new Vulkan renderer produces dmabufs when rendering to a texture.</p>
2526. <p>In GTK 4.16, the GtkGLArea widget will also provide dmabuf textures if it can, so you can put it in a GtkGraphicsOffload widget to send its output directly to the compositor.</p>
2527. <p>You can see this in action in the shadertoy demo in gtk4-demo in git main.</p>
2528. <figure class="wp-caption aligncenter" id="attachment_10171" style="width: 718px;"><a href="https://blog.gtk.org/files/2024/04/Screenshot-from-2024-04-16-21-46-33.png"><img alt="" class="wp-image-10171 size-full" height="769" src="https://blog.gtk.org/files/2024/04/Screenshot-from-2024-04-16-21-46-33.png" width="718"/></a><figcaption class="wp-caption-text" id="caption-attachment-10171">Shadertoy demo with golden outline around offloaded graphics</figcaption></figure>
2529. <h3>Improved compositor interaction</h3>
2530. <p>One nice thing about graphics offload is that the compositor may be able to pass the dmabuf to the KMS apis of the kernel without any extra copies or compositing. This is known as <em>direct scanout</em> and it helps reduce power consumption since large parts of the GPU aren’t used.</p>
2531. <p>The compositor can only do this if the dmabuf is attached to a fullscreen surface and has the right dimensions to cover it fully. If it does not cover it fully, the compositor needs some assurance that it is ok to leave the outside parts black.</p>
2532. <p>One way for clients to provide that assurance is to attach a <a href="https://wayland.app/protocols/single-pixel-buffer-v1">specially constructed</a> black buffer to a surface below the one that has the dmabuf attached. GSK will do this now if it finds black color node in the rendernode tree, and the GtkGraphicsOffload widget will put that color there if you set the “black-background” property. This should greatly increase the chances that you can enjoy the benefits of direct scanout when playing fullscreen video.</p>
2533. <figure class="wp-caption aligncenter" id="attachment_10219" style="width: 600px;"><a href="https://blog.gtk.org/files/2024/04/bbb-bb.png"><img alt="Developer trying to make sense of graphics offload" class="wp-image-10219" height="540" src="https://blog.gtk.org/files/2024/04/bbb-bb-300x270.png" width="600"/></a><figcaption class="wp-caption-text" id="caption-attachment-10219">Offloaded content with fullscreen black background</figcaption></figure>
2534. <p>In implementing this for GTK 4.16, we found some issues with mutter’s support for single-pixel buffers, but these have been fixed quickly.</p>
2535. <p>To see graphics offload and direct scanout in action in a GTK4 video player, you can try the <a href="https://flathub.org/apps/org.sigxcpu.Livi">Light Video Player</a>.</p>
2536. <p>If you want to find out if graphics offload works on your system or debug why it doesn’t, this recent <a href="https://blogs.gnome.org/otte/2024/04/14/making-gtk-graphics-offloading-work/">post</a> by Benjamin is very helpful.</p>
2537. <h3>Summary</h3>
2538. <p>GTK 4 continues to improve for efficient video playback and drives improvements in this area up and down the stack.</p>
2539. <p>A big thank you for pushing all of this forward goes to Robert Mader. <img alt="&#x2764;" class="wp-smiley" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2764.png" style="height: 1em;"/></p></div>
2540.    </content>
2541.    <updated>2024-04-17T17:39:31Z</updated>
2542.    <published>2024-04-17T17:39:31Z</published>
2543.    <author>
2544.      <name>mclasen</name>
2545.    </author>
2546.    <source>
2547.      <id>https://blog.gtk.org</id>
2548.      <link href="https://blog.gtk.org/author/mclasen/feed/" rel="self" type="application/rss+xml"/>
2549.      <link href="https://blog.gtk.org" rel="alternate" type="text/html"/>
2550.      <subtitle>All things GTK</subtitle>
2551.      <title>mclasen – GTK Development Blog</title>
2552.      <updated>2024-04-17T17:43:54Z</updated>
2553.    </source>
2554.  </entry>
2555.  
2556.  <entry xml:lang="en">
2557.    <id>http://samthursfield.wordpress.com/?p=2408</id>
2558.    <link href="https://samthursfield.wordpress.com/2024/04/17/status-update-17-04-2024/" rel="alternate" type="text/html"/>
2559.    <title>Status update, 17/04/2024</title>
2560.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">In which I meet QA testers, bang my head against the GNOME OS initial setup process, and travel overland from Scotland to Spain in 48 hours. Linux QA meetup Several companies and communities work on QA testing for Linux distros, and we mostly don’t talk to each other. GUADEC 2023 was a rare occasion where … <a class="more-link" href="https://samthursfield.wordpress.com/2024/04/17/status-update-17-04-2024/">Continue reading <span class="screen-reader-text">Status update, 17/04/2024</span></a></div>
2561.    </summary>
2562.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>In which I meet QA testers, bang my head against the GNOME OS initial setup process, and travel overland from Scotland to Spain in 48 hours.</p>
2563.  
2564.  
2565.  
2566. <h2 class="wp-block-heading">Linux QA meetup</h2>
2567.  
2568.  
2569.  
2570. <p>Several companies and communities work on QA testing for Linux distros, and we mostly don’t talk to each other. GUADEC 2023 was a rare occasion where several of us were physically collocated for a short time, and a few folk proposed a “GNOME + openQA hackfest” to try and consolidate what we’re all working on.</p>
2571.  
2572.  
2573.  
2574. <p>Over time, we realized ongoing lines of communication are more useful than an expensive one-off meetup, and the idea turned into a recurring monthly call. This month we finally held the first call. In terms of connecting different teams it was a success – we had folk from Canonical/Ubuntu, Codethink, Debian, GNOME, Red Hat/Fedora and SUSE, and there are some additional people already interested in the next one. Everyone who attended this round is using openQA and we will to use the <a href="https://matrix.to/#/#openqa:opensuse.org">openqa:opensuse.org chat</a> to organise future events – but the call is not specific to openQA, nor to GNOME: anything Linux-related and QA-related is in scope.</p>
2575.  
2576.  
2577.  
2578. <p>If you want to be involved in the next one, make sure you’re in the openQA chat room, or follow this <a href="https://discourse.gnome.org/t/monthly-qa-testing-call/20382/2">thread on GNOME Discourse</a>. The schedule is documented <a href="https://gitlab.gnome.org/GNOME/openqa-tests/-/wikis/QA-testing-monthly-call">here</a> and the next call should be 08:00UTC on Thursday 2nd May.</p>
2579.  
2580.  
2581.  
2582. <h2 class="wp-block-heading">GNOME OS tests</h2>
2583.  
2584.  
2585.  
2586. <p>On the topic of QA, the testsuite for GNOME OS is feeling pretty unloved at the moment. Tests still don’t pass reliably and haven’t done for months. Besides the existing issue with initial setup where <a href="https://gitlab.gnome.org/GNOME/openqa-tests/-/issues/62">GNOME Shell doesn’t start</a>, there is a new regression that breaks the systemd user session and causes <a href="https://gitlab.gnome.org/GNOME/openqa-tests/-/issues/114">missing sound devices</a>. Investigating these issues is a slow and boring process which you can read about in great detail on the linked issues.</p>
2587.  
2588.  
2589.  
2590. <p><em>Fun fact: most of GNOME OS works fine without a systemd user session – there is still a D-Bus session bus after all; systemd user sessions are quite new and we still (mostly) support non-systemd setups.</em></p>
2591.  
2592.  
2593.  
2594. <p>One thing is clear, we still need a lot of work on tooling and docs around GNOME OS and the tests, if we hope to get more people involved. I’m trying my best in the odd hours I have available, greatly helped by Valentin David and other folk in the <a href="https://matrix.to/#/#gnome-os:gnome.org">#GNOME OS</a> channel, but it still feels like wading through treacle.</p>
2595.  
2596.  
2597.  
2598. <p>We particularly could do with documentation on how the early boot and <a href="https://github.com/GNOME/gnome-initial-setup/">initial setup</a> process is intended to work – its very hard to visualize just from looking at systemd unit files. Or maybe systemd itself can generate a graph of what should be happening.</p>
2599.  
2600.  
2601.  
2602. <h2 class="wp-block-heading">Magic in the <code>ssam_openqa</code> tool</h2>
2603.  
2604.  
2605.  
2606. <p>Debugging OS boot failures isn’t my favourite thing. I just want reliable tests. Writing support tooling in Rust is fun though, and it feels like magic to be able to control and debug VMs from a simple CLI tool, and play with them over VNC while the test suite runs.</p>
2607.  
2608.  
2609.  
2610. <p>Using a VNC connection to run shell commands is annoying at times: it’s a terminal in a desktop in a VNC viewer, with plenty of rendering glitches, and no copy/paste integration with the host. I recently noticed that while openQA tests are running, a virtio terminal is exposed on the host as a pair of in/out FIFOs, and you can control this terminal using <code>cat</code> and <code>echo</code>. This feels like actual magic.</p>
2611.  
2612.  
2613.  
2614. <p>I added a new option to <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/">ssam_openqa</a>, available whenever the test runner is paused, to open a terminal connection to this virtio console, and now I can debug directly from the terminal on my host. I learned a few things about line buffering and terminal control codes along the way.<em> (I didn’t get ANSI control codes like cursor movement to work, yet – not sure if my code is sending them wrong, or some TERM config is needed on the VM side. – but with backspace, tab and enter working it’s already fairly usable).</em></p>
2615.  
2616.  
2617.  
2618. <p>Here’s a quick demo of the feature:<br/><br/></p>
2619.  
2620.  
2621.  
2622. <figure class="wp-block-embed is-type-rich is-provider-embed-handler wp-block-embed-embed-handler wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
2623. <div class="jetpack-video-wrapper"/>
2624. </div></figure>
2625.  
2626.  
2627.  
2628. <p>Available in the 1.2.0-rc1 release. Happy debugging!</p>
2629.  
2630.  
2631.  
2632. <h2 class="wp-block-heading">Cross country travel</h2>
2633.  
2634.  
2635.  
2636. <p>Most of this month I was on holiday.  If you’re a fan of overland travel, how about this: Aberdeen to Santiago in 48 hours; via night train to Crewe, camper van to Plymouth, ferry to Santander and then more driving across to Galicia. A fun trip, although I got pretty seasick on the boat until I’d had a good nights sleep. (This wasn’t a particularly low-carbon trip though despite going overland, as the train, ferry and van are all powered by big diesel engines.)</p>
2637.  
2638.  
2639.  
2640. <p>And now back to regular work – “Moving files from one machine to another using Python and YAML”, etc.</p></div>
2641.    </content>
2642.    <updated>2024-04-17T13:41:37Z</updated>
2643.    <published>2024-04-17T13:41:37Z</published>
2644.    <category term="Build and Test Tools"/>
2645.    <category term="General"/>
2646.    <category term="gnome"/>
2647.    <author>
2648.      <name>Sam Thursfield</name>
2649.    </author>
2650.    <source>
2651.      <id>https://samthursfield.wordpress.com</id>
2652.      <logo>https://samthursfield.wordpress.com/wp-content/uploads/2020/10/cropped-favicon.png?w=32</logo>
2653.      <link href="https://samthursfield.wordpress.com/feed/" rel="self" type="application/rss+xml"/>
2654.      <link href="https://samthursfield.wordpress.com" rel="alternate" type="text/html"/>
2655.      <link href="https://samthursfield.wordpress.com/osd.xml" rel="search" title="Sam Thursfield" type="application/opensearchdescription+xml"/>
2656.      <link href="https://samthursfield.wordpress.com/?pushpress=hub" rel="hub" type="text/html"/>
2657.      <subtitle>Software and technology from Galicia, Spain</subtitle>
2658.      <title>Sam Thursfield</title>
2659.      <updated>2024-05-16T13:56:03Z</updated>
2660.    </source>
2661.  </entry>
2662.  
2663.  <entry>
2664.    <id>tag:base-art.net,2024-04-16:/Articles/from-webkitgstreamer-to-rust-av-a-journey-on-our-stacks-layers/</id>
2665.    <link href="https://base-art.net/Articles/from-webkitgstreamer-to-rust-av-a-journey-on-our-stacks-layers/" rel="alternate" type="text/html"/>
2666.    <title>From WebKit/GStreamer to rust-av, a journey on our stack’s layers</title>
2667.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>In this post I’ll try to document the journey starting from a WebKit issue and
2668. ending up improving third-party projects that WebKitGTK and WPEWebKit depend on.</p>
2669. <p>I’ve been working on WebKit’s GStreamer backends for a while. Usually some new
2670. feature needed on WebKit side would trigger work …</p></div>
2671.    </summary>
2672.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>In this post I’ll try to document the journey starting from a WebKit issue and
2673. ending up improving third-party projects that WebKitGTK and WPEWebKit depend on.</p>
2674. <p>I’ve been working on WebKit’s GStreamer backends for a while. Usually some new
2675. feature needed on WebKit side would trigger work on GStreamer. That’s quite
2676. common and healthy actually, by improving GStreamer (bug fixes or implementing
2677. new features) we make the whole stack stronger (hopefully). It’s not hard to
2678. imagine other web-engines, such as Servo for instance, leveraging fixes made in
2679. GStreamer in the context of WebKit use-cases.</p>
2680. <p>Sometimes though we have to go deeper and this is what this post is about!</p>
2681. <p>Since version 2.44, WebKitGTK and WPEWebKit ship with a
2682. <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_API">WebCodecs</a>
2683. backend. That backend leverages the wide range of GStreamer audio and video
2684. decoders/encoders to give low-level access to encoded (or decoded) audio/video
2685. frames to Web developers. I delivered a <a href="https://gstconf.ubicast.tv/videos/webcodecs-in-webkit-with-gstreamer/">lightning
2686. talk</a> at
2687. gst-conf 2023 about this topic.</p>
2688. <p>There are still some issues to fix regarding performance and some <span class="caps">W3C</span> web
2689. platform tests are still failing. The <span class="caps">AV1</span> decoding tests were flagged early on
2690. while I was working on WebCodecs, I didn’t have time back then to investigate
2691. the failures further, but a couple weeks ago I went back to those specific issues.</p>
2692. <p>The WebKit layout tests harness is executed by various post-commit bots, on
2693. various platforms. The WebKitGTK and WPEWebKit bots run on Linux. The WebCodec
2694. tests for <span class="caps">AV1</span> currently make use of the GStreamer <code>av1enc</code> and
2695. <a href="https://gstreamer.freedesktop.org/documentation/dav1d">dav1ddec</a> elements. We
2696. currently don’t run the tests using the modern and hardware-accelerated
2697. <code>vaav1enc</code> and <code>vaav1dec</code> elements because the bots don’t have compatible GPUs.</p>
2698. <p>The decoding tests were failing, <a href="https://github.com/WebKit/WebKit/tree/main/LayoutTests/imported/w3c/web-platform-tests/webcodecs/full-cycle-test.https.any.js">this
2699. one</a>
2700. for instance (the <code>?av1</code> variant). In that test both encoding and decoding are
2701. tested, but decoding was failing, for a couple reasons. Rabbit hole starts here.
2702. After debugging this for a while, it was clear that the colorspace information
2703. was lost between the encoded chunks and the decoded frames. The decoded video
2704. frames didn’t have the expected colorimetry values.</p>
2705. <p>The
2706. <a href="https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.h">VideoDecoderGStreamer</a>
2707. class basically takes encoded chunks and notifies decoded
2708. <a href="https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.h">VideoFrameGStreamer</a>
2709. objects to the upper layers (<span class="caps">JS</span>) in WebCore. A video frame is basically a
2710. GstSample (Buffer and Caps) and we have code in place to interpret the
2711. colorimetry parameters exposed in the sample caps and translate those to the
2712. various WebCore equivalents. So far so good, but the caps set on the <code>dav1ddec</code>
2713. elements didn’t have those informations! I thought the <code>dav1ddec</code> element could
2714. be fixed, “shouldn’t be that hard” and I knew that code because I wrote it in
2715. 2018 :)</p>
2716. <p>So let’s fix the GStreamer <code>dav1ddec</code> element. It’s a video decoder written in
2717. Rust, relying on the <a href="https://github.com/rust-av/dav1d-rs">dav1d-rs</a> bindings of
2718. the popular C <code>libdav1d</code> library. The <code>dav1ddec</code> element basically feeds encoded
2719. chunks of data to dav1d using the dav1d-rs bindings. In return, the bindings
2720. provide the decoded frames using a <code>Dav1dPicture</code> Rust structure and the
2721. <code>dav1ddec</code> GStreamer element basically makes buffers and caps out of this
2722. decoded picture. The dav1d-rs bindings are quite minimal, we implemented <span class="caps">API</span> on
2723. a per-need basis so far, so it wasn’t very surprising that… colorimetry
2724. information for decoded pictures was not exposed! Rabbit hole goes one level deeper.</p>
2725. <p>So let’s add colorimetry <span class="caps">API</span> in <code>dav1d-rs</code>. When working on (Rust) bindings of a
2726. C library, if you need to expose additional <span class="caps">API</span> the answer is quite often in the
2727. C headers of the library. Every <code>Dav1dPicture</code> has a <code>Dav1dSequenceHeader</code>, in
2728. which we can see a few interesting fields:</p>
2729. <div class="highlight"><pre><span/><code><span class="k">typedef</span><span class="w"> </span><span class="k">struct</span><span class="w"> </span><span class="nc">Dav1dSequenceHeader</span><span class="w"> </span><span class="p">{</span>
2730. <span class="p">...</span>
2731. <span class="w">    </span><span class="k">enum</span><span class="w"> </span><span class="n">Dav1dColorPrimaries</span><span class="w"> </span><span class="n">pri</span><span class="p">;</span><span class="w"> </span><span class="c1">///&lt; color primaries (av1)</span>
2732. <span class="w">    </span><span class="k">enum</span><span class="w"> </span><span class="n">Dav1dTransferCharacteristics</span><span class="w"> </span><span class="n">trc</span><span class="p">;</span><span class="w"> </span><span class="c1">///&lt; transfer characteristics (av1)</span>
2733. <span class="w">    </span><span class="k">enum</span><span class="w"> </span><span class="n">Dav1dMatrixCoefficients</span><span class="w"> </span><span class="n">mtrx</span><span class="p">;</span><span class="w"> </span><span class="c1">///&lt; matrix coefficients (av1)</span>
2734. <span class="w">    </span><span class="k">enum</span><span class="w"> </span><span class="n">Dav1dChromaSamplePosition</span><span class="w"> </span><span class="n">chr</span><span class="p">;</span><span class="w"> </span><span class="c1">///&lt; chroma sample position (av1)</span>
2735. <span class="w">    </span><span class="p">...</span>
2736. <span class="w">    </span><span class="kt">uint8_t</span><span class="w"> </span><span class="n">color_range</span><span class="p">;</span>
2737. <span class="w">    </span><span class="p">...</span>
2738. <span class="p">...</span>
2739. <span class="p">}</span><span class="w"> </span><span class="n">Dav1dSequenceHeader</span><span class="p">;</span>
2740. </code></pre></div>
2741.  
2742. <p>After sharing a naive branch with rust-av co-maintainers <a href="https://github.com/lu-zero">Luca
2743. Barbato</a> and <a href="https://github.com/sdroege">Sebastian
2744. Dröge</a>, I came up with a
2745. <a href="https://github.com/rust-av/dav1d-rs/pull/94">couple</a>
2746. <a href="https://github.com/rust-av/dav1d-rs/pull/97">pull-requests</a> that eventually
2747. were shipped in version 0.10.3 of dav1d-rs. I won’t deny matching primaries,
2748. transfer, matrix and chroma-site enum values to <code>rust-av</code><span class="quo">‘</span>s Pixel enum was a bit
2749. challenging :P Anyway, with <code>dav1d-rs</code> fixed up, rabbit hole level goes up one
2750. level :)</p>
2751. <p>Now with the needed <code>dav1d-rs</code> <span class="caps">API</span>, the GStreamer <code>dav1ddec</code> element could be
2752. fixed. Again, matching the various enum values to their GStreamer equivalent was
2753. an interesting exercise. The <a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1514">merge
2754. request</a>
2755. was merged, but to this date it’s not shipped in a stable gst-plugins-rs release
2756. yet. There’s one more complication here, <span class="caps">ABI</span> broke between <code>dav1d</code> 1.2 and 1.4
2757. versions. The <code>dav1d-rs</code> 0.10.3 release expects the latter. I’m not sure how we
2758. will cope with that in terms of gst-plugins-rs release versioning…</p>
2759. <p>Anyway, WebKit’s runtime environment can be adapted to ship dav1d 1.4 and
2760. development version of the <code>dav1ddec</code> element, which is what was done in this
2761. <a href="https://github.com/WebKit/WebKit/pull/27218">pull request</a>. The rabbit is
2762. getting out of his hole.</p>
2763. <p>The WebCodec <span class="caps">AV1</span> tests were finally fixed in WebKit, by this <a href="https://github.com/WebKit/WebKit/pull/27230">pull
2764. request</a>. Beyond colorimetry
2765. handling a few more fixes were needed, but luckily those didn’t require any
2766. fixes outside of WebKit.</p>
2767. <p>Wrapping up, if you’re still reading this post, I thank you for your patience.
2768. Working on inter-connected projects can look a bit daunting at times, but
2769. eventually the whole ecosystem benefits from cross-project collaborations like
2770. this one. Thanks to Luca and Sebastian for the help and reviews in <code>dav1d-rs</code>
2771. and the <code>dav1ddec</code> element. Thanks to my fellow <a href="https://igalia.com">Igalia</a>
2772. colleagues for the WebKit reviews.</p></div>
2773.    </content>
2774.    <updated>2024-04-16T20:15:00Z</updated>
2775.    <published>2024-04-16T20:15:00Z</published>
2776.    <category term="misc"/>
2777.    <category term="Projects"/>
2778.    <category term="WebKit"/>
2779.    <category term="GStreamer"/>
2780.    <author>
2781.      <name>Philippe Normand</name>
2782.    </author>
2783.    <source>
2784.      <id>https://base-art.net/</id>
2785.      <link href="https://base-art.net/" rel="alternate" type="text/html"/>
2786.      <link href="https://base-art.net/feeds/philippe-normand.atom.xml" rel="self" type="application/atom+xml"/>
2787.      <title>Base-Art - Philippe Normand</title>
2788.      <updated>2024-04-16T20:15:00Z</updated>
2789.    </source>
2790.  </entry>
2791.  
2792.  <entry>
2793.    <id>https://blog.sonny.re/retro-v2</id>
2794.    <link href="https://blog.sonny.re/retro-v2?pk_campaign=rss-feed" rel="alternate" type="text/html"/>
2795.    <title>Retro v2</title>
2796.    <summary>&lt;![CDATA[
2797.  
2798. Retro; the customizable clock widget is now available on Flathub in v2
2799.  
2800. a href='https://flathub.org/apps/re.sonny.Retro'img width='240' alt='Download on Flathub' src='https://flathub.org/api/badge?locale=en'//a
2801.  
2802. This new release comes with
2803.  
2804. Support both 12h and 24h clock format. It follows GNOME Date & Time preference while being sandboxed thanks to libportal new API for the settings portal.
2805.  
2806. Energy usage has been improved by using a more efficient method to get the time and by making use of the magic GtkWindow.suspended property to stop updating the clock when the window is not visible.
2807.  
2808. Better support for round clocks. The new GTK renderer fixed the visual glitch on transparent corners caused by large border radius. Retro now restores window dimensions and disables the border radius on maximize to make it look good, no matter the shape.
2809.  
2810. Controls have been moved to a floating header bar to stay out of the way and prevent interference with customizations.
2811.  
2812. There are further improvements to do, but I decided to publish early because Retro was using GNOME 43 runtime which is end-of-life and I have limited time to spend on it.
2813.  
2814. Help welcome https://github.com/sonnyp/Retro/issues]]&gt;</summary>
2815.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><img alt="" src="https://i.snap.as/mcikkbiD.png"/></p>
2816.  
2817. <p>Retro; the customizable clock widget is now available on Flathub in v2</p>
2818.  
2819. <p><a href="https://flathub.org/apps/re.sonny.Retro"><img alt="Download on Flathub" src="https://flathub.org/api/badge?locale=en" width="240"/></a></p>
2820.  
2821. <p>This new release comes with</p>
2822.  
2823. <p>Support both 12h and 24h clock format. It follows GNOME Date &amp; Time preference while being sandboxed thanks to <a href="https://github.com/flatpak/libportal/pull/143">libportal new API for the settings portal</a>.</p>
2824.  
2825. <p>Energy usage has been improved by using a more efficient method to get the time and by making use of the magic <a href="https://docs.gtk.org/gtk4/method.Window.is_suspended.html"><code>GtkWindow.suspended</code> property</a> to stop updating the clock when the window is not visible.</p>
2826.  
2827. <p>Better support for round clocks. The new GTK renderer fixed the visual glitch on transparent corners caused by large border radius. Retro now restores window dimensions and disables the border radius on maximize to make it look good, no matter the shape.</p>
2828.  
2829. <p>Controls have been moved to a floating header bar to stay out of the way and prevent interference with customizations.</p>
2830.  
2831. <p>There are further improvements to do, but I decided to publish early because Retro was using GNOME 43 runtime which is end-of-life and I have limited time to spend on it.</p>
2832.  
2833. <p>Help welcome <a href="https://github.com/sonnyp/Retro/issues">https://github.com/sonnyp/Retro/issues</a></p></div>
2834.    </content>
2835.    <updated>2024-04-16T11:36:55Z</updated>
2836.    <published>2024-04-16T11:36:55Z</published>
2837.    <source>
2838.      <id>https://blog.sonny.re/</id>
2839.      <logo>https://i.snap.as/W5pFkgq1.jpg</logo>
2840.      <author>
2841.        <name>Sonny Piers</name>
2842.      </author>
2843.      <link href="https://blog.sonny.re/" rel="alternate" type="text/html"/>
2844.      <link href="https://blog.sonny.re/feed/" rel="self" type="application/rss+xml"/>
2845.      <title>Sonny's</title>
2846.      <updated>2024-05-19T08:03:38Z</updated>
2847.    </source>
2848.  </entry>
2849.  
2850.  <entry xml:lang="en-US">
2851.    <id>https://blogs.gnome.org/otte/?p=6916</id>
2852.    <link href="https://blogs.gnome.org/otte/2024/04/14/making-gtk-graphics-offloading-work/" rel="alternate" type="text/html"/>
2853.    <title>Making GTK graphics offloading work</title>
2854.    <summary>(I need to put that somewhere because people ask about it and having a little post to explain it is nice.) What’s it about? GTK recently introduced the ability to offload graphics rendering, but it needs rather recent everything to work well for offloading video decoding. So, what do you need to make sure this […]</summary>
2855.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>(I need to put that somewhere because people ask about it and having a little post to explain it is nice.)</p>
2856. <p>What’s it about?<br/>
2857. <a href="https://blog.gtk.org/2023/11/15/introducing-graphics-offload/">GTK recently introduced the ability to offload graphics rendering</a>, but it needs rather recent everything to work well for offloading video decoding.</p>
2858. <p>So, what do you need to make sure this works?</p>
2859. <p>First, you of course need a video to test. On a modern desktop computer, you want a 4k 60fps video or better to have something that pushes your CPU to the limits so you know when it doesn’t work. Of course, the recommendation has to be <a href="http://bbb3d.renderfarming.net/download.html">Big Buck Bunny at the highest of qualities</a> – be aware that the most excellent 4000×2250 @ 60fps encoding is 850MB. On my Intel TigerLake, that occasionally drops frames when I play that with software decoding, and I can definitely hear the fan turn on.<br/>
2860. When selecting a video file, keep in mind that the format matters.</p>
2861. <p>Second, you need hardware decoding. That is provided by libva and can be queried using the <code>vainfo</code> tool (which comes in the `libva-utils` package in Fedora). If that prints a long list of formats (it’s about 40 for me), you’re good. If it doesn’t, you’ll need to go hunt for the drivers – due to the patent madness surrounding video formats that may be more complicated than you wish. For example, on my Intel laptop on Fedora, I need the <code>intel-media-driver</code> package which is hidden in the nonfree <a href="https://rpmfusion.org/Configuration/">RPMFusion repository</a>.<br/>
2862. If you look at the list from <code>vainfo</code>, the format names give some hints – usually VP9 and MPEG2 exist. H264 and HEVC aka H265 are the patent madness, and recent GPUs can sometimes do AV1. The Big Buck Bunny video from above is H264, so if you’re following along, make sure that works.</p>
2863. <p>Now you need a working video player. I’ll be using <code>gtk4-demo</code> (which is in the <code>gtk4-devel-tools</code> package, but you already have that installed of course) and its video player example because I know it works there. A shoutout goes out to <a href="https://github.com/agx/livi">livi</a> which was the first non-demo video player to have a release that supports graphics offloading. You need GTK 4.14 and GStreamer 1.24 for this to work. At the time of writing, this is only available in Fedora rawhide, but hopefully Fedora 40 will gain the packages soon.</p>
2864. <p>If you installed new packages above, now is a good time to check if GStreamer picked up all the hardware decoders. <code>gst-inspect-1.0 va</code> will list all the elements with libva support. If it didn’t pick up decoders for all the formats it should have (there should be a <code>vah264dec</code> listed for H264 if you want to decode the video above), then the easiest way to get them is to delete GStreamer’s registry cache in <code>~/.cache/gstreamer-1.0</code>.</p>
2865. <p>If you want to make sure GStreamer does the right thing, you can run the video player with <code>GST_DEBUG=GST_ELEMENT_FACTORY:4</code>. It will print out debug messages about all the elements it is creating for playback. If that includes a line for an element from the previous list (like `vah264dec` in our example) things are working. If it picks something else (like `avdec_h264` or `openh264dec`) then they are not.</p>
2866. <p>Finally you need a compositor that supports YUV formats. Most compositors do – gnome-shell does since version 45 for example – but checking can’t hurt: If <code>wayland-info</code> (in the <code>wayland-utils</code> package in Fedora) lists the NV12 format, you’re good.</p>
2867. <p>And now everything works.<br/>
2868. If you have a 2nd monitor you can marvel at what goes on behind the scenes by running the video player with <code>GDK_DEBUG=dmabuf,offload</code> and GTK will tell you what it does for every frame, and you can see it dynamically switching between offloading or not as you fullscreen (or not), click on the controls (or not) and so on. Or you could have used it previously to see why things didn’t work.<br/>
2869. You can also look at the <code>top</code> and <code>gputop</code> variant of your choice and you will see that the video player takes a bit of CPU to drive the video decoding engine and inform the compositor about new frames and the compositor takes a bit of CPU telling the 3D engine to composite things and send them to the monitor. With the video above it’s around 10% on my laptop for the CPU usage each and about 20% GPU usage.</p>
2870. <p>And before anyone starts complaining that this is way too complicated: If you read carefully, all of this should work out of the box in the near future. This post just lists the tools to troubleshoot what went wrong while developing a fast video player.</p></div>
2871.    </content>
2872.    <updated>2024-04-14T16:37:14Z</updated>
2873.    <published>2024-04-14T16:37:14Z</published>
2874.    <category term="General"/>
2875.    <author>
2876.      <name>Benjamin Otte</name>
2877.    </author>
2878.    <source>
2879.      <id>https://blogs.gnome.org/otte</id>
2880.      <link href="https://blogs.gnome.org/otte/feed/" rel="self" type="application/rss+xml"/>
2881.      <link href="https://blogs.gnome.org/otte" rel="alternate" type="text/html"/>
2882.      <subtitle>Swfdec, GStreamer, Cairo, GNOME, me</subtitle>
2883.      <title>Swfblag</title>
2884.      <updated>2024-04-14T16:37:14Z</updated>
2885.    </source>
2886.  </entry>
2887.  
2888.  <entry xml:lang="en-US">
2889.    <id>https://blogs.gnome.org/haeckerfelix/?p=3238</id>
2890.    <link href="https://blogs.gnome.org/haeckerfelix/2024/04/07/fragments-3-0/" rel="alternate" type="text/html"/>
2891.    <link href="https://blogs.gnome.org/haeckerfelix/files/2024/04/Screencast-from-2024-04-07-19-53-28.webm" length="3566506" rel="enclosure" type="video/webm"/>
2892.    <link href="https://blogs.gnome.org/haeckerfelix/2024/04/07/fragments-3-0/#comments" rel="replies" type="text/html"/>
2893.    <link href="https://blogs.gnome.org/haeckerfelix/2024/04/07/fragments-3-0/feed/atom/" rel="replies" type="application/atom+xml"/>
2894.    <title xml:lang="en-US">Fragments 3.0</title>
2895.    <summary type="xhtml" xml:lang="en-US"><div xmlns="http://www.w3.org/1999/xhtml">It has finally happened! The long awaited major update of Fragments is now available, which includes many exciting new features. The most important addition is support for torrent files. It is now possible to select the files you want to download from a torrent. The files can be searched and sorted, individual files can be … <a class="more-link" href="https://blogs.gnome.org/haeckerfelix/2024/04/07/fragments-3-0/">Continue reading <span class="screen-reader-text">Fragments 3.0</span></a></div>
2896.    </summary>
2897.    <content type="xhtml" xml:lang="en-US"><div xmlns="http://www.w3.org/1999/xhtml"><p>It has finally happened! The long awaited major update of Fragments is now available, which includes many exciting new features.</p>
2898.  
2899.  
2900.  
2901. <figure class="wp-block-image size-full"><img alt="" class="alignnone size-full wp-image-3286" height="822" src="https://blogs.gnome.org/haeckerfelix/files/2024/04/3.png" width="1022"/></figure>
2902.  
2903.  
2904.  
2905. <p>The most important addition is support for torrent files. It is now possible to select the files you want to download from a torrent. The files can be searched and sorted, individual files can be opened directly from Fragments.</p>
2906.  
2907.  
2908.  
2909. <div class="wp-video" style="width: 660px;"><!--[if lt IE 9]><script>document.createElement('video');</script><![endif]-->
2910. <video class="wp-video-shortcode" controls="" height="524" id="video-3238-1" preload="metadata" width="660"><source src="https://blogs.gnome.org/haeckerfelix/files/2024/04/Screencast-from-2024-04-07-19-53-28.webm?_=1" type="video/webm"/><a href="https://blogs.gnome.org/haeckerfelix/files/2024/04/Screencast-from-2024-04-07-19-53-28.webm">https://blogs.gnome.org/haeckerfelix/files/2024/04/Screencast-from-2024-04-07-19-53-28.webm</a></video></div>
2911.  
2912.  
2913.  
2914. <p><strong>Further new features</strong></p>
2915. <ul>
2916. <li>
2917. <ul>
2918. <li>Added torrents can now be searched</li>
2919. <li>In addition to magnet links, *.torrent links in the clipboard are now also recognized</li>
2920. <li>Prevent system from going to sleep when torrents are active</li>
2921. <li>New torrents can be added via drag and drop</li>
2922. <li>Automatic trashing of *.torrent files after adding them</li>
2923. <li>Stop downloads when a metered network gets detected</li>
2924. </ul>
2925. </li>
2926. </ul>
2927. <p><img alt="" class="alignnone size-full wp-image-3265" height="793" src="https://blogs.gnome.org/haeckerfelix/files/2024/04/Screenshot-from-2024-04-07-20-08-17.png" width="1022"/></p>
2928. <ul>
2929.  
2930.  
2931.  
2932.  
2933.  
2934.  
2935.  
2936. </ul>
2937. <ul/>
2938.  
2939.  
2940.  
2941. <p><strong>Improvements</strong></p>
2942. <ul>
2943. <li>
2944. <ul>
2945. <li>When controlling remote sessions, the local Transmission daemon no longer gets started</li>
2946. <li>Torrents are automatically restarted if an incorrect location has been fixed</li>
2947. <li>Torrents can now also be added via CLI</li>
2948. <li>Clipboard toast notification is no longer displayed multiple times</li>
2949. <li>Reduced CPU/resource consumption through adaptive polling interval</li>
2950. <li>Improved accessibility of the user interface</li>
2951. <li>Modernized user interface through the use of new Adwaita widgets</li>
2952. <li>Update from Transmission 3.0.5 to 4.0.5</li>
2953. </ul>
2954. </li>
2955. </ul>
2956.  
2957.  
2958.  
2959. <ul/>
2960.  
2961.  
2962.  
2963. <p>Thanks to Maximiliano and Tobias for once again helping with this release. As usual this release contains many other improvements, fixes and new translations thanks to all the contributors and upstream projects.</p>
2964. <p>Also a big shoutout to the Transmission project, without which Fragments would not be possible, for their fantastic 4.0 release!</p>
2965. <p>The new Fragments release can be downloaded and installed from Flathub:</p>
2966. <p><a href="https://flathub.org/apps/details/de.haeckerfelix.Fragments"><img class="alignnone " height="86" src="https://flathub.org/assets/badges/flathub-badge-en.png" width="248"/></a></p></div>
2967.    </content>
2968.    <updated>2024-04-07T18:51:23Z</updated>
2969.    <published>2024-04-07T18:51:23Z</published>
2970.    <author>
2971.      <name>haeckerfelix</name>
2972.    </author>
2973.    <source>
2974.      <id>https://blogs.gnome.org/haeckerfelix/feed/atom/</id>
2975.      <link href="https://blogs.gnome.org/haeckerfelix" rel="alternate" type="text/html"/>
2976.      <link href="https://blogs.gnome.org/haeckerfelix/feed/atom/" rel="self" type="application/atom+xml"/>
2977.      <subtitle xml:lang="en-US">Just another development blog</subtitle>
2978.      <title xml:lang="en-US">Felix Häcker</title>
2979.      <updated>2024-04-07T18:51:23Z</updated>
2980.    </source>
2981.  </entry>
2982.  
2983.  <entry xml:lang="en-US">
2984.    <id>https://blogs.gnome.org/xjuan/?p=6265</id>
2985.    <link href="https://blogs.gnome.org/xjuan/2024/04/06/cambalache-0-90-0-released/" rel="alternate" type="text/html"/>
2986.    <title>Cambalache 0.90.0 Released!</title>
2987.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Hi, I am happy to announce a new Cambalache stable release. With the UI ported to Gtk 4 I bumped the version to 0.90 to reflect the fact we are really close to 1.0 Release Notes: Migrate main application to Gtk 4 Update widget catalogs to SDK 46 Add support for child custom fragments Add … <a class="more-link" href="https://blogs.gnome.org/xjuan/2024/04/06/cambalache-0-90-0-released/">Continue reading <span class="screen-reader-text">Cambalache 0.90.0 Released!</span></a></div>
2988.    </summary>
2989.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Hi, I am happy to announce a new Cambalache stable release.</p>
2990. <p>With the UI ported to Gtk 4 I bumped the version to 0.90 to reflect the fact we are really close to 1.0</p>
2991. <p><a href="https://blogs.gnome.org/xjuan/files/2024/02/Screenshot-from-2024-02-16-09-13-58.png"><img alt="Editing Cambalache UI in Cambalache" class="alignnone size-full wp-image-6258" height="1169" src="https://blogs.gnome.org/xjuan/files/2024/02/Screenshot-from-2024-02-16-09-13-58.png" width="2109"/></a></p>
2992. <h3>Release Notes:</h3>
2993. <ul>
2994. <li>
2995. <ul>
2996. <li>Migrate main application to Gtk 4</li>
2997. <li>Update widget catalogs to SDK 46</li>
2998. <li>Add support for child custom fragments</li>
2999. <li>Add add parent context menu action</li>
3000. <li>Mark AdwSplitButton.dropdown-tooltip translatable. (Danial Behzadi)</li>
3001. </ul>
3002. </li>
3003. </ul>
3004. <h3>Where to get it?</h3>
3005. <p>You can get it from Flathub</p>
3006. <pre>flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
3007.  
3008. flatpak install flathub ar.xjuan.Cambalache</pre>
3009. <p>or checkout cmb-90 branch at <a href="https://gitlab.gnome.org/jpu/cambalache">gitlab</a></p>
3010. <blockquote>
3011. <pre>git clone https://gitlab.gnome.org/jpu/cambalache.git</pre>
3012. </blockquote>
3013. <h3>Matrix channel</h3>
3014. <p>Have any question? come chat with us at <a href="https://matrix.to/#/#cambalache:gnome.org">#cambalache:gnome.org</a></p>
3015. <h3>Mastodon</h3>
3016. <p>Follow me in Mastodon <a href="https://mastodon.social/@xjuan">@xjuan</a> to get news related to Cambalache development.</p>
3017. <p>Happy coding!</p></div>
3018.    </content>
3019.    <updated>2024-04-06T20:31:36Z</updated>
3020.    <published>2024-04-06T20:31:36Z</published>
3021.    <author>
3022.      <name>xjuan</name>
3023.    </author>
3024.    <source>
3025.      <id>https://blogs.gnome.org/xjuan</id>
3026.      <link href="https://blogs.gnome.org/xjuan/feed/" rel="self" type="application/rss+xml"/>
3027.      <link href="https://blogs.gnome.org/xjuan" rel="alternate" type="text/html"/>
3028.      <subtitle>Just another GNOME Blogs site</subtitle>
3029.      <title>ar.xjuan.Blog</title>
3030.      <updated>2024-04-06T20:31:36Z</updated>
3031.    </source>
3032.  </entry>
3033.  
3034.  <entry xml:lang="en-us">
3035.    <id>https://jensge.org/2024/04/06/exercises-in-reversing/</id>
3036.    <link href="https://jensge.org/2024/04/06/exercises-in-reversing/" rel="alternate" type="text/html"/>
3037.    <title>Exercises in Reversing</title>
3038.    <summary>As a follow-up in spirit of reversing the USB a blood pressure monitor See Github project I was part of a project to revive a GPS receiver from the late 2000s. This is still work in process since it is still not possible to decode the actual GPS data, but we are getting there.
3039. The code and documentation is also available at github and we’ve done a talk about the project at Easterhegg 21, which is on media.</summary>
3040.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>As a follow-up in spirit of reversing the USB a blood pressure monitor
3041. <a href="https://github.com/phako/bpm">See Github project</a> I was part of a project to
3042. revive a GPS receiver from the late 2000s. This is still work in process since
3043. it is still not possible to decode the actual GPS data, but we are getting there.</p>
3044. <p>The code and documentation is also <a href="https://github.com/phako/geotate-gps-receiver">available at github</a> and we’ve done a talk about the project at Easterhegg 21, which is <a href="https://media.ccc.de/v/eh21-67-digital-ewaste-anatomie-und-wiederbelebung-eines-gps-dingsis">on media.ccc.de</a> (german only, sorry).</p></div>
3045.    </content>
3046.    <updated>2024-04-06T13:27:35Z</updated>
3047.    <published>2024-04-06T13:27:35Z</published>
3048.    <source>
3049.      <id>https://jensge.org/tag/english/feed/index.xml</id>
3050.      <author>
3051.        <name>Jens Georg</name>
3052.      </author>
3053.      <link href="https://jensge.org/tag/english/feed/index.xml" rel="alternate" type="text/html"/>
3054.      <link href="https://jensge.org/tag/english/feed/index.xml" rel="self" type="application/rss+xml"/>
3055.      <subtitle>Recent content in English on The adventures of foo</subtitle>
3056.      <title>English on The adventures of foo</title>
3057.      <updated>2024-04-06T13:27:35Z</updated>
3058.    </source>
3059.  </entry>
3060.  
3061.  <entry xml:lang="en-us">
3062.    <id>https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/</id>
3063.    <link href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/" rel="alternate" type="text/html"/>
3064.    <title>Just How Much Faster Are the GNOME 46 Terminals?</title>
3065.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./header.jpg">
3066.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./header.jpg"/>
3067. </a>
3068. </p>
3069. <p><a href="https://gitlab.gnome.org/GNOME/vte">VTE</a> (Virtual TErminal library) is the library underpinning various GNOME terminal emulators.
3070. It provides a GTK widget that shows a terminal view, which is used in apps like <a href="https://gitlab.gnome.org/GNOME/gnome-terminal">GNOME Terminal</a>, <a href="https://gitlab.gnome.org/GNOME/console">Console</a>, <a href="https://gitlab.gnome.org/raggesilver/blackbox">Black Box</a>, <a href="https://github.com/gnunn1/tilix">Tilix</a>, <a href="https://github.com/gnome-terminator/terminator">Terminator</a>, <a href="https://gitlab.gnome.org/chergert/ptyxis">Ptyxis</a>, and others.
3071. It also powers embedded terminals in <a href="https://gitlab.gnome.org/GNOME/gnome-builder">Builder</a> and <a href="https://github.com/workbenchdev/Workbench">Workbench</a>.</p>
3072. <p>Over the GNOME 46 cycle, VTE has seen a <em>lot</em> of performance improvements.
3073. Christian Hergert mentioned some of them in his blog posts <a href="https://blogs.gnome.org/chergert/2023/10/03/vte-performance-improvements/">about VTE</a> and <a href="https://blogs.gnome.org/chergert/2024/03/25/gnome-45-46-retrospective/">about his work in GNOME 46</a>.
3074. But how much did the performance actually improve?
3075. What should you, the user, expect to <em>feel</em> after installing a fresh <a href="https://fedoraproject.org">Fedora</a> 40 update and launching your favorite terminal?</p>
3076. <p>Let’s measure and find out!
3077. If you don’t have time for measuring, you can <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#input-latency-tests">skip</a> straight to the finding out.</p>
3078. <h2 id="what-are-we-measuring">What Are We Measuring? <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#what-are-we-measuring">#</a></h2><p>There is no shortage of ways to define “performance”, especially when it comes to terminal emulators.
3079. One of the more tangible metrics is <em>input latency</em>.
3080. Roughly, it describes how quickly the program reacts to your actions: how much time passes from the moment you press a key on your keyboard to the change in color of the pixels on your monitor.
3081. Apps with low input latency feel snappy, whereas apps with high input latency can feel sluggish.</p>
3082. <p>When the input latency is small-ish, you can get used to it and think it feels <em>fine</em>.
3083. However, comparing lower and higher input latency together (for example, by switching between two apps and typing in both) can make it quite noticeable.
3084. If you’ve ever heard people say they can’t go back to a 60 Hz monitor after trying out 144 Hz, that’s a similar effect (and input latency is partially responsible).</p>
3085. <p>So, how do you measure it?</p>
3086. <h3 id="measuring-input-latency">Measuring Input Latency <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#measuring-input-latency">#</a></h3><p>There are tools like <a href="https://pavelfatin.com/typometer/">Typometer</a> that measure the input latency in software by detecting key press events and recording the screen to detect a change in pixel color.
3087. This can work reasonably well but requires fiddling with your setup to make sure you’re not accidentally introducing any biases.
3088. For example, a screen capture API may return the new pixel colors a few milliseconds before or after they are shown on the monitor, depending on the system setup, and you need to be aware of this when trying to measure something to a millisecond precision.</p>
3089. <p>I’ve got something more interesting, a hardware input latency tester!
3090. It consists of a light sensor attached to a <a href="https://www.pjrc.com/store/teensy32.html">Teensy</a> board, which in turn is plugged into the computer via USB.</p>
3091. <figure>
3092.    <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./latency-tester.jpg">
3093.    
3094.    <img alt="Photo of the latency tester." src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./latency-tester.jpg" width="300"/>
3095.    
3096.    </a>
3097.    <figcaption>
3098.        
3099.    </figcaption>
3100. </figure>
3101.  
3102. <p>I should really get around to writing a full blog post about this latency tester, but for now, you should read <a href="https://thume.ca/2020/05/20/making-a-latency-tester/">this post by Tristan Hume</a> about building a similar device.<sup id="fnref:1"><a class="footnote-ref" href="https://bxt.rs/tags/planet-gnome/index.xml#fn:1">1</a></sup>
3103. I used that post as a reference for building mine, but I wrote <a href="https://gist.github.com/YaLTeR/8e8bd0cddb324a9e372b32e742ff992a">my own firmware</a> and analysis scripts (these I am <em>not</em> sharing until they are less of an utter mess).</p>
3104. <p>The main benefit of such a device is that it allows you to measure a full end-to-end input latency, including processing time in the kernel, the compositor, the application, and then the response time of the monitor itself.
3105. You are measuring what you really see and feel, excluding only the keyboard firmware (since the latency tester sends key press events directly over USB).
3106. There’s also very little extra load on the system, especially compared to using something like a screen capture API.</p>
3107. <p>Here’s a gist of how it works.
3108. The light sensor is aimed at a specific, small area on the monitor, which will be affected by the key press (in our case, a specific character cell in the terminal).
3109. The board sends a key press over USB (for example, Space) and starts monitoring the light sensor readings.
3110. As soon as it detects a jump in the light amount, it releases the key.
3111. Then, it presses a second key (for example, Backspace) and waits for the light to change back.
3112. Now we’re back to square one; the firmware waits a randomized amount (to prevent “snapping” to the monitor refresh rate) and repeats the experiment.</p>
3113. <p>During all of this process, the board dumps light sensor readings over a serial port as fast as it can manage (I’m getting about 35,500 readings per second with my current board and firmware).
3114. On the computer, I save all of this data into a file for offline analysis with Python code.
3115. This analysis code finds the timestamp where the light starts to change, and subtracts it from the timestamp of the key press, to get one input latency measurement.</p>
3116. <p>I then aggregate the measurements and plot them with <a href="https://seaborn.pydata.org/">seaborn</a>.
3117. Here’s an example of what the result looks like:</p>
3118. <figure>
3119.    <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./example-latency.png">
3120.    
3121.    <img src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./example-latency.png" width="200"/>
3122.    
3123.    </a>
3124.    <figcaption>
3125.        
3126.    </figcaption>
3127. </figure>
3128.  
3129. <h3 id="input-latency-plots">Input Latency Plots <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#input-latency-plots">#</a></h3><p>Let’s explore what you can find on this latency plot.</p>
3130. <figure>
3131.    <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./example-latency-breakdown.png">
3132.    
3133.    <img src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./example-latency-breakdown.png" width="500"/>
3134.    
3135.    </a>
3136.    <figcaption>
3137.        
3138.    </figcaption>
3139. </figure>
3140.  
3141. <p>The small black dots represent the individual measurements.
3142. As in, every dot shows a real amount of time that had passed between one key press and the corresponding change in light on the sensor.
3143. There are 120 of these dots since I repeat each test 120 times.</p>
3144. <p>Looking at the dots can confirm that the data is sensible.
3145. We expect the bulk of the measurements to be spread uniformly across an interval roughly the size of one monitor repaint cycle.
3146. This is because monitors generally repaint at a constant rate, and pressing a key at a random point in time should land us in a random point of the repaint cycle.
3147. We get the lowest latency if the application renders a new frame in response right in time for the monitor to show it.
3148. And we get the highest latency when the application finishes rendering a new frame <em>just</em> missing the monitor deadline, having to wait one extra repaint cycle for the pixel colors to change.</p>
3149. <p>In the example above, the dots are spread over 7–8 ms, which is about equal to the ~6.94 ms refresh cycle of my 144 Hz monitor.</p>
3150. <p>High outliers in the dots, or a larger spread, indicate lag or slowness of the application under test: some key presses are taking longer than others to process.</p>
3151. <p>We do not expect to see any gaps between dot clusters.
3152. They would usually indicate aliasing with the monitor repaint cycle, or some frame scheduling bug in the compositor.<sup id="fnref:2"><a class="footnote-ref" href="https://bxt.rs/tags/planet-gnome/index.xml#fn:2">2</a></sup></p>
3153. <p>The box shows statistics over the individual measurements:</p>
3154. <ul>
3155. <li>median (a measurement perfectly “in the middle” with half of the measurements lower and half of the measurements higher),</li>
3156. <li>lowest and highest measurement,</li>
3157. <li>25th and 75th percentiles (with 25% and 75% of the measurements lower than the line, respectively).</li>
3158. </ul>
3159. <p>All in all, you can compare applications by their spread, then by the median latency, and also look if there are any outliers.</p>
3160. <p>With all that said, we’re <em>almost</em> ready to look at some results.
3161. I just need to tell you what exactly I was measuring the latency of.</p>
3162. <h2 id="test-setup">Test Setup <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#test-setup">#</a></h2><p>I did all tests on this system:</p>
3163. <ul>
3164. <li><a href="https://www.lenovo.com/us/en/p/laptops/legion-laptops/legion-7-series/legion-7-gen-7-%2816-inch-amd%29/len101g0017">Lenovo Legion 7 Gen 7 AMD</a> with Ryzen 7 6800H CPU and Radeon RX 6700M dGPU (using the dGPU exclusively via the MUX switch).</li>
3165. <li>Monitor: <a href="https://www.acer.com/il-en/monitors/gaming/nitro-xv0/pdp/UM.JX0EE.V01">Acer Nitro XV320QU</a>, 2560×1440, 144 Hz, using 100% scale.</li>
3166. <li>Host: Fedora 40 Silverblue Beta, Mesa 24.0.4.</li>
3167. <li>Compositor: raw Mutter 46.0.</li>
3168. </ul>
3169. <p>What is raw Mutter, you may ask?
3170. Well, Mutter is the compositor that GNOME Shell builds on top of.
3171. Turns out, you can start Mutter on its own, without GNOME Shell, by switching to a different VT and running a command like <code>mutter --display-server -- alacritty</code>.
3172. This gives you a very bare-bones environment that is only really meant for testing.
3173. It is, however, quite useful for benchmarking, as it represents something close to a zero-overhead GNOME Shell ideal case.</p>
3174. <p>I’m testing several terminal applications.
3175. In the order of appearance on the plots, they are:</p>
3176. <ul>
3177. <li><a href="https://github.com/alacritty/alacritty">Alacritty</a>: not VTE-based; serves as a baseline of sorts, because it is consistently one of the fastest terminals according to <a href="https://mastodon.online/@YaLTeR/110837121102628111">all of my prior tests</a>.</li>
3178. <li><a href="https://gitlab.gnome.org/GNOME/console">Console</a>: GTK 4, the default terminal in GNOME.<sup id="fnref:3"><a class="footnote-ref" href="https://bxt.rs/tags/planet-gnome/index.xml#fn:3">3</a></sup></li>
3179. <li><a href="https://gitlab.gnome.org/GNOME/vte/-/tree/0.76.0/src/app">VTE Test App</a>: GTK 4, a test terminal that lives in the VTE repository.</li>
3180. <li><a href="https://gitlab.gnome.org/GNOME/gnome-terminal">GNOME Terminal</a>: GTK 3,<sup id="fnref:4"><a class="footnote-ref" href="https://bxt.rs/tags/planet-gnome/index.xml#fn:4">4</a></sup> used to be the default in GNOME, and is still shipped out of the box in several distributions.</li>
3181. </ul>
3182. <p>Since the intention is to compare GNOME 45 to GNOME 46, I used <a href="https://containertoolbx.org">toolb<span style="font-size: small;">\0</span>x</a> containers with Fedora 39 and Fedora 40 to install and run all terminals above, as packaged by Fedora with no extra tweaks.</p>
3183. <p>I ran the terminals one by one and put their windows in the top left corner of the monitor.
3184. The mouse cursor was outside the window for all tests.<sup id="fnref:5"><a class="footnote-ref" href="https://bxt.rs/tags/planet-gnome/index.xml#fn:5">5</a></sup></p>
3185. <h2 id="input-latency-tests">Input Latency Tests <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#input-latency-tests">#</a></h2><p>The first test is simple: I run <code>cat &gt; /dev/null</code> to get an input field with no readline or similar processing, and then I measure how long it takes for the terminal to move its block cursor one cell to the right after pressing Space.</p>
3186. <p>This is meant to test the best possible scenario for the terminal, with the least overhead.</p>
3187. <p>This is what the test process looks like:</p>
3188. <figure>
3189.    <video controls="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./test-kgx-cat.mp4"/>
3190.    <figcaption>
3191.        
3192.    </figcaption>
3193. </figure>
3194.  
3195. <p>And here are the results:</p>
3196. <p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-cat.png">
3197.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-cat.png"/>
3198. </a>
3199. </p>
3200. <p>Alacritty, which is our baseline, did not change from F39 to F40, as expected.</p>
3201. <p>But look at the massive improvement on all of the VTE terminals!
3202. They went from <em>quite bad</em> to pretty much on par with Alacritty, even the GTK 3 GNOME Terminal is very close.</p>
3203. <p>The main change that caused this much improvement is likely <a href="https://gitlab.gnome.org/GNOME/vte/-/commit/c17d9c6b4571be0ab55c3818d9125233553bb7ee">this one by Christian</a> that moves away from a 40 Hz VTE repaint timer to drawing every frame, synchronized with the monitor, as any self-respecting GTK widget should do.</p>
3204. <p>Console has a few outliers which are <em>maybe</em> caused by its process tracking, but those are nothing new (they may be looked into for GNOME 47).</p>
3205. <p>For the next test, I constructed a more realistic case.
3206. I took <a href="https://github.com/YaLTeR/dotfiles/tree/d3976398058f2f5b6eee57c7e656ee8e7f098ac5/common/.config/_nvim_latency">a snapshot of my neovim setup</a> and opened the README from <a href="https://gitlab.gnome.org/chergert/ptyxis">Ptyxis</a>.
3207. I then strategically replaced a square of text with Unicode full-block characters to provide a bright “landing pad” for the light sensor.</p>
3208. <figure>
3209.    <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./test-kgx-nvim.png">
3210.    
3211.    <img src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./test-kgx-nvim.png" width="480"/>
3212.    
3213.    </a>
3214.    <figcaption>
3215.        
3216.    </figcaption>
3217. </figure>
3218.  
3219. <p>The test consists of repeatedly pressing Ctrl+D and Ctrl+U to scroll the text buffer down and up in neovim.
3220. The light sensor alternates between an empty line (dark) and the full-block landing pad (bright).
3221. The neovim setup has a bunch of bells and whistles, so the terminal gets to have fun drawing the various underlines, undercurls, gutter icons, and the statusline.</p>
3222. <p>This is what the test process looks like:</p>
3223. <figure>
3224.    <video controls="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./test-kgx-nvim.mp4"/>
3225.    <figcaption>
3226.        
3227.    </figcaption>
3228. </figure>
3229.  
3230. <p>Here are the results:</p>
3231. <p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-nvim.png">
3232.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-nvim.png"/>
3233. </a>
3234. </p>
3235. <p>The massive improvement is clear on this test too, and our GNOME 46 terminals are still pretty much on par with Alacritty!</p>
3236. <p>Finally, let’s take a closer look at all Fedora 40 results on one plot:</p>
3237. <p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-f40.png">
3238.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./all-f40.png"/>
3239. </a>
3240. </p>
3241. <p>This plot shows how much of a latency toll the neovim test takes compared to a simple <code>cat</code>, but the latency increase is similar across all terminals.</p>
3242. <h2 id="vtebench">vtebench <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#vtebench">#</a></h2><p>I also ran Alacritty’s <a href="https://github.com/alacritty/vtebench">vtebench</a> suite across the same set of applications and configurations.
3243. This is a fully automated benchmark that measures something <em>completely different</em> from input latency: PTY read and parsing performance.
3244. <del>It has also proven quite capable at finding <a href="https://gitlab.gnome.org/GNOME/vte/-/issues/2747">crashes</a> in VTE.</del></p>
3245. <p>Here’s what vtebench’s README has to say:</p>
3246. <blockquote>
3247. <p>This benchmark is not sufficient to get a general understanding of the performance of a terminal emulator. It lacks support for critical factors like frame rate or latency. The only factor this benchmark stresses is the speed at which a terminal reads from the PTY. If you do not understand what this means, please do not jump to any conclusions from the results of this benchmark.</p>
3248. </blockquote>
3249. <p>The repaint duration can and does affect the results of this test, especially for terminals that read and parse PTY on the same thread as they run their repaint logic, like VTE.</p>
3250. <p>This is what one of the vtebench benchmarks looks like:</p>
3251. <p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench-kgx.jpg">
3252.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench-kgx.jpg"/>
3253. </a>
3254. </p>
3255. <p>And here are the results:</p>
3256. <figure>
3257.    <a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench.png">
3258.    
3259.    <img src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench.png"/>
3260.    
3261.    </a>
3262.    <figcaption>
3263.        <p>To avoid making this plot even busier, I drew the green arrows on only one of the benchmarks.
3264. As you can see, other benchmarks show a similar trend.</p>
3265.  
3266.    </figcaption>
3267. </figure>
3268.  
3269. <p>VTE from GNOME 46 shows some welcome improvements here too, although a lot more varied, and not quite on par with Alacritty (which renders in a separate thread from reading and parsing).
3270. These improvements likely come from the many other optimizations that happened in VTE during the GNOME 46 cycle.</p>
3271. <p>Note that I omitted two benchmarks from these results: <code>dense_cells</code> and <code>unicode</code>.
3272. They are the main stress tests of vtebench that hit the terminal really hard.
3273. Unfortunately, VTE still struggles with them and shows a huge spread, which pushes the rest of the results down and makes the plot less readable.</p>
3274. <details>
3275.    Open this to see the full results if you’re curious.
3276.    <p><a href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench-full.png">
3277.    <img alt="" src="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/./vtebench-full.png"/>
3278. </a>
3279. </p>
3280.  
3281. </details>
3282.  
3283. <h2 id="conclusion">Conclusion <a class="anchor" href="https://bxt.rs/blog/just-how-much-faster-are-the-gnome-46-terminals/#conclusion">#</a></h2><p>VTE had a round of massive performance improvements in GNOME 46 which manifest as something you can really feel during normal terminal use.
3284. The input latency is down to almost matching the fastest terminals, even in a non-trivial neovim setup with lots of complexity on screen.</p>
3285. <p>The remaining difference, at least on these test cases, is close to negligible.
3286. Some of it can be explained by VTE doing a bit more extra work for accessibility (enabled in GNOME Terminal and currently disabled in the GTK 4 terminals), scrollbar calculations, and other features.</p>
3287. <p>If you’ve been avoiding VTE-based terminals due to <em>sluggishness</em> and input lag, now is the time to give them another chance.
3288. Just make sure you’re running VTE 0.76, which includes all of this goodness.</p>
3289. <p>Huge thanks to the VTE maintainers and contributors for making this a reality, and congratulations on an awesome release!</p>
3290. <p>P.S. If you’re curious about Ptyxis or the behavior of GTK’s NGL vs. NVK vs. GL renderers, they all perform similarly to the F40 VTE Test App results shown above.
3291. I did more extensive benchmarks of these a month ago, you can find them <a href="https://gitlab.gnome.org/-/snippets/6439">here</a>.</p>
3292. <div class="footnotes">
3293. <hr/>
3294. <ol>
3295. <li id="fn:1">
3296. <p>As you can tell from the photo, I did <em>not</em> follow Tristan’s advice to make something fancier than just dangling wires. <a class="footnote-backref" href="https://bxt.rs/tags/planet-gnome/index.xml#fnref:1">↩︎</a></p>
3297. </li>
3298. <li id="fn:2">
3299. <p>Just a few weeks ago some measurements I took showed a suspicious one-frame-long gap in the dots.
3300. And guess what, it was a frame scheduling bug in <a href="https://github.com/YaLTeR/niri">my compositor</a>, with none other than myself to blame for it.
3301. Thankfully, it wasn’t hard to fix, and easy to verify afterward by redoing the same test. <a class="footnote-backref" href="https://bxt.rs/tags/planet-gnome/index.xml#fnref:2">↩︎</a></p>
3302. </li>
3303. <li id="fn:3">
3304. <p>Your distribution may have a different idea of which terminal should be the default in its GNOME spin.
3305. For example, Fedora still ships GNOME Terminal by default. <a class="footnote-backref" href="https://bxt.rs/tags/planet-gnome/index.xml#fnref:3">↩︎</a></p>
3306. </li>
3307. <li id="fn:4">
3308. <p>GNOME Terminal is being ported to GTK 4 for GNOME 47, but in GNOME 46 it is still a GTK 3 application. <a class="footnote-backref" href="https://bxt.rs/tags/planet-gnome/index.xml#fnref:4">↩︎</a></p>
3309. </li>
3310. <li id="fn:5">
3311. <p>To avoid the link-under-cursor detection logic skewing the results. <a class="footnote-backref" href="https://bxt.rs/tags/planet-gnome/index.xml#fnref:5">↩︎</a></p>
3312. </li>
3313. </ol>
3314. </div></div>
3315.    </summary>
3316.    <updated>2024-04-06T08:00:00Z</updated>
3317.    <published>2024-04-06T08:00:00Z</published>
3318.    <source>
3319.      <id>https://bxt.rs/tags/planet-gnome/</id>
3320.      <author>
3321.        <name>Ivan Molodetskikh</name>
3322.      </author>
3323.      <link href="https://bxt.rs/tags/planet-gnome/" rel="alternate" type="text/html"/>
3324.      <link href="https://bxt.rs/tags/planet-gnome/index.xml" rel="self" type="application/rss+xml"/>
3325.      <subtitle>Recent content in planet-gnome on Ivan Molodetskikh’s Webpage</subtitle>
3326.      <title>planet-gnome on Ivan Molodetskikh’s Webpage</title>
3327.      <updated>2024-04-06T08:00:00Z</updated>
3328.    </source>
3329.  </entry>
3330.  
3331.  <entry xml:lang="en-US">
3332.    <id>https://blogs.gnome.org/hughsie/?p=9820</id>
3333.    <link href="https://blogs.gnome.org/hughsie/2024/04/03/fwupd-and-xz-metadata/" rel="alternate" type="text/html"/>
3334.    <title>fwupd and xz metadata</title>
3335.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A few people (and multi-billion dollar companies!) have asked for my response to the xz backdoor. The fwupd metadata that millions of people download every day is a 9.5MB XML file — which thankfully is very compressible. This used to be compressed as gzip by the LVFS, making it a 1.6MB download for end-users, but … <a class="more-link" href="https://blogs.gnome.org/hughsie/2024/04/03/fwupd-and-xz-metadata/">Continue reading <span class="screen-reader-text">fwupd and xz metadata</span></a></div>
3336.    </summary>
3337.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>A few people (and multi-billion dollar companies!) have asked for my response to the <a href="https://en.wikipedia.org/wiki/XZ_Utils_backdoor">xz backdoor</a>. The fwupd metadata that millions of people download every day is a 9.5MB XML file — which thankfully is very compressible. This used to be compressed as gzip by the LVFS, making it a 1.6MB download for end-users, but in 2021 we switched to xz compression instead.</p>
3338. <p>What actually happens behind the scenes is that the libxmlb library <a href="https://github.com/hughsie/libxmlb?tab=readme-ov-file#introduction">loads the optionally compressed metadata into a mmap-able binary blob</a>, and then it gets used by fwupd to look for new updates for specific hardware. In libxmlb 0.3.3 we added support for xz as a compression format. Then fwupd 1.8.7 was released with xz support, preferring the xz format to the “legacy” gz format — as the metadata became a 1.1MB download, saving significant amounts of data from the CDN.</p>
3339. <p>Then this week we learned that xz wasn’t the kind of thing we want to depend on. Out of an abundance of caution (and to be clear — my understanding is there is no fwupd or LVFS security problem of any kind) I’ve switched the LVFS <a href="https://gitlab.com/fwupd/lvfs-website/-/commit/79709d7e899ae499232b49631be89da66757e8c6">to also generate zstd metadata</a>, make libxmlb <a href="https://github.com/hughsie/libxmlb/pull/160/commits/bdf845510fbed40b88465b2272ccad9e93656639">no longer hard depend on lzma</a> and switched fwupd to <a href="https://github.com/fwupd/fwupd/pull/7013">prefer the zstd metadata over the xz metadata</a> if the installed version of libjcat supports it. The zstd metadata is also ~3% smaller than xz (and faster to decompress), but the real benefit is that I now trust it a lot more than xz.</p>
3340. <p>I’ll be doing new libxmlb and fwupd releases with the needed changes next week.</p></div>
3341.    </content>
3342.    <updated>2024-04-03T08:39:01Z</updated>
3343.    <published>2024-04-03T08:39:01Z</published>
3344.    <category term="Uncategorized"/>
3345.    <author>
3346.      <name>hughsie</name>
3347.    </author>
3348.    <source>
3349.      <id>https://blogs.gnome.org/hughsie</id>
3350.      <link href="https://blogs.gnome.org/hughsie/feed/" rel="self" type="application/rss+xml"/>
3351.      <link href="https://blogs.gnome.org/hughsie" rel="alternate" type="text/html"/>
3352.      <subtitle>Blog about geeky stuff</subtitle>
3353.      <title>Technical Blog of Richard Hughes</title>
3354.      <updated>2024-04-03T08:39:01Z</updated>
3355.    </source>
3356.  </entry>
3357.  
3358.  <entry xml:lang="en-US">
3359.    <id>https://blogs.gnome.org/uraeus/?p=10890</id>
3360.    <link href="https://blogs.gnome.org/uraeus/2024/03/28/fedora-workstation-40-what-are-we-working-on/" rel="alternate" type="text/html"/>
3361.    <title>Fedora Workstation 40 – what are we working on</title>
3362.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">So Fedora Workstation 40 Beta has just come out so I thought I share a bit about some of the things we are working on for Fedora Workstation currently and also major changes coming in from the community. Flatpak Flatpaks … <a href="https://blogs.gnome.org/uraeus/2024/03/28/fedora-workstation-40-what-are-we-working-on/">Continue reading <span class="meta-nav">→</span></a></div>
3363.    </summary>
3364.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">So <a href="https://fedoramagazine.org/announcing-fedora-linux-40-beta/">Fedora Workstation 40 Beta has just come out</a> so I thought I share a bit about some of the things we are working on for Fedora Workstation currently and also major changes coming in from the community.<br/><br/>
3365. <strong>Flatpak</strong>
3366. <p>
3367. Flatpaks has been a key part of our strategy for desktop applications for a while now and we are working on a multitude of things to make Flatpaks an even stronger technology going forward.
3368. Christian Hergert is working on figuring out how applications that require system daemons will work with Flatpaks, using his own Sysprof project as the proof of concept application. The general idea here is to rely on the work that has happened in SystemD around sysext/confext/portablectl trying to figure out who we can get a system service installed from a Flatpak and the necessary bits wired up properly.
3369.  
3370. The other part of this work, figuring out how to give applications permissions that today is handled with udev rules, that is being worked on by Hubert Figuière based on earlier work by Georges Stavracas on behalf of the GNOME Foundation thanks to the sponsorship from the <a href="https://www.sovereigntechfund.de/">Sovereign Tech Fund</a>. So hopefully we will get both of these two important issues resolved soon.
3371.  
3372. Kalev Lember is working on polishing up the Flatpak support in Foreman (and Satellite) to ensure there are good tools for managing Flatpaks when you have a fleet of systems you manage, building on the work of Stephan Bergman.
3373.  
3374. Finally Jan Horak and Jan Grulich is working hard on polishing up the experience of using Firefox from a fully sandboxed Flatpak. This work is mainly about working with the upstream community to get some needed portals over the finish line and polish up some UI issues in Firefox, <a href="https://phabricator.services.mozilla.com/D202717">like this one</a>.
3375. </p>
3376. <strong>Toolbx</strong>
3377. <p>
3378. <a href="https://containertoolbx.org/">Toolbx</a>, our project for handling developer containers, is picking up pace with Debarshi Ray currently working on getting full NVIDIA binary driver support for the containers. One of our main goals for Toolbx atm is making it a great tool for AI development and thus getting the NVIDIA &amp; CUDA support squared of is critical.
3379.  
3380. Debarshi has also spent quite a lot of time cleaning up the Toolbx website, providing easier access to and updating the documentation there.
3381.  
3382. We are also moving to use the new <a href="https://gitlab.gnome.org/chergert/ptyxis">Ptyxis (formerly Prompt) terminal application</a> created by Christian Hergert, in Fedora Workstation 40. This both gives us a great GTK4 terminal, but we also believe we will be able to further integrate Toolbx and Ptyxis going forward, creating an even better user experience.
3383. </p>
3384.  
3385. <strong>Nova</strong>
3386. <p>
3387. So as you probably know, we have been the core maintainers of the Nouveau project for years, keeping this open source upstream NVIDIA GPU driver alive. We plan on keep doing that, but the opportunities offered by the availability of the new GSP firmware for NVIDIA hardware means we should now be able to offer a full featured and performant driver. But co-hosting both the old and the new way of doing things in the same upstream kernel driver has turned out to be counter productive, so we are now looking to split the driver in two. For older pre-GSP NVIDIA hardware we will keep the old Nouveau driver around as is. For GSP based hardware we are launching a new driver called <a href="https://gitlab.freedesktop.org/drm/nova">Nova</a>.
3388. It is important to note here that Nova is thus not a competitor to Nouveau, but a continuation of it.
3389.  
3390. The idea is that the new driver will be primarily written in Rust, based on work already done in the community, we are also evaluating if some of the existing Nouveau code should be copied into the new driver since we already spent quite a bit of time trying to integrate GSP there. Worst case scenario, if we can’t reuse code, we use the lessons learned from Nouveau with GSP to implement the support in Nova more quickly.
3391.  
3392. Contributing to this effort from our team at Red Hat is Danilo Krummrich, Dave Airlie, Lyude Paul, Abdiel Janulgue and Phillip Stanner.
3393. </p>
3394.  
3395. <strong>Explicit Sync and VRR</strong>
3396. <p>
3397. Another exciting development that has been a priority for us is <a href="https://www.x.org/wiki/Events/XDC2014/XDC2014PeltonenSynchronization/nvidia-explicit-synchronization.pdf">explicit sync</a>, which is critical for especially the NVidia driver, but which might also provide performance improvements for other GPU architectures going forward.
3398. So a big thank you to Michel Dänzer , Olivier Fourdan, Carlos Garnacho; and Nvidia folks, Simon Ser and the rest of community for working on this. This work has just finshed upstream so we will look at backporting it into Fedora Workstaton 40.
3399.  
3400. Another major Fedora Workstation 40 feature is experimental support for Variable Refresh Rate or VRR in GNOME Shell. The feature was mostly developed by community member Dor Askayo, but Jonas Ådahl, Michel Dänzer, Carlos Garnacho and Sebastian Wick have all contributed with code reviews and fixes. In Fedora Workstation 40 you need to enable it using the command
3401. </p><p>
3402. <code>gsettings set org.gnome.mutter experimental-features "['variable-refresh-rate']"</code>
3403. </p>
3404. <strong>PipeWire</strong>
3405. <p>
3406. Already covered PipeWire in my <a href="https://blogs.gnome.org/uraeus/2024/03/15/pipewire-camera-handling-is-now-happening/">post a week ago</a>, but to quickly summarize here too. Using PipeWire for video handling is now finally getting to the stage where it is actually happening, both Firefox and OBS Studio now comes with PipeWire support and hopefully we can also get Chromium and Chrome to start taking a serious look at merging the patches for this soon. Whats more Wim spent time fixing Firewire FFADO bugs, so hopefully for our pro-audio community users this makes their Firewire equipment fully usable and performant with PipeWire. Wim did point out when I spoke to him though that the FFADO drivers had obviously never had any other consumer than JACK, so when he tried to allow for more functionality the drivers quickly broke down, so Wim has limited the featureset of the PipeWire FFADO module to be an exact match of how these drivers where being used by JACK. If the upstream kernel maintainer is able to fix the issues found by Wim then we could look at providing a more full feature set. In Fedora Workstation 40 the de-duplication support for v4l vs libcamera devices should work as soon as we update Wireplumber to the new 0.5 release.
3407. </p>
3408. <p>
3409. To hear more about PipeWire and the latest developments be sure to check out this <a href="https://www.youtube.com/watch?v=_buKw1la_tg&amp;t=2393s">interview with Wim Taymans by the good folks over at Destination Linux.</a>
3410. </p>
3411.  
3412. <strong>Remote Desktop</strong>
3413. <p>
3414. Another major feature landing in Fedora Workstation 40 that Jonas Ådahl and Ray Strode has spent a lot of effort on is finalizing the remote desktop support for GNOME on Wayland. So there has been support for remote connections for already logged in sessions already, but with these updates you can do the login remotely too and thus the session do not need to be started already on the remote machine. This work will also enable 3rd party solutions to do remote logins on Wayland systems, so while I am not at liberty to mention names, be on the lookout for more 3rd party Wayland remoting software becoming available this year.
3415. </p>
3416. <p>
3417. This work is also important to help Anaconda with its Wayland transition as remote graphical install is an important feature there. So what you should see there is Anaconda using GNOME Kiosk mode and the GNOME remote support to handle this going forward and thus enabling Wayland native Anaconda.
3418. </p>
3419. <strong>HDR</strong>
3420. <p>
3421. Another feature we been working on for a long time is HDR, or High Dynamic Range. We wanted to do it properly and also needed to work with a wide range of partners in the industry to make this happen. So over the last year we been contributing to improve various standards around color handling and acceleration to prepare the ground, work on and contribute to key libraries needed to for instance gather the needed information from GPUs and screens. Things are coming together now and Jonas Ådahl and Sebastian Wick are now going to focus on getting Mutter HDR capable, once that work is done we are by no means finished, but it should put us close to at least be able to start running some simple usecases (like some fullscreen applications) while we work out the finer points to get great support for running SDR and HDR applications side by side for instance.
3422. </p>
3423.  
3424. <strong>PyTorch</strong>
3425. <p>
3426. We want to make Fedora Workstation a great place to do AI development and testing. First step in that effort is packaging up PyTorch and making sure it can have working hardware acceleration out of the box. Tom Rix has been leading that effort on our end and you will see the first fruits of that labor in Fedora Workstation 40 where PyTorch should work with GPU acceleration on AMD hardware (ROCm) out of the box. We hope and expect to be able to provide the same for NVIDIA and Intel graphics eventually too, but this is definitely a step by step effort.</p></div>
3427.    </content>
3428.    <updated>2024-03-28T18:56:33Z</updated>
3429.    <published>2024-03-28T18:56:33Z</published>
3430.    <category term="Fedora"/>
3431.    <category term="General"/>
3432.    <category term="GNOME"/>
3433.    <category term="PipeWire"/>
3434.    <author>
3435.      <name>uraeus</name>
3436.    </author>
3437.    <source>
3438.      <id>https://blogs.gnome.org/uraeus</id>
3439.      <link href="https://blogs.gnome.org/uraeus/feed/" rel="self" type="application/rss+xml"/>
3440.      <link href="https://blogs.gnome.org/uraeus" rel="alternate" type="text/html"/>
3441.      <subtitle>Blog talking about Fedora, GNOME, GStreamer and related topics. Anything I write in this blog is me speaking as a member of the open source community, official Red Hat communication happens on Redhat.com. The comments are my own personal opinion.</subtitle>
3442.      <title>Christian F.K. Schaller</title>
3443.      <updated>2024-03-28T21:56:05Z</updated>
3444.    </source>
3445.  </entry>
3446.  
3447.  <entry xml:lang="en-US">
3448.    <id>https://blog.jwf.io/?p=2866</id>
3449.    <link href="https://blog.jwf.io/2024/03/win-win-for-all-outreachy/" rel="alternate" type="text/html"/>
3450.    <title>Win-win for all: How to run a non-engineering Outreachy internship</title>
3451.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The post <a href="https://blog.jwf.io/2024/03/win-win-for-all-outreachy/">Win-win for all: How to run a non-engineering Outreachy internship</a> appeared first on <a href="https://blog.jwf.io">/home/jwf/</a>.</p>
3452. <p><a href="https://blog.jwf.io">/home/jwf/ - Free &amp; Open Source, technology, travel, and life reflections</a></p>
3453. <p>This year, I am mentoring again with the Outreachy internship program. It is my third time mentoring for Outreachy and my second time with the Fedora Project. However, it is my first time mentoring as a Red Hat associate. What also makes this time different from before is that I</p></div>
3454.    </summary>
3455.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The post <a href="https://blog.jwf.io/2024/03/win-win-for-all-outreachy/">Win-win for all: How to run a non-engineering Outreachy internship</a> appeared first on <a href="https://blog.jwf.io">/home/jwf/</a>.</p>
3456. <p><a href="https://blog.jwf.io">/home/jwf/ - Free &amp; Open Source, technology, travel, and life reflections</a></p>
3457.  
3458. <p>This year, I am mentoring again with the <a href="https://www.outreachy.org/" rel="noreferrer noopener" target="_blank">Outreachy internship program</a>. It is my third time mentoring for Outreachy and my second time with the <a href="https://blog.jwf.io/category/fedora/">Fedora Project</a>. However, it is my first time mentoring as a <a href="https://blog.jwf.io/category/red-hat/">Red Hat</a> associate. What also makes this time different from before is that I am mentoring a non-engineering project with Outreachy. Or in other words, my project does not <em>require</em> an applicant to write any code. Evidently, the internship description was a hook. We received an extremely large wave of applicants literally overnight. Between 40-50 new contributors arrived to the Fedora Marketing Team in the first week. Planning tasks and contributions for beginners already took effort. Scaling that planning work overnight for up to 50 people simultaneously is extraordinarily difficult.</p>
3459.  
3460.  
3461.  
3462. <p>During this round, my co-mentor <a href="https://fedoraproject.org/wiki/User:Joseph" rel="noreferrer noopener" target="_blank">Joseph Gayoso</a> and I experimented with new approaches at handling the tsunami wave. There are two competing forces at play. One, you need to provide engagement to top performers so they remain motivated to continue. Two, you need to provide new opportunities for emerging contributors to distinguish themselves. It is easier to do one of these but hard to do both simultaneously. However, Joseph and I agreed on something important. We agreed that all applicants should end the contribution phase with something practically useful. As mentors, we asked ourselves how to prepare applicants to be successful open source contributors beyond this one month.</p>
3463.  
3464.  
3465.  
3466. <p>In this article, you will get some practical takeaways for mentoring with Outreachy. First, I will share our practical approach for structuring and planning an open source project during the Outreachy contribution phase. Second, I will detail the guiding philosophy Joseph and I follow for how we planned the contribution phase.</p>
3467.  
3468.  
3469.  
3470. <span id="more-2866"/>
3471.  
3472.  
3473. <h2 class="wp-block-heading" id="about-outreachy">About Outreachy</h2>
3474.  
3475.  
3476. <p>This article assumes you already know a thing or two about the Outreachy internship program. If not, Outreachy provides internships in open source and open science. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they live. You can read more <a href="https://www.outreachy.org/" rel="noreferrer noopener" target="_blank">on the Outreachy website</a>.</p>
3477.  
3478.  
3479.  
3480. <p>What makes Outreachy unique is that the internships are remote and often open without geographic or nationality constraints. Applicants from nearly every continent of the world have participated in Outreachy. Also, Outreachy is distinguished by the <strong>contribution phase</strong>. For a one-month period, approved Outreachy applicants are encouraged to participate in the project community as a contributor. Applicants spend the month learning about the project, the community, the mentors, and the work involved for the internship. This provides applicants an opportunity to grow their open source identity. It also gives mentors an opportunity to assess applicants on their skills and communication abilities.</p>
3481.  
3482.  
3483.  
3484. <p>However, this contribution phase can be intimidating as a mentor, especially if you are new to mentoring with Outreachy. A wave of people eager to contribute could suddenly appear overnight at your project’s door steps. If you are not prepared, you will have to adapt quickly!</p>
3485.  
3486.  
3487. <h2 class="wp-block-heading" id="prerequisite-tasks-raising-the-outreachy-bar">Pre-Requisite Tasks: Raising the Outreachy bar</h2>
3488.  
3489.  
3490. <p>My co-mentor and I knew that a wave of applicants was coming. However, we didn’t expect the wave to be as big as it was. After the first week of the contribution phase, we knew we needed a better way to scale ourselves. We were limited in our person-power. The approach we took to addressing the mental overload was defining pre-requisite tasks.</p>
3491.  
3492.  
3493.  
3494. <p>We defined <strong>pre-requisite tasks</strong> as tasks that any applicant <em>MUST</em> complete in order to be considered eligible for our internship. Without completing these tasks, we explained that final applications would <em>not</em> be accepted by mentors. The defining characteristics of these pre-requisite tasks were that they were personalized, repeatable, and measurable. We came up with five pre-requisite tasks that all applicants were required to complete beyond the initial qualification for Outreachy:</p>
3495.  
3496.  
3497.  
3498. <ol>
3499. <li><a href="https://gitlab.com/fedora/marketing/marketing-planning/-/issues/153" rel="noreferrer noopener" target="_blank">Set up your Fedora Account System (FAS) account</a></li>
3500.  
3501.  
3502.  
3503. <li><a href="https://gitlab.com/fedora/marketing/marketing-planning/-/issues/154" rel="noreferrer noopener" target="_blank">Set up a personal blog</a></li>
3504.  
3505.  
3506.  
3507. <li><a href="https://gitlab.com/fedora/marketing/marketing-planning/-/issues/155" rel="noreferrer noopener" target="_blank">Write a blog post that introduces the Fedora community to your audience</a></li>
3508.  
3509.  
3510.  
3511. <li><a href="https://gitlab.com/fedora/marketing/marketing-planning/-/issues/156" rel="noreferrer noopener" target="_blank">Promote your intro blog post on social media</a></li>
3512.  
3513.  
3514.  
3515. <li><a href="https://gitlab.com/fedora/marketing/marketing-planning/-/issues/157" rel="noreferrer noopener" target="_blank">Write an onboarding guide for Outreachy 2025 applicants</a></li>
3516. </ol>
3517.  
3518.  
3519. <h3 class="wp-block-heading" id="how-were-initial-contributions-personalized">How were initial contributions personalized?</h3>
3520.  
3521.  
3522. <p>Each of these tasks were personalized to each applicant. They each have a unique account profile, with their pictures, time zones, and chat system usernames. The personal blog is a personal space on the Internet for each applicant to start writing new posts. The blog post prompts encouraged applicants to start filling up their blogs with Fedora content. The social media post helped applicants promote themselves as budding open source enthusiasts in their existing web spaces.</p>
3523.  
3524.  
3525.  
3526. <p>This approach had two benefits. First, it provided clear guidance to all newcomers and early-stage applicants on how to get started with contributing to Fedora for the Outreachy internship. This took a burden off of mentors answering the same questions about getting started. It also gave new applicants something to start on right away. Joseph and I were able to put more time into reviewing incoming contributions and brainstorming new tasks.</p>
3527.  
3528.  
3529. <h2 class="wp-block-heading" id="portfoliodriven-submissions-for-outreachy">Portfolio-driven submissions for Outreachy</h2>
3530.  
3531.  
3532. <p>Toward the third week, many applicants had completed the pre-requisite tasks and were ready for more advanced tasks. Many had already taken on advanced projects already, beyond the pre-requisite tasks. Although the pre-requisite tasks did reduce the applicant pool, there were still between 20-30 people who completed them all. Again, the approach had to adapt as our ability to keep up with new contributions slowed down.</p>
3533.  
3534.  
3535.  
3536. <p>From here, we encouraged applicants to build personal portfolio pages that described their contributions with Fedora. This encouraged applicants to use the blog they built in the previous tasks, although they are not required to use their blog to host their portfolio. The only requirement we added was that it should be publicly visible on the Internet without a paywall. So, no Google Docs. Most applicants have ended up using their blog for this purpose though.</p>
3537.  
3538.  
3539. <h3 class="wp-block-heading" id="how-did-a-portfolio-help">How did a portfolio help?</h3>
3540.  
3541.  
3542. <p>Building a portfolio solved multiple challenges for our Outreachy project at once. First, the portfolios will simplify how the project mentors review final applications after the deadline on April 2nd, 2024. It will be streamlined because we will have a single place we can refer to that describes the applicant’s achievements. It gives us a quick, easily shareable place to review and share with other stakeholders.</p>
3543.  
3544.  
3545.  
3546. <p>Second, it ends up being something useful to the applicant as well. The portfolio page captures a month’s worth of contributions to open source. For many applicants, this is their first time ever interacting with an open source community online. So, it is a big deal to block out a month of time to volunteer on a project in a competitive environment for a paid, remote internship opportunity. Writing a portfolio page gives applicants the confidence to represent their contributions to Fedora, regardless of whether they are selected for the Fedora internship. It becomes a milestone marker for themselves and for their professional careers.</p>
3547.  
3548.  
3549. <h2 class="wp-block-heading" id="our-philosophy-you-win-we-win">Our philosophy: You win, we win.</h2>
3550.  
3551.  
3552. <p>This idea of applicants building something that is useful for themselves underpins the approach that Joseph and I took on structuring our non-engineering Outreachy internship. If I had to summarize the philosophy in one sentence, it might be like this:</p>
3553.  
3554.  
3555.  
3556. <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
3557. <p>Everyone who participants as an Outreachy applicant to Fedora should finish the contribution phase with more than they had at the start of the contribution phase.</p>
3558. <cite>myself</cite></blockquote>
3559.  
3560.  
3561.  
3562. <p>Our philosophy can be applied to engineering and non-engineering internships. However, applying the philosophy to our non-engineering project required improvisation as we went. There are examples of design-centered Outreachy internships, but I have not seen a marketing or community manager internship before. This was a challenge because there were not great models to follow. But it also left us room to innovate and try ideas that we have never tried before.</p>
3563.  
3564.  
3565.  
3566. <p>Adopting this philosophy served as helpful guidance on planning what we directed applicants to do during the contribution phase. It allowed us to think through ways that applicants could make real, recognizable contributions to Fedora. It also enables applicants to achieve a few important outcomes:</p>
3567.  
3568.  
3569.  
3570. <ol>
3571. <li>Get real experience in a real project.</li>
3572.  
3573.  
3574.  
3575. <li>Build their own brand as open source contributors.</li>
3576.  
3577.  
3578.  
3579. <li>Gain confidence at collaborating in a community.</li>
3580. </ol>
3581.  
3582.  
3583.  
3584. <p>The contribution phase is not yet over. So, we will continue to follow this philosophy and see where it guides us into the end of this phase!</p>
3585.  
3586.  
3587. <h2 class="wp-block-heading" id="share-your-outreachy-mentoring-experience">Share your Outreachy mentoring experience!</h2>
3588.  
3589.  
3590. <p>Have you experienced or seen a marketing or community manager internship in Outreachy before? Know a project or a person who has done this? Or is this totally new to you? Drop a comment below with your thoughts. Don’t forget to share with someone else if you found this advice useful.</p></div>
3591.    </content>
3592.    <updated>2024-03-28T08:00:00Z</updated>
3593.    <published>2024-03-28T08:00:00Z</published>
3594.    <category term="Fedora Linux"/>
3595.    <category term="Open Source"/>
3596.    <category term="Red Hat"/>
3597.    <category term="community management"/>
3598.    <category term="Fedora Diversity Equity &amp; Inclusion"/>
3599.    <category term="Fedora Marketing"/>
3600.    <category term="Fedora Planet"/>
3601.    <category term="internship"/>
3602.    <category term="open source"/>
3603.    <category term="open source communities"/>
3604.    <author>
3605.      <name>Justin W. Flory</name>
3606.    </author>
3607.    <source>
3608.      <id>https://blog.jwf.io/tag/fedora-planet/</id>
3609.      <logo>https://i0.wp.com/blog.jwf.io/wp-content/uploads/2023/08/favicon.png?fit=16%2C16&amp;ssl=1</logo>
3610.      <link href="https://blog.jwf.io/tag/fedora-planet/feed/" rel="self" type="application/rss+xml"/>
3611.      <link href="https://blog.jwf.io/tag/fedora-planet/" rel="alternate" type="text/html"/>
3612.      <subtitle>Free &amp; Open Source, technology, travel, and life reflections</subtitle>
3613.      <title>Fedora Planet Archives – /home/jwf/</title>
3614.      <updated>2024-05-02T13:05:13Z</updated>
3615.    </source>
3616.  </entry>
3617.  
3618.  <entry xml:lang="en-US">
3619.    <id>https://blogs.gnome.org/alatiera/?p=5107</id>
3620.    <link href="https://blogs.gnome.org/alatiera/2024/03/26/thoughts-on-employing-pgo-and-bolt-on-the-gnome-stack/" rel="alternate" type="text/html"/>
3621.    <title>Thoughts on employing PGO and BOLT on the GNOME stack</title>
3622.    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Christian was looking at PGO and BOLT recently I figured I’d write down my notes from the discussions we had on how we’d go about making things faster on our stack, since I don’t have time or the resource to pursue those plans myself atm. First off let’s start with the basics, PGO (profile guided … <a class="more-link" href="https://blogs.gnome.org/alatiera/2024/03/26/thoughts-on-employing-pgo-and-bolt-on-the-gnome-stack/">Continue reading <span class="screen-reader-text">Thoughts on employing PGO and BOLT on the GNOME stack</span></a></div>
3623.    </summary>
3624.    <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Christian was looking at PGO and BOLT <a href="https://blogs.gnome.org/chergert/2024/03/21/bolting-libraries/">recently</a> I figured I’d write down my notes from the discussions we had on how we’d go about making things faster on our stack, since I don’t have time or the resource to pursue those plans myself atm.<br/><br/>First off let’s start with the basics, PGO (profile guided optimizations) and BOLT (Binary Optimization and Layout Tool) work in similar ways. You capture one or more “profiles” of a workload that’s representative of a usecase of your code and then the tools do their magic to make the common hot paths more efficient/cache-friendly/etc. Afterwards they produce a new binary that is hopefully faster than the old one and functionally identical so you can just replace it.<br/><br/>Now already we have two issues here that arise here:<br/><br/>First of all we don’t really have any benchmarks in our stack, let alone, ones that are rounded enough to account for the majority of usecases. Additionally we need better instrumentation to capture stats like frames, frame-times, and export them both for sysprof and so we can make the benchmark runners more useful.<br/><br/>Once we have the benchmarks we can use them to create the profiles for optimizations and to verify that any changes have the desired effect. We will need multiple profiles of all the different hardware/software configurations. <br/><br/>For example for GTK ideally we’d want to have a matrix of profiles for the different render backends (NGL/Vulkan) along with the mesa drivers they’d use depending on different hardware AMD/Intel and then also different architectures, so additional profile for Raspberrypi5 and Asahi stacks. We might also want to add a profile captured under qemu+virtio while we are it too.<br/><br/>Maintaining the benchmarks and profiles would be a lot of work and very tailored to each project so they would all have to live in their upstream repositories. <br/><br/>On the other hand, the optimization itself has to be done during the Tree/userland/OS composition and we’d have to aggregate all the profiles from all the projects to apply them. This is easily done when you are in control of the whole deployment as we can do for the GNOME Flatpak Runtime. It’s also easy to do if you are targeting an embedded deployment where most of the time you have custom images you are in full control off and know exactly the workload you will be running.<br/><br/>If we want distros to also apply these optimizations and for this to be done at scale, we’d have to make the whole process automatic and part of the usual compilation process so there would be no room for error during integration. The downside of this would be that we’d have a lot less opportunities for aggregating different usecases/profiles as projects would either have to own optimizations of the stack beneath them (ex: GTK being the one relinking pango) or only relink their own libraries.<br/><br/>To conclude, Post-linktime optimization would be a great avenue to explore as it seems to be one of the lower-hanging fruits when it comes to optimizing the whole stack. But it also would be quite the effort and require a decent amount of work to be committed to it. It would be worth it in the long run.</p></div>
3625.    </content>
3626.    <updated>2024-03-26T15:42:51Z</updated>
3627.    <published>2024-03-26T15:42:51Z</published>
3628.    <author>
3629.      <name>Jordan Petridis</name>
3630.    </author>
3631.    <source>
3632.      <id>https://blogs.gnome.org/alatiera</id>
3633.      <link href="https://blogs.gnome.org/alatiera/feed/" rel="self" type="application/rss+xml"/>
3634.      <link href="https://blogs.gnome.org/alatiera" rel="alternate" type="text/html"/>
3635.      <subtitle>Just another GNOME Blogs site</subtitle>
3636.      <title>Rust in Peace</title>
3637.      <updated>2024-03-26T15:42:51Z</updated>
3638.    </source>
3639.  </entry>
3640. </feed>
3641.