The libreoffice 6.0.0 snap is ready for testing in the candidate channel. It has received a fair amount of smoke-testing, and according to the download statistics it has a large number of users.
We are keen on hearing from users for whom the snap doesn’t work well enough, or is not on par with the packages in the ubuntu archive (or your other distribution of choice, for that matter).
Please describe here your use case and expectations, and how the snap doesn’t meet them. We’ll turn those into bug reports that we can then address to raise the quality and usefulness of the libreoffice snap.
I had LO open when I refreshed to 6.0.0.3 (47, candidate) and when I tried to close LO I got this error in a dialogue box called ‘LibreOffice 5.4.4.2’ (which I had to close twice):
saving the document file:///home/adam/snap/libreoffice/46/.config/libreoffice/4/user/basic/dialog.xlc:
General Error.
General input/output error.
$ snap version
snap 2.31 # core 16-2.31 (4017, candidate)
snapd 2.31
series 16
ubuntu 17.10
kernel 4.13.0-32-generic
Installed it on Ubuntu 17.10. It’s working fine. Works with Zotero as well, which I needed the most. However, there are some issues:
Font antialiasing not working. Texts look bad.
It’s using a very old and ugly Adwaita theme similar to the snaps like VLC and Skype. However, some other snaps like Atom comes with nice theme; so maybe it can be fixed.
System fonts are not available. Only a few font options are there.
Places (Documents, Downloads, Pictures etc.) in the file open dialogue box does not work. Bookmarked locations (Documents, Downloads etc.) work.
Launcher icon is always the blank document icon be it writer document or calc.
This has been in progress for a while, the most recent update is here.
This should be fixed, please comment on this thread saying it isn’t working on LibreOffice (linking back to your post here) and give them the output of snap version and the tracking and installed lines of snap info libreoffice and snap info core.
E.g. my LibreOffice snap version
$ snap info libreoffice
tracking: candidate
installed: 6.0.2.1 (53) 419MB -
$ snap version
snap 2.31.1
snapd 2.31.1
series 16
ubuntu 17.10
kernel 4.13.0-36-generic
$ snap info core
tracking: candidate
installed: 16-2.31.1 (4110) 85MB core
I suspect this is related to this bug but please can you file a new one (make sure to add ‘[snap]’ to the start of the bug title and add the ‘snap’ tag to the bug report)?
Ubuntu 18.04 here, using libreoffice 6.0.4.2 (63).
I’m sorry to report this, but LO in this form remains hardly usable:
Impossible to open documents on SMB shares mounted through Nautilus (yes I do have :removable-media enabled for libreoffice)
Impossible to open documents owned by another user.
Impossible to open documents in /tmp (the confined package has its own /tmp). This is especially annoying, since /tmp is where Thunderbird saves attached files by default. In practice this means it’s impossible to open directly a file received by email.
Impossible to sign documents using gnupg (due to no access to ~/.anything), which particularly a problem when preparing more complex templates with macros.
The current confinement is way too strict for a desktop office software suite. The problem, in my opinion, is that snap was primarily designed for a mobile phone environment, with a confinement that somewhat makes sense there, but is absolutely impossible to use on a desktop. I’m not that familiar with XDG Portals that snap will start supporting in the next cycle, maybe that would alleviate some of the problems. In the meantime, a solution could be to switch to a Classic confinement?
Thanks for your reply, glad to see that there are solutions coming up. What about the last problem though, where snap denies LO access to any file owned by another user?
I dont know enough about portals to judge if they would be able to allow this, which is why i left the question out in my answer (there is surely no currrent snap interface that allows this… ).
I think this a problem that the snap interfaces should address. Deciding that apps can’t access files owned by someone else is an arbitrary limitation that stands in the way of many legitimate and expected usage scenarios “just because”. IMO the home interface should allow the package to access any file the user can access, anywhere in file filesystem tree, in all modes the user can (read, read write, append) etc., no more, no less.
that would make having an interface at all pretty pointless
while i agree that there should be an interface that allows such access, i dont think it should be part of the home interface … snaps are used in many environments and interfaces need to be fine-grained enough to take that into account.
