Yes we are still here!
It has been many seasons since I last posted. A lot has changed over the years. Old stories end. New stories begin. As they say, "time changes everything". Priorities change.But as things change, there are still things that remain constant, remain unchanged.
Fatdog is one of them.
Fatdog is still alive. Still kicking. Still actively maintained. By the same Fatdog team. Though we don't announce every single changes that we make, updates still trickle to Fatdog package repository. Eventually, when the time comes, there will be another release.
In the meanwhile, enjoy.
Comments - Edit - Delete
Fatdog64 903 Final is released
Fatdog64 903 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 902 Final Is Released
Fatdog64 902 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 901 Final Is Released
Fatdog64 901 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 900 Final is released
Fatdog64 900 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog 900 Beta is released
Fatdog 900 marches along, and now the Beta release is here.Fatdog64 900 Beta Release.
Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog 900 Alpha and Fatdog 814 Simultaneous Release
The long awaited release of Fatdog64 900 is now here. It is in alpha state. At the same time, we release the last, and final version of the 800 series (814).Fatdog64 900 Alpha Release.
Fatdog64 814 Final Release.
Forum announcement.
You can download 900 Alpha from ibiblio.org, uoc.gr, or nluug.nl.
And 814 Final from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 813 is released
Release notes here, announcement (and discussions) here.Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Xdialog ported to GTK+ 3
Xdialog is a popular program to create a simple GUI for shell scripts. It is easy to use and implements the most commonly used GUI elements (e.g. input boxes, message boxes, etc). It was one of the earliest program of its kind.Sure, there are tons of similar program like this nowadays, some with even more powerful features - kdialog, zenity, yad, and I'm sure there are a lot more ... but Xdialog has two things going for it.
1. It's available almost anywhere.
2. It's command line interface (the parameters you pass to it, to get the GUI you want), is stable and unchanged in the last 20 years.
Any program you write with Xdialog would most probably work, while the same thing can't be easily said for the others.
There is only one problem. Xdialog is old, and for the longest time, has always been available only with those with GTK+ 2. GTK+2 has been end-of-life for about a decade now, although it is still popular.
GTK+ 2 replacement is GTK+ 3, so it's a reasonable migration path (as opposed to Qt for example, which requires a total re-write).
So far, I have not found a port of Xdialog to GTK+ 3, so I decided to start my own. The motivation is simple: so that in the future when we move to GTK+ 2-less future (only pure GTK+ 3), existing shell scripts that use Xdialog still works (we have a ton of those).
The result is here: http://chiselapp.com/user/jamesbond/repository/xdialog/index
The code in the repository compiles with both GTK+ 2 and GTK+ 3 (the original Xdialog compiles with GTK+ 1 and GTK+ 2). Login as anonymous in order to download the tarball. The port retains almost all of the features of the original Xdialog (except "unavailable" status are not available for radiolist/checklist/buidlist).
PS: While in the process of porting it, I found that somebody already did that here: https://github.com/wdlkmpx/Xdialog. I ended up using borrowing some of the codes from there to speed up the porting process, although the final code that goes into my repository is different wdlkmpx's. Another thing which is different is that I tried to retain all the existing functionalities, while wdlkmpx's port has dropped some of the lesser used features (which he documented in the his version of the Xdialog's manual).
Comments - Edit - Delete
The state of FOSS today
Somebody recently propped up Okular.It's the best PDF viewer, they say. You can view a lot of other stuff, not only PDF, but also stuff like XPS, Djvu, CBR, and many others. And it has annotation ability. And form-filling. And a lot of other nice stuff. Supposedly.
Wow. Nice. I already have a working and nice PDF viewer (Evince and qpdfviewer), but this Okular sounds so much better! I've really got to see it!
So what's the next logical stop? Try it, of course.
So I head to the website, and then on to the download page.
And immediately I see that we have problem, Houston.
There is an option to download it from the KDE Software Centre, since, well, Okular is a sub-project of KDE. There is no surprise here. It requires KDE to run, at least, KDE libraries.
But I don't have KDE.
And I can't install KDE from my repository either!
Why? Oh, it's only because I'm running my own build-from-source Linux (=Fatdog64), so I won't have KDE in my repository until I build KDE myself. But KDE is a big project, building the whole thing just to __try__ to use a PDF viewer sounds ... silly.
But that's not a problem in 2021, right?
Everybody delivers their programs in AppImage.
Well, no.
At least not this Okular.
Well no problem, just use Flatpak! Okular supports Flatpak!
Sorry, no cigar either.
Flatpak isn't just a packaging mechanism, it's an entire ecosystem.
The host OS needs to support Flatpak in the first place, before it can be used.
Fatdog64 doesn't have Flatpak support, and I'm not about to add it either (because it requires another bajillion dependencies to be built) - certainly, not for the sole purpose of testing a PDF viewer.
So what else can I do?
I see that Okular provides Windows binaries.
But I don't run Windows!
Yeah, but that's what "wine" is for, right?
So, downloaded said Windows binary, launched it with wine, and only then I got to see the wonderful PDF viewer. No amount of words can explain my jubilation, finally.
It gives me such a warm feeling, that me, someone who runs a FOSS operating system, has a such difficulty to run another FOSS software on it. Instead, I have to resort to using a binary meant for closed-source OS in order to run said FOSS software on a FOSS OS.
Merry Christmas everyone.
PS1: if you're wondering what's the point of this post: if the Okular team can spend the effort to make a Windows binary (with all the dependencies compiled in), why can't they do the same thing for other Linux users, in AppImage format?
By all means, pander to Windows users if you have to - but remember where you came from, would you? Nobody cares for your stuff in the Windows world: Adobe makes the most comprehensive PDF tools (viewer, editor, whatever have you) in the entire Windows universe. Only folks in the FOSS world do, and you're not making it easy for them.
PS2: Of, and if you're an AppImage packager, I have a message for you too.
Please, please, __resist__ the temptation to build your stuff on systems with the latest glibc, especially the one released last month. It makes said AppImage not runnable with people who happen to have OS with glibc from, say, 3 years ago, which is not that long ago.
Remember that the whole point of AppImage is to make it distro-independent, and this includes older distro, not only those relased in 2021 ?
Even a project as complex as VirtualBox can run on truly ancient glibc, because, they realise that backward-compatibility is important.
Yeah. Thanks for listening.
Comments - Edit - Delete
