You are here

Planet GNOME

Subscribe to Feed Planet GNOME
Planet GNOME -
Përditësimi: 4 ditë 13 orë më parë

Cassidy James Blaede: Use Commit from Flatpak Both Inside and Outside of Toolbx

Hën, 09/10/2023 - 2:00pd

This one’s gonna be a short one, and is mostly for my own notes. :)

I like to use the Commit app as a visual editor when committing changes to a git repo; it’s a simple dialog that gives some niceties over using the CLI, like spell check, a visual indication of line length, graying out comments, etc. It’s nice!

Here are the instructions provided by Commit to edit your git config:

git config --global core.editor "flatpak run re.sonny.Commit"

Since I’m often in a toolbx container when developing, I can’t directly access my host’s Flatpaks (which makes sense!), and thus the provided instructions don’t work in this context.

Update: Just Install Flatpak in the Toolbx Container!

Thanks to Felipe and Sebastian in the comments, I learned Flatpak inside a toolbx container is actually smart, and will launch host Flatpaks on the host! So all you actually need to do is:

sudo dnf install flatpak

…or your toolbx container distro’s equivalent, then the instructions provided by Commit should Just Work™️.

If you get an error about unpacking rpm package flatpak, you may be on an older version of toolbx and need to work around a bug; just sudo umount /var/lib/flatpak, then install Flatpak, then restart your container exit it, then podman stop fedora-toolbox-39 (or your container name), then toolbox enter fedora-toolbox-39 (or your container name) again.

Edit the Git Config (Outdated!)

Note: The above update should be all you need; the previous contents of this post are included here for posterity and to show the learning process, in case that’s still useful to anyone.

I could modify my git config to work in the container by using flatpak-spawn (which, despite its name, you can use to spawn things outside of toolbx containers as well as outside of flatpaks), but then it won’t work on the host, which I also need! So I have to dynamically handle both cases…

After a bit of trial and error, I came up with this kludge:

git config --global core.editor 'if [ -f /run/.toolboxenv ]; then prefix="flatpak-spawn --host"; fi && $prefix flatpak run re.sonny.Commit'

If all you wanted was for this to work for you, copy the above and you’re done. :)

How it works

Let’s step through it to better understand what’s going on. I’m going to break it into lines to make it easier to read; I know this can’t be parsed as-is by bash, but just bear with the visual:

git config --global core.editor ' if [ -f /run/.toolboxenv ]; then prefix=" flatpak-spawn --host "; fi && $prefix flatpak run re.sonny.Commit '

