Is there any switch, button or dial that can stop this popup from appearing ?
“Your donations support our worldwide community.” Wants me to click at Donate button.
TIA’s for any tips or clues.
1 Like
It should not show after you dismiss it using the cross (unless you reset user profile, which makes LibreOffice think it is started for the first time). Does it re-appear for you?
According to this blog post, “The nag notices are designed to trigger every 90 or 180 days.” and usual methods of overriding it within the user profile don’t work.
You need to create a .xcd file containing this markup inside $BASEDIR/share/registry (eg. /usr/lib/libreoffice/share/registry/noinfobarnags.xcd):
<?xml version="1.0"?>
<oor:data xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:oor="http://openoffice.org/2001/registry">
<dependency file="main"/>
<oor:component-data xmlns:install="http://openoffice.org/2004/installation" oor:name="Setup" oor:package="org.openoffice">
<node oor:name="Product">
<prop oor:name="LastTimeGetInvolvedShown" oor:op="fuse" oor:finalized="true">
<value>0</value>
</prop>
<prop oor:name="LastTimeDonateShown" oor:op="fuse" oor:finalized="true">
<value>0</value>
</prop>
</node>
</oor:component-data>
</oor:data>
Honestly, I worry that, with how many people still download Apache OpenOffice, not realizing how unmaintained it is, they might take recurring donation prompts as a sign that LO is on shakier footing than AOO or is a less professional product.
1 Like
It’s a matter of principle. I might whip up something PyQt-based or I might see if I can integrate Gnumeric or Calligra into my workflow, but I don’t want to endorse (financially, verbally, or by any other contribution), this kind of behaviour by a product’s upstream.
(Nag all you want on the website, but I firmly believe that what’s running on the user’s hard drive in day-to-day use is a sacred space… especially when someone’s gone out of their way to avoid proprietary OSes and office suites.)
That said, grumpy as I am, the comment about Apache OpenOffice was an honest attempt to be helpful, based on past observations about human psychology.
EDIT: I’ve revised the original comment now… and sorry for being a grump. It’s a recurring problem. I try to train myself to be diplomatic and then, sooner or later, something irritates me when I’m not on guard, and my ability to be introspective goes out the window for a few minutes.
1 Like
I find this an extremely condescending comment on a serious topic - “if you can’t be bothered, don’t tell us about it” - what kind of reply is this?
Let me get one thing straight, LibreOffice developers: because of these ANNOYING “pop-ups” I will most definitely NOT give you any money, nor will I help making LO better.
STOP showing those messages. I am not a 12 year old, who needs to be reminded or begged to do something. I will (correction: would) donate and help, because I WANT to, and not I because you annoy me with those info bars every N-time.
Honestly, this is Microsoft Windows behaviour… Perhaps I should go back to OpenOffice? (Please, refrain from answering, “Then go back to Openoffice”.)
(And why are all my lines underneath one another?)
1 Like
Ok, that’s FINE!
Btw, the term is not pop-up but InfoBar.
I too find irritating - obstructive - the various periodic ‘infoBars’ that solicit contributions of one form or another.
Why have you posted this as an answer?
Why not just implement the answer given above and upvote it or like it?
“If you don’t like being nagged but you actually need the functionality, pay for a proprietary competitor/build” is “shareware in the Windows/macOS-ecosystem” reasoning.
I don’t know about you, but I believe it’s corrosive to open-source software to treat it, culturally, as just “freeware/shareware where you have access to the source code”.
Open-source software lives and dies on community and network effects, and that attitude harms building and maintaining a community.
It’s just disgusting when users treat FLOSS this way: as something given to them by a kind of slaves, who have obligations, but don’t have a right to voice their needs. Users feel entitled to say what the real community (i.e., those who actually contribute) may or may not to inform them: e.g., that the project really has some needs, which only end users, who benefit from the labor put into the software, provided free and open, can satisfy. That there is a reality that the users do not support the software as much as they use it. That it doesn’t really matter that some of them are so lordy that they feel irritated by these facts being said to them, that they write such things, and do not simply use the already provided solutions…
- I’m a developer myself, so I’m not ignorant of how users can treat developers, and I’m currently struggling with resource constraints, so I do have some experience with that. (eg. This project has been languishing because the pandemic was not good for my mental health.)
- I do donate to projects… not just file bugs and such.
Heck, in the world of games, I own over 3000 digital downloads and I donated more to OpenTTD than what I was willing to pay for all but two or three of the proprietary ones. (Likewise, I’ve donated to 0 A.D. despite the fact that I’ve never won a game because I suck at RTSes.)
…but do you know what one of the determining factors is in whether I donate to a project? Whether it respects my agency over my own computer.
I’d never contribute to jDownloader, for example, because I don’t like how the “hide donation button” option overrules my agency over my own computer by unchecking itself monthly.
If there were a comparably compatible and functional open-source alternative to LibreOffice, I’d switch to it and recommend it to my less computer-savvy friends and family members on principle, but I don’t know of such a thing, so I use it under protest as the best of a bunch of less-than-ideal options and refuse to donate because I refuse to reward people for patronizing or disrespecting me.
So what? It’s your idea how things work in this world.
If it were a different world, where people like you were the majority, it would be - well, a different world. Currently, people who do contribute, and don’t need reminders, are the minority; and others, who would contribute, but only if they are reminded, are the majority. And projects need to remind users.
And behaving as if one lives in a world different from what is the reality is … not ideal.
*shrug* All I know is that, aside from the need for uBlock Origin and SponsorBlock in my Firefox, LibreOffice and jDownloader are the only applications on my Linux desktop that are difficult to say “I know you want money. I want to be left alone and it’s my computer.” to.
If LibreOffice had some kind of “don’t ask me again” option that wouldn’t get overwritten by a Flatpak upgrade (I use distro packages so I can add noinfobarnags.xcd and have it stick)… even a particularly well-buried one, I’d be fine with that. It’s the paid-per-impression advertisement “No. You have to keep seeing it, even if it just makes you feel less charitable each time”-ness that I take issue with.
Aha. Maybe the solution needs to be mentioned here? It is this extension published in 2019.
I see now that you basically repeated it in your answer 
Well, yes, it is the way. And I myself contributed to make this extension work.
heh, my reading skills are poor. I only see things after reading a few times
Well, this is basically a question to flatpack packaging, isn’t it? 
Sorry for a noob question (I don’t use flatpack): does it also drops user profile? Because per-user extensions are kept there…
Ahh, thank you. I’ll give that a try as soon as I have a moment to get things switched over. It’ll be nice to have another application where I can easily manage and tighen a sandbox using Flatseal, rather than having to futz around with /etc/firejail files.
Both I and the author of noinfobarnags.xcd weren’t able to get the hand-written noinfobarnags.xcd to have any effect if installed in the user profile rather than under /usr… and Flatpak’s approach to packaging regenerates the /usr-equivalent stuff on each update.
More specifically, Flatpak is built on the same OSTree “git for your OS” infrastructure that things like Fedora Silverblue use for system packaging, so a package upgrade is as follows:
- Install the new version to
/var/lib/flatpak/app/<APP_ID>/x86_64/stable/<REVISION_HASH>/or the equivalent--userlocation. (using hardlinks to deduplicate files that are hash-identical between versions with the help of tooling and resources to help packagers maximize the number of files that stay the same.) - Update the
/var/lib/flatpak/app/<APP_ID>/x86_64/stable/currentand/var/lib/flatpak/app/<APP_ID>/currentsymlinks to point to the new revision. - Queue the old revision’s folder to be deleted once no more active containers are using it. (This solves those situations where things like Firefox will force a restart because the version-matched content process binary no longer exists and so they can’t spawn new subprocesses by extending the OS’s “files don’t get deleted until they have no open file handles” behaviour to the entire container as an atomic unit.)
Because the design intent is that you never manually modify the installed program images, there’s no facility for applying patches which will be copied over when the current symlinks are switched, so a system-installed noinfobarnags.xcd just stays in the old version’s folder and gets deleted along with the other files that make it up.
(Basically, it’s designed with the expectation that you’ll never commingle installed package contents and site customizations. A package’s manifest can declare the need to access stuff under /etc, but /usr is always the “platform runtime” package and /app is the application package, both of which are read-only from inside the container and assumed to be immutable from outside the container.)
LibreOffice is designed to have two customizable sources of configuration: user and shared. The shared one is intended to be managed by an admin; so IMO, a package maintainer should make sure that their package either does something to keep the admin customizations of shared location intact on upgrade (this is done e.g. by our Windows installer), or should customize the placement of the shared location to be outside of the immutable data set.
So I’d suggest to file an enhancement request to flatpak maintainer to move from /usr/lib/libreoffice/share to some other place. Then this problem could be avoided.
In the Flatpak case, it’d be /app/libreoffice/share/ since $PREFIX is /app for Flatpak rather than /usr. (So that constructing the container filesystem only needs mount --bind to combine the platform runtime and application packages rather than some kind of overlay filesystem which the kernel might not have been built with… and, in my experience with using them as part of Firejail, things like Unity sometimes fail with cryptic errors when run under overlay filesystems, so it’s probably also a compatibility thing.)
In fact, they specifically add a site customization to /app/libreoffice/share/registry/flatpak.xcd as part of their build process to disable UseOpenCL as some kind of workaround for something or other.
Does LibreOffice support more than one site customization location?
…and, assuming they can find an alternative way to apply that workaround, do you have a link to the documentation for how to relocate that folder?
Then I would think that putting your xcd there under /app/libreoffice/share should work and be kept on upgrade? Indeed, I would assume using the extension a bit better, but still, I feel that your original trouble that customizations get overwritten each time is not optimal.
Hmm. This looks silly, to not provide a way to administer application system-wide. I don’t think we have a way to use several shared locations…
Then I would think that putting your xcd there under
/app/libreoffice/shareshould work and be kept on upgrade? Indeed, I would assume using the extension a bit better, but still, I feel that your original trouble that customizations get overwritten each time is not optimal.
No, as I explained earlier. The update involves writing a NEW directory that will be mounted at /app, swapping the current symlink over, and then queueing the old one for deletion.
Any changes I make to /app will get unapplied when the current symlink is switched over and then deleted when the old /app is, in effect, garbage collected.
It’s basically the OTA update mechanism used for things like phones, which is itself effectively OpenGL double-buffering, but applied to the filesystem.
Any changes I make will be to the “current buffer” and will be lost when the equivalent to glSwapBuffers() happens.
Hmm. This looks silly, to not provide a way to administer application system-wide. I don’t think we have a way to use several shared locations…
They have two approaches:
- The Filesystem Hierarchy Standard expects applications to put their site configuration in
/etcand their persistent system-level userdata in/var… both of which can be selectively exposed to a Flatpak-packaged application via its manifest. - Flatpak packages can declare “extension points” within their filesystems, where other Flatpak packages of type “extension” can be mounted. That’s how things like LADSPA plugins are provided for Audacity… though I’m not sure how much cooperation from the parent package is required to support more than one thing on the same extension point.