I am also on Linux Mint. I installed Seamly from Flathub and get the same build date. When I click the “Check For Updates” I get an error about github.com not being found.
My install of Seamly2D was within the few weeks. For LM users Seamly2D is not inn the repositories. We compile from source, or run the Flatpak or AppImage versions.
I just learned that Flathub has a new build as of 1 day ago. When I update to the most recent version my build revision in the About window matches that of @Pasque The info on Flathub is:
Well that makes sense. The Check for Updates is looking for a revision number that is the Github release build date. If you build from source you’re not going to have a correct revsion number as that is generated by the Github CI. You are going to get this:
Need to have a revision number like this… which is literally the build date & time:
Last week’s was Feb 9, 2026 @ 2:14 in the morning.
We don’t control the Flatpak so it’s out of our hands.
It must be either a Flatpack thing, or they don’t/didn’t have access to github for some reason. I got an AppImage download when I clicked the button from my local-build copy of Seamly.
Interestingly, they both have “unknown” Build revision… Oh! you typoed Version not revision! nevermind.
I assume that it just counts any 6.0.1 as an older version, but I have neither inclination nor time to test that tonight.
That’s the old versioning from the V days, and it’s coded in the app so that’s what you get if you build locally. The version 0.6.0.1 was the last version when the project was forked, and never changes. The ci.yml script on Github overrides that whenever a CI job is run giving the version the build release number.
The ci.yml runs the version.sh script that actually overwites the (branch) source code with the correct Github version. Then the apps are built.
If you ran the version.sh script first locally, then build as normall it will have a correctly formatted version… just not the same as a release build as on Github. The key is the last digits of the number which represent the time (hr &mins) built. It would be impossible to time a local build to that of a GithubCI build to have those digits match.This is all assuming your local is upto date with the main repo for if you don’t fetch the origin before building locally you don’t know if your build is current. If you run the version.sh script your code would no longer have the 0.6.0.1 though until you fetched the origin again and it would probably be back.
In an attempt to see if the latest changes were present in the Flatpak version Pascal I are using, I glanced through the Full Changelog of v2026.2.16.214. What I came up with, that I thought I had a chance of visually spotting, was where you added the ability to “set the description column to stretch” in the History Dialog file. As it turns out I can change the size of all of the columns. Though not completely as I expected; I had to increase the size of the entire window for some increases and decreases in width.
For all I know this ability was present in past versions. I never checked in the only other version I had. And I am no coder, I could have easily overlooked it in my perusal. After all, the last computer language I learned was Basic back in the 70s.
In this case I didn’t want or need the newly added angle formula to expand… it makes more sense to keep the description column to expand so I programmatically set the description column to stretch.
You can set a column to a fixed width:
othwrwise the column is going to adjust itself to the default or minimum based on the size hints:
which is determined by the size policy and hints of the widget:
Designing forms to adjust is an art and science unto itself. What I did with the History dialog is try to set colum widths that make sense, and where the description col is the one that stretches when the window resizes:
and if neccessary certain columns like the Name will resize to fit the largest content if need be… and the Description will shrink.
And if you resize the window really small it triggers the scroll bars to appear and the Description gets really shrunk. I should probably bump the minimum width up on the description.
