You are here

Planet GNOME

Subscribe to Feed Planet GNOME
Planet GNOME - https://planet.gnome.org/
Përditësimi: 16 orë 40 min më parë

Jan Lukas Gernert: Newsflash 3.1

Hën, 12/02/2024 - 9:55pd

(yes, you read that right: the ‘f’ is not capitalized anymore)

This release doesn’t introduce groundbreaking new functionality. But there are quite a few quality of life improvements worth checking out.

Marking all articles as read is now more predictable and can be undone. It takes into account if the article list is filtered by a search term or viewing only starred articles. Only those will get marked as read. If you still accidentally mark more articles as read than intended there is a grace period that allows you to undo your action.

Subscribing to a new feed used to add it to the sidebar. But no articles were fetched until the next sync. No longer: Newsflash will now fetch articles of that particular feed right after it was added.

Speaking of fetching articles for feeds: if a feed fails to download or parse for some reason it will now display an icon in the sidebar. This works for local RSS and all services that propagate their errors via their API.

My personal highlight in this release is the miniflux implementation supporting enclosures. This means more thumbnails and attachments for users if they run a recent version of miniflux (>= 2.0.49).

Other than that a few more smaller changes and bug fixes can be found in Newsflash 3.1

Get it on flathub

Bastien Nocera: New and old apps on Flathub

Pre, 09/02/2024 - 3:42md

3D Printing Slicers

 I recently replaced my Flashforge Adventurer 3 printer that I had been using for a few years as my first printer with a BambuLab X1 Carbon, wanting a printer that was not a “project” so I could focus on modelling and printing. It's an investment, but my partner convinced me that I was using the printer often enough to warrant it, and told me to look out for Black Friday sales, which I did.

The hardware-specific slicer, Bambu Studio, was available for Linux, but only as an AppImage, with many people reporting crashes on startup, non-working video live view, and other problems that the hardware maker tried to work-around by shipping separate AppImage variants for Ubuntu and Fedora.

After close to 150 patches to the upstream software (which, in hindsight, I could probably have avoided by compiling the C++ code with LLVM), I manage to “flatpak” the application and make it available on Flathub. It's reached 3k installs in about a month, which is quite a bit for a niche piece of software.

Note that if you click the “Donate” button on the Flathub page, it will take you a page where you can feed my transformed fossil fuel addiction buy filament for repairs and printing perfectly fitting everyday items, rather than bulk importing them from the other side of the planet.


 

Preparing a Game Gear consoliser shell

I will continue to maintain the FlashPrint slicer for FlashForge printers, installed by nearly 15k users, although I enabled automated updates now, and will not be updating the release notes, which required manual intervention.

FlashForge have unfortunately never answered my queries about making this distribution of their software official (and fixing the crash when using a VPN...).

 Rhythmbox

As I was updating the Rhythmbox Flatpak on Flathub, I realised that it just reached 250k installs, which puts the number of installations of those 3D printing slicers above into perspective.

 

The updated screenshot used on Flathub

Congratulations, and many thanks, to all the developers that keep on contributing to this very mature project, especially Jonathan Matthew who's been maintaining the app since 2008.

Martín Abente Lahaye: Gameeky released

Enj, 08/02/2024 - 2:33md

After three months of development, Gameeky reaches its first public release. This project is the result of nearly fifteen years of experience contributing to education projects and mentoring young learners.

I am happy to share it everyone!

Although this project can still be considered in early stages of development, it’s not far from being feature complete. This first release comes the following:

  • A game launcher to manage projects more easily.
  • A game client to play games cooperatively.
  • A scene editor to create and modify game worlds.
  • An entity editor to create and modify game objects.
  • A Python library for a LOGO-like experience.
  • Plugins support to extend the games logic and entities behavior.
  • An offline beginner’s guide.
  • The first thematic pack to create role-playing games in a medieval fantasy setting.
  • And more…

Gameeky is available in English and Spanish, including the beginner’s guide.

The recommended installation method is through GNOME Software from Flathub. Alternatively, it can also be installed  from the terminal:

flatpak --user install flathub dev.tchx84.Gameeky

The first thematic pack can also be installed from the terminal:

flatpak --user install flathub dev.tchx84.Gameeky.ThematicPack.FreedomValley