So the outer-most part is that we’re setting the core.editor variable globally with git config, just as Commit’s original instructions say. We’re using single-quotes (') here because we don’t want our $prefix to be interpreted as string replacement at the time we set the variable, which double-quotes (") would do; we just want to include that in the literal string (to be replaced when git runs it).

Next we have an if to check if the file /run/.toolboxenv exists; this exists in all toolbx containers, so it’s an easy way to know if we’re running in toolbx.

If we’re in toolbx, we set a new variable prefix to flatpak-spawn --host since we need to run the actual editor on the host, not in our container. We use double-quotes (") here since we’re inside of the single-quoted (') string.

After we successfully do the toolbx check and optionally set the prefix, && will tell the shell that’s calling the commit program to execute the next bit.

We include the actual original flatpak run re.sonny.Commit, this time prefixed by $prefix, which will either be string-replaced by a harmless empty string, or by our flatpak-spawn --host if we’re in a toolbx container.

We have to leave the command for the end of our kludged string because git will append the temporary filename of the commit message to the end of the whole core.editor string; if we included flatpak-span --host flatpak run re.sonny.Commit inside the if statement, it would never get the name of the file to edit, and wouldn’t work (ask me how I know…).

So there we are. It’s super ugly, but hey, it works. How would you solve this in a better way? Let me know on social media. :)

Jakub Steiner: GNOME 45 Wallpapers

Enj, 05/10/2023 - 12:00pd

With the 45 release out the door, it would be a shame not to reveal some of the behind the scenes for the new wallpapers.

I’ll start off by mentioning a lovely new addition by David Lapshin, Amber, leaning into Inkscape’s mesh gradients.

The default has shown no dramatic departure from the triangles/hexagons of the previous releases. The on-brand triangle theme has been kept, but the implementation is very different. The wallpaper is a result of a generated mesh using Blender’s geometry nodes and color gradients derived from a pre-existing wallpaper texture. You can check the whole thing out in the provided blender project files in wallpaper-assets.

There have been updates to the existing set, the surprisingly popular Blobs have been tweaked, my personal favorite, Fold crops a bit better at the most common 16:9 aspect and Truchet is round yet again. Pixels have been updated to feature Circle apps.

Weirdly named Morphogenesis is one of my favorite additions this release. Based around a concept of reactive diffusion, described by none other than Allan Turing, features a little easter egg if you’re into chasing those down.

Previously, Previously, Previously, Previously

António Fernandes: My second (full) GUADEC

Mër, 04/10/2023 - 2:03md
Back to GUADEC

Four years after my first attendance of GUADEC, in Thessaloniki, I was fortunate enough to once again attend, in-person, the main GNOME conference, which was hosted this year in the enchanting city of Riga.

These were four long years! Alright, I’ve watched the online editions of 2020 and 2021, but that doesn’t count. Honorary mention to the Berlin “mini-GUADEC” in 2022, which was de facto a satellite venue and which I was very glad to attend in-person. It did have some of the GUADEC spirit and that was where I first met a lot of faces who I was very happy to see again this year.

Travelling from the diametrically opposite corner of Europe, and constrained by the number of PTO days I could to allocate, I couldn’t avoid air travel, but I’ve at least managed to replace one airplane connection with a high speed train travel.

My First Talk

While contributing to nautilus, I often find myself doing code archaeology, i.e., looking into past revisions to make better decisions and avoid past mistakes. But there is also the fun of looking at how different things were 20 years ago. Last year, when I blogged about some of these findings, I was surprised by the  public feedback, both nostalgia from people who remembered that, and surprise from people who had never seen it.

That was when I realized it could be a good idea to share more such content as a presentation for GUADEC 2022. I even drafted the talk proposal, but in the end didn’t submit it because I was busy with life, the GTK 4 port, and 2 GSOC interns. So, this year I decided to go ahead and I was very happy to be accepted as a speaker for GUADEC 2023!

The original intention was to have other nautilus contributors join me to speak about on-going developments and future plans, while I focused on the history of nautilus only. But I was the only one who could make it to Riga, so I ended up taking up the stage alone to talk about past, present and future. I must admit I became a little nervous the 5 minutes before the talk!

But it went great. The room was full and I enjoyed seeing people react to both screenshots from the past and demos of new enhancements coming  in the room. The questions from the public after the presentation were very relevant and made for a great discussion. I was very happy to share how healthy and fun the project is right now.

The hallway (and canteen)

GUADEC is not just the public talks. It’s also having GNOME contributors bump into each other and get productive results from these collisions. I had very fruitful conversations during coffee and lunch breaks.

Once at lunch, I was sitting on the table with just the right people to clarify some questions regarding Files search: Carlos and Sam, from tracker team, and Allan, from the design team.

I even got dragged into a guerrilla usability testing by the design team, for the new workspace indicator.


Social events

In the first day, I joined the Latvia Old City Center guided tour, which I loved, despite the rain at the end! I was very lucky it was rescheduled from the last day, when I wouldn’t be able to join.

Besides the official social events, as usual in GUADEC, it’s easy to organize and join informal activities. I had great conversations in bars while metting or getting closer to more fellow contributors. Building these bounds and trust makes collaboration so much easier and enjoyable!

I almost skipped the beach evening. But fortunately changed my mind just in time to catch the train to Jürmala with a amazing group.


Final words

I cannot finish without praising the local organizing team, for the venue was great and everything went smoothly for me as a speaker and attendee. I’m also very thankful to the GNOME Foundation for sponsoring my travel and lodging. Last but not least, I send cheers to Pedro Sader Azevedo, who was my roommate at the hotel, and a very talented new contributor! I hope to join everyone again in a future GUADEC!


Christian Hergert: VTE performance improvements

Mër, 04/10/2023 - 12:53pd

To celebrate every new GNOME release I try to do a little bit of work that would be intrusive to land at the end of the cycle. The 46 cycle is no different and this time I’m making our terminals faster.

The terminal is surely the most used desktop app for developers and things have changed in drawing models over the years. There might be some excellent energy savings to be had! So I made myself a little prototype to see how much faster we might be able to go without drastic design changes and use that as my guide to improving VTE performance.

VTE has been around since the early days of GNOME. It’s been touched in some manner by many programmers that I consider more talented than myself, but perhaps I can improve things yet!

So far I’ve landed a little over a dozen patches, none of which address drawing (yet). So that means these patches will make both the GTK 3 and GTK 4 versions of VTE faster. Once the last patch lands in this category we will have cut wall clock time down for a number of common scenarios by a solid 40%. That’s a pretty good win!

After these land I have a bunch of patches which introduce native GTK 4 drawing primitives instead of Cairo. Those patches will ultimately reduce draw latency on GTK 4 while not regressing GTK 3 performance. There are still a couple things to figure out around some “minifont” usage, but things are looking good.

I’d also like to find a way to get draw timing driven by the frame clock rather than some internal timeouts. Combining that with the GTK 4 native drawing will certainly make things feel faster on the “butt dyno”.

Anyway, I probably won’t go down the rabbit hole with this, I just want to get things inline with performance expectations.

And to nobodies surprise, this is the type of stuff that is much easier to do when armed with Sysprof and working frame-pointers.

Christian Hergert: What have frame-pointers given us anyway

Mar, 03/10/2023 - 8:32md

I obsess over battery life. So having a working Sysprof in Fedora 39 with actually useful frame-pointers has been lovely. I heard it asked at an All Systems Go talk if having frame-pointers enabled has gained any large performance improvements and that probably deserves addressing.

The answer to that is quite simply yes. Sometimes it’s directly a side-effect of me and others sending performance patches (such as Shell search performance or systemd-oomd patches). Sometimes it just prevents the issues from showing up on peoples systems to begin with. Basically all the new code I write now is done in tandem with Sysprof to visualize how things ran. Misguided choices often stick out earlier.

I think it’s also important to recognize that in addition to gaining performance improvements we’ve not seen people complain about performance regressions. That means we can have visibility to improve things without a significant burden in exchange.

Here is a little gem that I would have been unlikely to find without system-wide frame-pointers. Basically API contract validation needs to do a couple lookups for flags on the TypeNode for GTypeInstance. I’ll remind the reader that GTypeInstance is what underlies GObject, GskRenderNode, and is likely to be our “performance escape hatch” from GObject.

Those checks, in particular for G_TYPE_IS_ABSTRACT() and G_TYPE_IS_DEPRECATED() were easily taking up nearly a percent of samples in some tight loop tests (like creating thousands of GTK render nodes). It turns out that both g_type_create_instance() and g_type_free_instance() were doing these checks. Additionally g_value_unset() on a GBoxed type can do this too (via g_boxed_free()). That gets used all the time for closure invocations such as through the g_signal_* API.

A quick peek with Sysprof, thanks to those frame-pointers, shows the common code paths which hit this. It looks like the flags for abstract and deprecated are stored on an accessory object for the TypeNode. This is a vestige of a day where we must have thought it prudent to be very tight about memory consumption in TypeNodes. But unfortunately, accessing that accessory data requires acquiring the read side of a GRWLock because the type system is mutable. As it were, there is space to cache these bits in the TypeNode directly and the patch linked above does just that.

Combining the above patch with this patch from Emmanuele does wonders for the g_type_create_instance() performance. It basically drops things down to the cost of your malloc() implementation, which is much more ideal.

All of this was only on my radar because I was fixing up a few performance issues in GTK’s OpenGL renderer. Getting extraneous TypeNode checks out of hot code paths and instead at consumer API boundaries instead is always a win for performance.

This is just one example of many. And thankfully, many more people are capable of casually improving performance rather than relying on someone like me thanks to Sysprof and frame-pointers on Fedora.

Ondřej Holý: Discovering SMB shares in GNOME

Mar, 03/10/2023 - 5:09md

Available SMB shares can be found using the Other Locations view in the Files application in addition to other network shares and devices that also appear there. This internally uses several backends and volume monitors provided by the GVfs project, as I explained in my previous blog post.

Just a note that there are plans to replace the Other Locations view with a Network view.

mDNS/DNS Service Discovery

Services that appear there are most likely published via the mDNS/DNS-SD protocols these days. The SAMBA shares on Linux systems are automatically published to the network via this protocol if the Avahi daemon is installed and running. It is also natively supported on Apple systems. The problem is with Windows systems. As far as I can tell, Windows still supports the mDNS protocol for resolving .local hostnames only, but shares are not automatically published or discovered. It is only supported by some third-party applications (e.g. from Apple).

SMB1/NetBIOS Service Discovery

The NetBIOS Service Discovery had been used for years to discover Windows shares. It is available over the SMB1 protocol, also called NT1 in the SAMBA project. Unfortunately, this protocol is now disabled by default because it is outdated and vulnerable. If I’m not mistaken, the latest Windows systems don’t even allow it to be enabled. This is why Windows shares are not available in the “Other Locations” view and why the Windows Network folder is empty in most cases.

Web Service Device Discovery

Windows systems rely primarily on the WS-Discovery protocol instead. It is quite easy to publish SMB shares from Linux to make them visible to Windows systems. There are wsdd and other similar projects for this purpose. But the discovery of these shares in Linux in general is not ideal. As far as I can tell, only the KDE environment provides graphical file managers that support this protocol. This is possible thanks to its implementation in the KIO extras project. GNOME doesn’t support it yet.

The big news is that I recently proposed a WS-Discovery backend for the GVfs project. It doesn’t implement the protocol itself, but uses the wsdd project’s API. There are still some small things that would be nice to improve, but I hope this will be part of GNOME 46 to make Windows shares visible again!