LabPlot - Cannot print or export

[Jonathan Riddell]

On Wed, Jan 06, 2021 at 07:05:43AM -0600, Bill Gee wrote:
> I always always always test new stuff on a virtual machine before letting it onto my main systems.  If it blows up, I can revert to a snapshot.  On a real computer, if it blows up I often have to rebuild from the metal.  It is a risk not worth taking, and a problem that has bitten me many times.  It is a lesson I learned the hard way.
> 
> The main issued I found with the flatpak for LabPlot is that it does not save files where I expect it to.  I specified "/home/bgee/Documents" as the directory.  LabPlot reports success.  If I save the file again, LabPlot reports that the file is already there.  However, I cannot see the file with any other program!  Bash, Krusader, Dolphin ...  None of them see the files I saved out of LabPlot.  In my mind that is reason enough to not use the flatpak.
> 
> There may also be problems with themes, icons, fonts etc.  I did not test for that.  The Z-order problem with file-open and file-save dialogs is very annoying but not quite a show stopper.
> 
> As a general philosophy, I still think that flatpaks, snaps and containers are imperfect solutions for which no problem exists.  Let's assume, for example, that I choose to run EVERY application I use as a flatpak.  That means Firefox, LibreOffice, KMail, KOrganizer, KeePassXC, Audacity et.al.  Each of them brings in and launches a complete version of KDE.  None of them is running in the same sandbox, so they cannot see each other and use each other's services.  If, for example, I click on a KMail attachment to open it, does Gwenview open in the same sandbox as KMail?  If I click on an image in Firefox, does it open the same Gwenview instance as the one that KMail launched?  If I click on an email address in Firefox, does that launch a new instance of KMail or does it use the sandbox that is already running?
> 
> KeePassXC connects into Firefox to provide password filling.  If they are running in separate sandboxes, then how are they to talk to each other?  If I make a settings change in the KDE System Settings application, how does that get inside all the different KDE sandboxes?
> 
> And if all those applications DO run in the same sandbox, then what's the gain?  Why not run them in the real environment and save a huge amount of both memory and drive space?
> 
> I understand the problems with "DLL Hell", or its equivalent in Linux.  I made a good living for many years doing Windows tech support.  I think that flatpaks, snaps and containers are an interesting attempt to solve that problem.  However, the only result has been to change the appearance.  It is not gone - it just looks different.
> 
> I am - and remain - a committed contrary curmudgeon!  :-)  I think the real answer is to find a Fedora packager and ask them to create a repository package for LabPlot 2.8.1.

Containerised packages, Snaps, Flatpaks and Appimages, solve many
problems.  They mean one package can work on all Linux installs, from
the view of the app maintainers that's a massive advantage.  They also
mean app maintainers can package and deploy the app directly, not
being reliant on the timetables and person-power of a third party
project.

Integration between apps is done with xdg-portals, a spec which works between
Snaps and Flatpaks.

Here we have a good example of the problems caused by having to have
dozens of packagers for dozens of distros and versions of distros,
often there's no package for the setup you have.

There's still loads of work needing to be done to get Flatpaks and Snaps up to the same quality and cadance as traditional distro packages for sure, any help appreciated.

Jonathan