Unfortunately, GTK 4 has removed key themes. Eventually, Firefox, Chrom(e|ium) and all actual GTK applications will migrate to GTK 4, so this is not very future-proof.
I use a variant of the emacs key theme, so I'd be happy if there were a workaround...
It's unfortunate that the GTK devs feel they have to remove features which their users find useful to keep GTK maintainable. Keeping software complexity under control is a difficult task, and I can't begrudge them their choice.
Video conferences are as if everybody were potentially constantly staring at you, but you couldn't tell if or when this was the case, and despite everybody looking at you, you couldn't even make eye-contact with anybody, share a smile etc.
I'm not OP, (and people at Mozilla have probably already considered this), but why doesn't Mozilla try a far more aggressive Wikipedia-like donation campaign?
Admittedly:
1. Wikipedia has more "users" than Firefox.
2. Despite this, the donations Wikimedia receives are only about a fifth of Mozilla's budget.
However, people use their browser far more than they use any single website and hence might be more willing to donate more to Mozilla. (For example, I love Wikipedia, but I've gotten even more value from Firefox.)
Overall, this would be unlikely to cover all of Mozilla's expenses, but I'd also be surprised if donations (after such a campaign) would be less than 10% of current revenue; in any case it'd be a valuable source of diversification.
It's possible that the legal relation between the Foundation and the Corporation doesn't make this possible.
Encyclopedia Britannica[0] isn't free ("libre"), but it is now free (gratis). Arguably, being libre isn't quite as indispensable in the case of cultural/educational works as it is for software.
Doesn't the same also partially hold for Firefox and Chrome, though?
They wouldn't start charging for Chrome, as that's not their business model, but they might move part of their development out of (open source) Chromium and into (closed source) Chrome or further curtail extensions (e.g. adblockers) etc.
Google has done that with Android, moving more APIs and features from the open-source AOSP core to the closed-source Google Play Services library. Google can then control which Android partners get permission to ship Google Play Services for a full-featured Android experience.
As more browsers move to a Chromium base, Google might have a similar push to move more of Google's value-add out of the open-source Chromium core to the closed-source Chrome product.
No. Firefox vs Chrome is a completely different comparison than Wikipedia vs Encyclopedia Britannica.
The first two are browsers; software, the second two are stores of knowledge.
Browsers have been free for the longest time now, they are a commodity; the 'for pay' browser market died a long time ago. Possibly that was a mistake but that's where we are now and the parties that supply browers (Mozilla, Apple, Microsoft, Google to name the bulk) all try to win marketshare because they benefit from having more users. Putting up a barrier will automatically play into the hands of the opponents.
Wikipedia is a free and much larger alternative to EB, which historically was very expensive. If Wikipedia goes away there is no longer any incentive for EB to have a free tier, which is the one thing they can do to erode support for Wikipedia a little bit.
I'm not disagreeing that (in these scenarios) EB would probably become paid-for, while Chrome never would. I'm just arguing that Chrome would become even more privacy- and user-unfriendly, which is the approximate equivalent of EB putting up paywalls. (Is paying with your attention and privacy better or worse than paying directly with money?)
Apple would continue offering a relatively privacy-friendly alternative — but would require you to switch OS to use it; Microsoft might fork Chromium, but I fear that they'd only pay lip-service to privacy.
Obviously these analyses are complicated by the fact that in both cases the forces that helped create Wikipedia/Firefox wouldn't disappear. If Wikimedia died, then people would put up their Wikipedia dumps online in their own MediaWiki instances. If Mozilla died, then people would either try to keep Firefox alive or try to maintain a set of privacy patches on Chromium. How successful they'd be is another matter...
I'm probably not the intended "you", but one idea would be a "testimonials"/thanks section in GitHub/GitLab/Gitea, in addition to the standard Issues and Pull/Merge requests.
It'd allow users of the tool/library to express gratitude, give the developer feedback about their creation and possibly even provide inspiration to other users. People could set their own notification preferences, and the UI could make it clear to those thanking that they shouldn't necessarily expect a reply.
The "testimonials/thanks template" could include a suggestion to donate if you've made a commercial product using the software or if you're just a happy end-user.
GitHub is trying out "discussions", but that's far less targeted.
From a personal point of view, I just try to express thanks whenever I otherwise have a substantive point to make (bug report, comment on an issue, but as you point out that doesn't allow for situations where you don't have anything else to say.
Unfortunately, that's not what OP wants. What OP wants is that when they scroll, the position of the cursor remains at the same position in the buffer (the contents), even when that means that it leaves the currently visible screen.
What scroll-preserve-screen-position determines, is whether the point/cursor stays at the same visual position in the screen — i.e. if for instance your cursor was in the middle of the screen, it will stay in the middle when you scroll.
OP needs the currently non-existent scroll-preserve-buffer-position.
The lack of "scroll-preserve-buffer-position" has been a very minor pet peeve for me for multiple years, and for some reason this very simple solution just never occurred to me.
I can't believe I didn't think of this. I'm already using marks to keep track of position when I scroll, it's just all manual right now.
I'll likely mess around with some hooks in my config this weekend and see if this is actually feasible, or if it comes with caveats I'm not seeing right now. I guess it would need to account for multiple windows open into the same buffer too.
I'm convinced the edge cases will dominate this code, but the general idea seems straight forward. If you get this working, please share. Not something I think I want, per se, but I could be mistaken on seeing it work. :)
"Instead of setting the mark in order to operate on a region, you can also use it to remember a position in the buffer (by typing C-<SPC> C-<SPC>), and later jump back there (by typing C-u C-<SPC>)." -- https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...
Sure, but then every time the user does anything that might scroll the point off the screen, he has to remember to C-<SPC> C-<SPC> first. Installing a new habit that has to activate before such a wide range of editing operations can take a lot of time, during which the user is less productive because part of his attention is devoted to installing the new habit.
You're right. In practice I usually C-/ (undo) C-g / (redo) to get back to where I was; which is something you can do after you've lost your place in the file, but it assumes to previously made some change in that location.
To add to this, there's a set of Winetricks recipes for running SM on Linux.[0] (Disclaimer: I haven't tried them, though I've been planning to, for a while.)
XMonad's[0] default behaviour of being able to separately tell a program to go "fullscreen" (i.e. hide most UI) and control what portion of the screen its window takes up is extremely valuable, since many programs don't give you the option of separately hiding their UI, and it's only possible by making them go fullscreen. However, being able to hide the UI is actually most valuable when there is more than one window on the screen... This is especially important when you have a small (or average-sized) screen, but it's also useful on larger ones to avoid distractions.
Getting the "normal" fullscreen is just two keyboard shortcuts away ("fullscreen" the program and assign its window the entire screen), rather than one. From an intuitiveness point of view, being able to hide a program's UI and change its window size separately is arguably more intuitive — according to the separation of concerns, the former is managed by the program itself and the latter by the WM.
PiP is really nice, but videos aren't the content for which getting a distraction-free experience is most important...
[0] I'm sure that it's also possible with other tiling WMs such as ratpoison, stumpwm, awesome etc.
I second the mpv-based solution, as suggested by st1ck. If you prefer vlc, it now (as of the beta 4.0.0)[0] also supports dual/secondary subtitles. Making it work seems a bit fiddly: first you need to turn them on (under Tools > Preferences > Subtitles/OSD > Dual Subtitles (at the very bottom) > Align — change to anything but unset, and possibly also adjust offset). Then, when playing a video, to select them for that video, you need to "Toggle secondary subtitle control" with Ctrl+Shift+V (this means that the normal subtitle control shortcuts like "v", "Alt+v" etc. now apply to the secondary subtitles) and press "v" the right number of times to switch to the subtitles that you want.
(Obviously vlc and mpv will only work for DRM-free videos, e.g. from youtube or a DVD.)
If you were asking specifically about Netflix subtitles, there used to be an open source NflxMultiSubs extension[1] for both Firefox and Chromium, but it was broken by Netflix introducing changes to its video player and discontinued. There is an active, open-source dual-captions[2] extension, but it's for Chrome only. (However, since it's open source adapting it it for Firefox should be straightforward.) Finally, as an alternative approach, you could try a Firefox addon which allows loading arbitrary subtitles in the SRT format to netflix,[3] and which might perhaps allow you to have both netflix's subtitles and your own SRT ones at the same time.
> NflxMultiSubs is still working. I wrote a patch to fix it, and took over maintence on Chrome.
That's great! It's a shame that it's (apparently) no longer open source, though obviously given the MIT license you're allowed to stop disclosing the source.
