(A bit late) weekly update
Well, it’s a bit late for a weekly update that it should be rather called decadly update. But well, better than nothing!
WIP: Safety flag
Related:
- Backend: libxfce4util !16
- UI: Thunar !121
- Additional discussions: Thunar #156
I’m still working on safety-flag, which is mentioned in my introduction post and 2nd saturday post. Not much have changed, but now an interface for safety flag is going to be merged into libxfce4util. Also, this flag will now only be used for .desktop files, rather than every executables.
Also, the UI part of this project also got its MR page (Thunar !121). Several discussion later (startig from here), we decided to put checkbox for safety flag on Property->Launcher. Because flicking trusted flag on should also trigger executable flag on, it would be preferrable to show it visually. Thus toggle button for executable flag would also be on Launcher tab. So this would be how it will look like:
Additional update
Related: libxfce4ui !42 (42 is a nice number!)
While I was working on safety flag, I got distracted by the boilerplates used on several XFCE projects, which was a direct copy of thunar_gtk_label_set_a11y_relation(). To use this function across XFCE projects, I ported this to libxfce4ui as xfce_gtk_label_set_a11y_relation(). Doesn’t it feel good when duplicate codes are replaced with a proper function?
Weekly update – transfer queueing, execution safety flag, and MTP
Transfer queueing
After transfer queueing was introduced, it frequently caused crashes or freezing when working with remote location. This problem was solved by introducing a waiting queue. To be released in Thunar 4.17.4.
-
This patch will not be backported. If you have this problem with Thunar 4.16, it is recommended to set parallel transfer to “Always” to avoid this problem.
-
You might ask about how it was done before. How can a job can be queued when there is no queue? The answer is simple. Since every transfer job runs on a separate thread, it is possible to play a game of musical chairs. Every thread tries to be the only active thread, and if a thread fails to start, it waits until the next opportunity arises. This is easy to implement when parallel transfer is already implemented. But unfortunately, the game did not go well.
WIP: Introduction of an execution safety flag
(I recommend reading Thunar !156 for the context.)
Since the executable bit is not enough to confirm that the file is safe to execute, I am implementing an additional metadata (execution safety flag). Thunar will check this flag even if the execution bit is on, so a user has to confirm that they know that they are launching an executable. This data is contained in GVFS-metadata, and will remember SHA-256 hash value of that file. This will work as a per-file option to allow launching the executable.
I already finished coding a feature to save a hash value per-file and using it to verify executable, and will be added to libxfce4util soon. Interface with this safety flag is still work-in-progress, though.
WIP: MTP freeze
Recently, there are a lot of issue reports about MTP, and most of the complaints are about freeze. A directory under mtp:// that contains a lot of files tends to cause problems. One problem is that icon renderer reads file contents and might clog the main event loop, so I am experimenting with icon rendering right now. Trying to change directory while a directory is loading also freezes the environment, so requesting a file list of the current directory (or cancelling it) might be blocking for some reason.
Introduction
Hello and welcome to the first of a series of blog posts detailing my work in this year's Google Summer of Code (GSoC from now on). Most of you have probably found this page from one of Xfce's development channels, but for those of you who just happened to stumble upon it let me say a few quick words about Xfce. Xfce is a FOSS desktop environment for Unix-like systems. It has a dedicated community of developers and users and it is one of the most widely available DEs. It also happens to be the desktop environment that my/our department uses for its Linux systems.
Allow me to introduce myself, which is also the main point of this blog post. I am Sergios - Anestis Kefalidis and I am a 3rd year undergraduate student at the department of Informatics and Telecommunications of the University of Athens. This is my second year in GSoC and my first time contributing to Xfce. I've made significant contributions to another high profile open source project, MuseScore with whom I also completed my first GSoC project as you might have guessed.
This summer I will work on improving Thunar, Xfce's file manager. File managers are one of the most used system programs and the Xfce project considers Thunar one of its core components. A good file manager positively impacts the user experience and allows the user to achieve his/her file managing tasks intuitively and quickly. Thunar is a pretty decent file manager that is unfortunately missing some features that other widely used file managers support. I am aiming to bring the parts of Thunar that are lagging behind up to par with the rest of its rock-solid components. I've already made a significant amount of contributions in the previous months that improve various parts of Thunar, most notably the Trash folder. The time has come for even bigger improvements.
In the first month of GSoC I have planned to work on 2 things. Support for the `Recent` location (as seen in Nautilus, Dolphin, Windows' File Explorer and others) and support for saving zoom levels as a per-directory setting. I've already started working on these 2 features and the early results are more than encouraging (you can see and test the latest implementations by visiting the Thunar gitlab). I'll talk more about these things in the following weeks.
In the second month of GSoC I will work on improving Thunar's search functionality which is bare-bones and on implementing a missing part of freedesktop.org's thumbnail spec. More on both of those in the coming weeks.
As an ending note, I want to congratulate my fellow GSoC students Yongha and Vishal and wish them good luck. I am looking forward to working with all of you on improving Xfce :^)
GSOC 2021
Good news! I have been accepted to GSoC 2021. (Well, actually, it had been 3 weeks since it was announced, so I “was” accepted, to be exact.) I am contributing to XFCE this summer, so I will explain who I am, and what I am going to do.
First stop. So, who am I? My name is Yongha Hwang, and I am an Electronic Engineering sophomore. And that’s enough for personal information to do about contributing, so I’ll explain my experience with Linux, XFCE and C altogether.
I use Linux as my main OS. For developemnt, for surfing web, for entertainment like gaming, and everything else that happens after pressing power button. Although I use it as a main OS, I reinstall linux every 3~6 months. Since I don’t install the same thing everytime, I have used Ubuntu, Xubuntu, Linux Mint (both Cinnamon and MATE), Manjaro, Arch, Gentoo, and et cetra. I have even used Linux from Scratch (with LXQt) as a main OS.
My first experience with XFCE was Xubuntu in 2011. My first linux distribution was Ubuntu, as you have guessed. At that time Ubuntu was packed with Unity DE. It looked very futuristic to me since the only UI experience was with Windows XP and 98. But it did have one big problem to me: it was resource-heavy. The computer I was using at that time was quite slow and Internet Explorer took a whopping 12 seconds to show up. So I had to look for a lighter alternative and Xubuntu was a natural choice. Since then I liked how light DEs look like, so I use light DEs most of the time not because of my low-end PC, but because I like the visual of “nothing fancy but looks fine enough.”
I started programming in C about the time I started using Linux. I have not much to tell about C, though. What I do have to show is a Scheme interpreter, which I made when I was studying SICP (for fun, and I think it’s worth the time.)
So, what do I work on for XFCE? I have set two big goals for this summer.
Fix buggy launch behavior
Some people experience a bug that thunar tries to execute ordinary files like subtitles, and even directories. That happens when these files have execution bit (+x) enabled. I will try to fix this problem by checking MIME type before executing.
Another problem with launch behavior is that someone can slip in an executable file with execution bit on by packing it inside tar archives. This may not be a problem with normal scripts, but .desktop files can change their icon or file name to resemble normal document files. Files (formerly known as Nautilus,the file manager of GNOME) had the same problem before and they introduced safety flags using GVFS metadata as a solution. We can do the same trick because we use GVFS, too.
Improvements to file transmission
Have you ever experienced this: You were copying a lot of files, and somehow it got interrupted. You copy same files again. You skipped everything that was “already copied” to save time, only to find out a year later that the most important file was interrupted during the copy and you are left with the first 10KB of that file. To prevent this issue, you can copy every files again just to be sure, but that is a huge waste of time. If there is an option that leaves a partailly copied file as *.partial and it automatically deletes one, wouldn’t it be a better solution? If I have spare time I also would implement pedantic feature like “verify checksum of every files copied” to use on network drives.
Speaking of network files, Thunar loses metadata when copying files from GVFS. GVFS is a wrapper (naively speaking) for exotic locations like network file shares, smartphones, trash bin, and et cetra. Also, files copied from GDrive are labeled with unreadable names rather than the actual file name. I would also fix this problem.
Well, that’s what as far as I can tell! Congratulations to fellow XFCE GSoC contributors Vishal Sharma and Kefalidis Sergios, and major thanks to my mentor Alexander Schwinn.
Check out my Thunar contributions here:
Post 4.16 fatigue and what’s next
After we successfully released Xfce 4.16 as an early Christmas gift to all users last year I personally fell into the typical “post release fatigue” (PRF). On the one hand I was exhausted, on the other hand that’s how far our plans had taken us so there were no clear next steps we had settled on (apart from taking a break and recharging :)).
So what’s been going on since then…
Xfce 4.16 maintenance
First of all, we’ve done quite a few maintenance release of 4.16 to ensure it’s stability. We already provided lots of bugfix releases of 4.14 – some even very recently (Desktop, Appfinder) – but it looks like 4.16 may end up being (at least: among) the best maintained Xfce release so far.
Thunar is probably the active component with a 6th patch release being available already. Here goes an overview of all patch releases since 4.16.0 in December 2020:
- Thunar: 4.16.1, 4.16.2, 4.16.3, 4.16.4, 4.16.5, 4.16.6
- Panel: 4.16.1, 4.16.2
- Xfwm4: 4.16.1
- Garcon: 4.16.1
- Appfinder: 4.16.1
Developer documentation
In order to improve documentation for developers and make it more readily available we have started developer.xfce.org. For now this site hosts the API documentation of most relevant core components. This documentation is automatically kept up-to-date as part of our GitLab CI for the xfce/xfce-build Docker container and re-deployed on every week based on the latest 4.16 release tags.
Furthermore, we improved the shell-based helper scripts for developers, e.g. xfce-build (to locally run distcheck in the same Docker container used in our CI) with subcommands.
Task manager
I have fixed some bugs and done maintenance releases of the 1.4 series and started the 1.5 development series, which features a port of Task manager to Xfconf and Client-side decorations.
New icon naming scheme
As we changed the icon names for all Xfce components during the 4.16 cycle, I also migrated some plugins to the new naming scheme.
To briefly explain the rationale behind our change in 4.16: the previous names were highly inconsistent, overlapped with icons also used/shipped by other packages in distributions (so shipping our own icons with those “old” / “used” names would lead to unsolvable packaging conflicts). Especially the “standard” names like “preferences-desktop-*” would have been impossible to update and ship for us. In order to provide a consistent look and also to make it easier for icon theme maintainers to set up icons for Xfce we decided to follow the rDNS naming scheme for desktop files. The same naming scheme is already followed by Gnome, so it is fairly widespread in Gtk-based environments. Finally: previously no icon theme maintainer could even provide dedicated icons because the names overlapped and would also appear in other contexts or Desktop Environments.
Being an icon theme maintainer myself, I understood that this would lead to work for others. Sean even created a script to make it easier for everyone to update existing themes.
Plugin updates
I have taken a look at the three more prominent “monitoring plugins” of Xfce, namely CPU-graph, Systemload and Netload. I have created new icons for all three of them in a style consistent to the icons introduced in Xfce 4.16 and also ported Systemload to Xfconf.
I have also updated the Weather plugin quite a bit, adding a new icon, porting to Xfconf and improving the UX of the settings and forecast summary windows.
Finally some of the plugins mentioned above now implement the xfce_dialog_show_help API, which creates a “Help” button linking to the plugin’s documentation. This has been made possible by Kev, who ported the plugin documentation pages to docs.xfce.org and harmonized them, where possible. He also helped with adding more of these “Help” buttons and we’ll probably continue updating our plugins in parallel to the 4.18 cycle to make it easier for users to find the corresponding online documentation.
What’s next
The next step for me will likely be to focus on kickstarting the 4.18 cycle, which is still in its planning phase.
Xfce Panel Profiles 1.0.13 Released
Introducing new layouts and improving on existing ones, Xfce Panel Profiles 1.0.13 makes it easier than ever to manage and experiment with new panel configurations.
What’s New?
New Features
- New “Cupertino” macOS-inspired layout ( Xfce #7). Note that this theme requires the AppMenu Plugin to display the menu in the panel.
- New “Redmond 7”, Windows 7-inspired layout ( Xfce #8)
- New “Xfce 4.16” layout to make it easier to get back to defaults
- The Whisker menu configuration is now included in the export (Xfce #11). Existing templates using the Whisker menu have been updated to include appropriate defaults.
General
- All existing templates have been updated with better support for Xfce 4.16. This includes updated launchers, current defaults, and replaced plugins.
- Bashisms have been removed from the Makefile, enabling installation with alternative shells.
Updated Translations
Belarusian, Czech
Screenshots
Xfce 4.16, Cupertino, and Redmond 7 Layouts
Downloads
Download Xfce Panel Profiles 1.0.13 from the link below.
Source tarball ( sha1, sha256)
Xfce Panel Profiles 1.0.13 Released
Xfce Panel Profiles 1.0.13 has been released! The new release introduces new macOS and Windows layouts and improves on existing ones.
The post Xfce Panel Profiles 1.0.13 Released appeared first on Sean Davis.
Xfce 4.16pre2 released!
We are pleased to announce the second pre-release of Xfce 4.16 (a.k.a. xfce4.16pre2), moving us closer to the final release. As you all may have noticed, we are again a bit behind the schedule, but nothing like the 4+ years it took from 4.12 to 4.14, so please hold your excitement a tad longer while we are polishing the rough edges. For now, help yourself with the latest batch of changes:
Notable Changes
General
- More new app icons with rDNS naming scheme
- Bugfixes and minor improvements in all components
- Translation updates
Settings
- Disable UPower support by default
- Improve UX of settings dialogs (inline toolbar labels etc)
- Default Applications: Add ‘Open with…’ button to settings dialog
Libxfce4ui
- Revamped About Xfce tab
- Improve UI for setting shortcuts
- New API to launch “daemonized” processes
Panel
- Icon and appearance improvements
Power Manager
- More accurate status icons (Fixes #95) - 10 percent steps instead of “low, good, full”
- Respect the notification daemon’s timeouts (Fixes #57)
Session
- Tweak settings dialog (making columns sortable etc)
- Add xfsm-lock icon
Thunar
- Add support for transparency in gtk themes
Tumbler
- New thumbnailer plugin for epub files
Where can you get it?
Similary to pre1, you can either manually compile the tarballs or use xfce-test (ubuntu_20.04-xfce-4.16pre2 tag should be available at any moment) to enjoy a safe preview of Xfce 4.16. See the previous post for more options.
What’s next?
Finally, we will decide based on the feedback we get on pre2 whether to do a third pre-release or to go straight for the Xfce 4.16 stable release towards the end of the year. If no showstoppers are found we will try to release 4.16 still in 2020.
Xfce 4.16pre1 released!
As scheduled we have just released Xfce 4.16pre1 on August 27th (sorry for the long time to write a post about it) - the first development release leading up to Xfce 4.16. And it comes with a boatload of new features and improvements, so prepare yourselves.
Notable Changes
General
- Dropping lots of code (Gtk2 support), improving maintainability
-
Adding new icons to all core components to extend Xfce’s visual identity (also: follow freedesktop.org rDNS icon naming standard)
-
A revamped and improved “About Xfce” dialog that also holds general system details
-
Switch to client-side decorations for settings dialogs
- Lots of bugfixes everywhere
Settings
-
New “Default Applications” dialog: merge between “Mime Settings” and “Preferred Applications”
-
Display: Support for fractional scaling (with XRandR), better fallback in case of mis-configuration
-
Settings Manager: Improved search/filter
Panel
-
New Plugin: “Status Tray” - a merger between the systray and the statusnotifier plugin, will make life for users much easier and less confusing, now supports the panel’s global “icon size” setting
-
Autohide animation: Makes “autohide” more easily understandable (in the sense of: where did my panel just go?)
- Launchers now show desktop file actions on right-click (e.g. “Open a New Private Window” for Firefox)
-
The Window list now supports “launching a new instance” of an application in the right-click menu
- The Workspace switcher can optionally show numbering for workspaces
- Dark mode for the panel (precondition: your theme has to support dark mode)
Thunar
-
Copying and moving can be paused
- Support for queued file transfer (configurable)
- Initial support to remember view settings per directory
- New versioning scheme
Volman
- Removed PDA Tab
- New versioning scheme
Xfwm4
- Show alt-tab dialog only on the primary monitor (if one is set)
Power Manager
- Cleaner settings dialog (battery and “on power” settings)
- Optional visual indicator in the panel when “Presentation mode” is enabled
- Automatically dismiss low-power notifications upon connecting of a charger
Session
- Improved gpg-agent support
- Smaller visual cleanups
Appfinder
- Allow sorting apps by frecency (frequency and recency)
Thumbnailing Service
- Support for excluding paths (in the tumbler.rc settings file)
Xfconf Settings Service
- Enable gsettings backend by default
- Bash auto-completion for xfconf-query
- Drop Perl bindings
Where can you get it?
Besides manually compiling tarballs, it’s also possible to use xfce-test (ubuntu_20.04-xfce-4.16pre1 tag) to easily preview Xfce 4.16 without the risk of breaking your system.
Please go ahead try this release if possible, we would be more happy to hear your impressions as well as get bug reports before the final release.
What’s next?
We’re expecting to release Xfce 4.16pre2 at the end of this month and if necessary pre3 will be released in October. If everything goes as planned Xfce 4.16 should be released by November!
Xfce infrastructure in 2020
Oh boy, 3 years without any blogpost ! So much things happened in the Xfce world!
First, we finally released Xfce 4.14 in August 2019, more than 4 years of effort, a migration to gtk3, and so much new things, but you already know that, and you surely already run it.
We are now working on Xfce 4.16 , with the hope to release it this year (yes, in 2020) !
You can read more development news on our blog.
Some buzzwords: new icons, CSD, drop of gtk2 support, UI revamp, and tons of other stuff.
I want to talk a bit about the infrastructure.
Last year, we had a Gandi sponsorship for our servers. I started an Ansible repository with all our services (no more -undocumented- local modifications!), and we migrated a big part of our infra to the new servers (docs, www, wiki etc).
Then came the time to think about our development environment. We used the cgit/gitolite/bugzilla triptych, which worked fine for us for more than a decade, but make difficulty to have new contributor (our workflow was…hm, suboptimal).
We tested differents solutions (mainly Gitea and GitLab), and we opted for the famous Gitlab, already used by multiples open source projects. In the core team we were several to use it at work, so we were in a familiar environment.
For months, a gitlab was running on one of our Gandi instance, to do tests and prepare the transition.
But it was so much work that we never started the real migration. Then came the Covid-19 lockdown. No friends, no bars, lot of free time, so why not spent it on Xfce ?
With Simon (ochosi) and Andre (andreldm), we started to use our own gitlab by opening issues, creating todo, doing merge requests etc related to the migration.
The 1st of May, we finally did the migration to GitLab ! Woot !
Jason (j4yav), working for Gitlab inc, joined us and proposed to help us for the Gitlab CI/CD setup. At the same time, we got a new (sponsored !) VM from FossHost ! Perfect timing, we can now run a dedicated gitlab-runner instance, and we started to use gitlab-ci !
As of July 2020, almost all Xfce components (core, apps, panel plugins) run make distcheck on every merge requests and push to master, thanks to our xfce-build docker container.
Now that we have a beautiful GitLab, merge requests and CI, the only missing part was… the migration from Bugzilla !
I forked and modified bztogl, a tool developped and used by Gnome and Freedesktop folks when they migrated away from bugzilla to gitlab in 2018/2019.
Initially, we wanted to migrate all bugzilla issues to gitlab (opened and closed ones). But we had more than 15000 issues ! We decided to only migrate opened issues. We took the opportunity to do a biiig cleanup of old bugs by closing more than 500 of them.
A important condition of the bugzilla migration was to not lose our 15 years of history.
AndreLDM did a huge work by creating bzstatic, a tool to snapshot a bugzilla instance and make it a simple static html version : https://bugzilla.xfce.org.
He open sourced it at https://gitlab.xfce.org/andreldm/bzstatic !
As a result, we now have a modern developments workflow, fully integrated with gitlab. We enabled github and gitlab.com auth on our instance (some people requested it), and since 3 months, we’ve seen a surge of new contributors, issues and merge request ! Really a good news for the Xfce project ! We also had a sponsorship from Scaleway lately, that we need to set up !
So much things left to do, like update all our documentations for the new workflow, work on Xfce 4.16, get rid of our old release manager and use gitlab-ci to generate artifacts, simplify our translation workflow and tons of other things !
Enjoy !