Moving forward, these are the next steps for Gameeky:

  • Improve the user experience and accessibility, e.g., supporting undo operations on the editors and allowing these editors to be fully usable with the keyboard.
  • Stress test the entities system, e.g., figuring out what else can’t be modeled with it and improve it without making it unnecessarily complex.
  • Address performance issues, e.g., optimizing the rendering pipeline and the communication protocol.
  • Create new thematic packs for different interests, e.g., robotics, sci-fi, urban cities, etc.
  • Produce more in-depth tutorials, e.g., videos to show how to create new thematic packs from scratch, an introductory course to Python built on Gameeky, etc.
  • Support more languages, e.g., providing translations of its user interface and beginner’s guide.
  • Other important miscellaneous tasks, e.g., designing a proper icon for the desktop.

To achieve some of these goals I plan to take Gameeky to its users, by organizing workshops and hackathons with students and teachers here in Paraguay.

If you know any organization or individual that might be interested in supporting these workshops financially or otherwise, please feel free to contact me.

Robert McQueen: Flathub: Pros and Cons of Direct Uploads

Mar, 06/02/2024 - 11:57pd

I attended FOSDEM last weekend and had the pleasure to participate in the Flathub / Flatpak BOF on Saturday. A lot of the session was used up by an extensive discussion about the merits (or not) of allowing direct uploads versus building everything centrally on Flathub’s infrastructure, and related concerns such as automated security/dependency scanning.

My original motivation behind the idea was essentially two things. The first was to offer a simpler way forward for applications that use language-specific build tools that resolve and retrieve their own dependencies from the internet. Flathub doesn’t allow network access during builds, and so a lot of manual work and additional tooling is currently needed (see Python and Electron Flatpak guides). And the second was to offer a maybe more familiar flow to developers from other platforms who would just build something and then run another command to upload it to the store, without having to learn the syntax of a new build tool. There were many valid concerns raised in the room, and I think on reflection that this is still worth doing, but might not be as valuable a way forward for Flathub as I had initially hoped.

Of course, for a proprietary application where Flathub never sees the source or where it’s built, whether that binary is uploaded to us or downloaded by us doesn’t change much. But for an FLOSS application, a direct upload driven by the developer causes a regression on a number of fronts. We’re not getting too hung up on the “malicious developer inserts evil code in the binary” case because Flathub already works on the model of verifying the developer and the user makes a decision to trust that app – we don’t review the source after all. But we do lose other things such as our infrastructure building on multiple architectures, and visibility on whether the build environment or upload credentials have been compromised unbeknownst to the developer.

There is now a manual review process for when apps change their metadata such as name, icon, license and permissions – which would apply to any direct uploads as well. It was suggested that if only heavily sandboxed apps (eg no direct filesystem access without proper use of portals) were permitted to make direct uploads, the impact of such concerns might be somewhat mitigated by the sandboxing.

However, it was also pointed out that my go-to example of “Electron app developers can upload to Flathub with one command” was also a bit of a fiction. At present, none of them would pass that stricter sandboxing requirement. Almost all Electron apps run old versions of Chromium with less complete portal support, needing sandbox escapes to function correctly, and Electron (and Chromium’s) sandboxing still needs additional tooling/downstream patching to run inside a Flatpak. Buh-boh.

I think for established projects who already ship their own binaries from their own centralised/trusted infrastructure, and for developers who have understandable sensitivities about binary integrity such such as encryption, password or financial tools, it’s a definite improvement that we’re able to set up direct uploads with such projects with less manual work. There are already quite a few applications – including verified ones – where the build recipe simply fetches a binary built elsewhere and unpacks it, and if this already done centrally by the developer, repeating the exercise on Flathub’s server adds little value.

However for the individual developer experience, I think we need to zoom out a bit and think about how to improve this from a tools and infrastructure perspective as we grow Flathub, and as we seek to raise funds for different sources for these improvements. I took notes for everything that was mentioned as a tooling limitation during the BOF, along with a few ideas about how we could improve things, and hope to share these soon as part of an RFP/RFI (Request For Proposals/Request for Information) process. We don’t have funding yet but if we have some prospective collaborators to help refine the scope and estimate the cost/effort, we can use this to go and pursue funding opportunities.