lwindolf
Change/revert content view
I installed Liferea 1.16.5 today and noticed that the article content view has changed drastically. Is there a way to customize this, or ideally revert to the pre-1.16.x layout? I'd like to restore the article header, the body using the previous color scheme, and the enclosure list displayed as attachments.
The latter is especially important, since now it seems the only way to access enclosures is via an embedded HTML5 player in the content view, but I normally do not want to play audio/video within the content view, and prefer to open audio or video enclosures in VLC or MPV. There does not even seem to be a way to extract the enclosure URLs within Liferea any longer.
I also think that this should be a task of the GTK+ graphical interface, not of the HTML renderer.
Yet, it seems that due to issues with the ever changing policies and infrastructure of GTK+, the developer has decided to deligate some components to the HTML renderer.
My plan is to switch to a web based feed reader and having a rendering stack in JS is very important to me. Also in the web stack the removal of XSLT support a possibility.
https://github.com/lwindolf/liferea/discussions/1456#discussioncomment-14742215
However, I offered to to utilize XSLT for that task.
I am currently working on a publication platform which is entirely made of The Atom Syndication Format.
Please see the bottom of this page (tags, enclosures, related).
https://journal.woodpeckersnest.eu/posts/2004-09-09-trusted-computing-2004/
This is another XSLT stylesheet which realizes a gallery from enclosures.
https://journal.woodpeckersnest.eu/posts/2026-01-01-recommended-xmpp-mobile-chat-clients/
As I stated, I think that it be best for the graphical interface to handle elements suchh as enclosures, provided that it is a reliable graphical interface, such as GTK+2 and not that "trendy" trap that BetHat and BNOME have designed.
https://github.com/lwindolf/liferea/discussions/1394
I have also suggested to replace GTK+ by SDL.
https://github.com/lwindolf/liferea/discussions/1394#discussioncomment-14791221
@jspatz
I want to convert this issue to a discussion.
Which classification may be fit? (General or Ideas)
@sjehuda I think this is a good 'general' discussion. I hadn't seen the thread you linked above, and if what @lwindolf was saying there is the way things develop, that'd be quite unfortunate. I've been using Liferea for years precisely because it is a conventional desktop application, and not a webapp. In fact, I'm already using a webapp (TT-RSS) to provide a centralized database/feed sync backend but almost exclusively using Liferea as my fronted.
I understand the frustration with the direction of GTK+, but that's where I'd hope for a port to Qt (as LDXE did) rather than a port to a web-centric UI. Or something equivalently native, such as one of the SDL-based toolkits you've recommended (and another good example of a desktop app using SDL with a custom GUI toolkit is Lagrange).
In the meantime, though, I realized that it's possible to create a custom liferea.css in the config directory, and have made some progress adjusting the content layout and colors to something a bit more palatable. I expect it should be possible to simulate most of the previous appearance and functionality of the content view with CSS, but still lacking in the ability to restore the attachments panel.
@lwindolf I do hope you're willing to offer a simpler way to restore some of the traditional functionality of Liferea, but otherwise, is there a possibility of enabling customization of not just the CSS, but also the HTML templates, and offer a documented JS API for interacting with application functionality from within the content view?
@jspatz I thought about your use case. I do not want to change the current implementation much, but I still want to address your use case of opening audio/video externally.
GUI-wise this means that for a given list of enclosures you need a way to launch them. I think this should be doable in a web presentation also.
So I'd like to consider this issue more as a regression bug that it is not possible anymore to open audio/video enclosures externally.
@jspatz There is a way to extract the audio/video enclosure URLs by right clicking on the player. This is a standard feature inherited from all browsers.
Of course it is not very easy to discover.
I did want to avoid having a custom player chrome (as this is just another code base to maintain), but it seems without one we run in such UX problems.
@jspatz Finally on the question of user customizing I think 2 things make sense
- Keep doing as much as possible with the user CSS (this already works)
- Add a new GreaseMonkey style user JS hook for more complicated changes
So in js/item.xml.in which contains the layout in form of a Handlebars.js template we could do the following:
- Add the item JSON data as a ld+json structure for access by the user JS
- Provide at least a pre-rendering and a post-rendering hook for a user JS
- Source the user JS from
~/.config/liferea/user.js
This way customization would be
- open to change passed data
- open to remove stuff created by the Handlebars template
- no need to change the internal template!
- open to add totally new stuff
The only interface would be
- the JSON data structure
- the CSS selector ids
- the user JS hooks
Since the owner of this project has participated in this discussion, I will not conduct any action to change the purpose of this thread.
Nevertheless, I want to write a general statement.
I think, that most, if not all, RSS Readers should utilize graphical interface components to present items of syndicated formats.
Additional means:
- Arc90 algorithm (Readability);
- ECMAScript parser; and
- A system, which be similar to Microsummaries XML Namespace, to standardize data extraction from documents that are not RSS.
All these so called "web renderers" (a joke of rendering spider webs upon people) is unnecessary.
@jspatz There is a way to extract the audio/video enclosure URLs by right clicking on the player. This is a standard feature inherited from all browsers.
Of course it is not very easy to discover.
In the XSLT stylesheets of Rivista Voyager and my Greasemonkey Newspaper extension, the enclosures are classified under title "Ecclosure" or "Downloads", so I suppose that it be feasible with Liferea also.
I did want to avoid having a custom player chrome (as this is just another code base to maintain), but it seems without one we run in such UX problems.
If I realize correctly, we can add an ECMAScript module which provides a custom player.
@jspatz Finally on the question of user customizing I think 2 things make sense
- Keep doing as much as possible with the user CSS (this already works)
- Add a new GreaseMonkey style user JS hook for more complicated changes
This would allow faster customization and it would improve the process of realizing new ideas with Liferea.
I want to ask a couple of questions.
- Would that "hook" allow to incorporate Typescript in addition to ECMAScript (i.e. JavaScript)?
- Would it be possible to utilize Node.js modules such as xmpp.js to communicate with protocols that are not of HTTP?
I consider to deliver Greasemonkey Newspaper as a desktop software, to allow to view XML files such as Arom, FOAF, RSS, Sitemap, Twtxt, and even DOAP, as regular documents.
If Liferea would allow the incorporation of ECMAScript, then it would be nice to somehow allow to incorporate Greasemonkey Newspaper with Liferea, and use Liferea to view RSS documents locally.
Preferably as an extension, because the code requires improvements.
https://greasyfork.org/en/scripts/465932-newspaper-syndication-feed-reader
Of course, an XSLT stylesheet of Liferea would be more proper for that task.
https://git.xmpp-it.net/sch/StreamBurner
@lwindolf I've done a lot of CSS customization and got the layout mostly how I like it, but as you pointed out, extracting the enclosure URLs is currently a problem. I think the user.js idea is great, and would be happy to tinker with it and provide feedback as soon as you have a commit ready to test.
@sjehuda If @lwindolf exposes full control of the article DOM via user JS, it should be possible to apply an XSLT via a script in user.js. at that point, the sky is (theoretically) the limit.
Did you examine Rivista Voyager, and did you further examine the realization of "enclosures" with XSLT?
Yes. I agree, that such interface would also allow to incorporate XSLT interpreters such as SaxonJS and XSLT Processor, even though I advocate for a built-in XSLT interpretor, in addition to the ability to add another one with User.JS.
https://github.com/DesignLiquido/xslt-processor
Post script
They sky could really be the limit. That phrase "the sky is the limit", which is not sensible of itself to describe "unlimited options", might be a "PsyOp" phrase to influence people to reject that possible notion, which might be a reality. Search for "℮𐌸⩘ℝ⩟∩Ø⋂" (replace signs with charcter equivalents); it is well worth to watch or listen to.
If my observation is correct, then Liferea appears to be supporting RSS enclosures (I guess, "media:content", and probably "enclosure" of RSS, also), but not Atom enclosures.
Where is the relevant code, so I see whether be able to contribute code for that?
@sjehuda all feed parsing is in src/parsers and Atom enclosures are already supported.
At the moment I would not accept PRs to change the XSLT handling as this would mismatch the current architecture and impact stability a lot. I absolutely want to avoid this.
In the scope of this ticket here I'm open to consider GUI changes. Waiting on feedback by @jspatz here...