[FR]: Option to enable/disable full text title

[Starboy-Xo]

Brief description of the feature request

Hello,
This RSS application is very useful and meets almost all the needs.
But there's one thing that requires improving is that it should have an option to enable /disable full text title.
This feature can help us decide whether to dive into the feed or not.

Many thanks.

[martinrotter]

an option to enable /disable full text title.

What is "full text" title? Can you perhaps give screenshot with red rectangle to see what you mean?

[Starboy-Xo]

This is full text title that I talked about:

While, this is the currently working truncated title:

It is better to have an option for both, so everyone can choose any at their convenience.

[martinrotter]

So you say that text should optionally be wrapped (multilined) and not truncated/clipped?

[Starboy-Xo]

Yes, Exactly.

[akinokonomi]

@AmmarSaleemG You can hover the title and there will be a tooltip with full article title.
Does it works for you?

[Starboy-Xo]

@AmmarSaleemG You can hover the title and there will be a tooltip with full article title. Does it works for you?

Yes, but having multiline text instead of hovering over every row can be more precise and clear, which can help us choose whether to open the article or not.

[akinokonomi]

having multiline text instead of hovering over every row can be more precise and clear

More confusing and messy, I'd say. Try to imagine that—oof, scary.

hovering over every row

Why do you need to hover every row?
But even if you do need, tooltips in Qt are really amazing, just try using them.
They were added for this exactly (#511 , #513).

[Starboy-Xo]

Try to imagine that—oof, scary.

The one I am using currently has this feature, and it doesn't look scary to me at all, I guess.

Well, it might look scary to you. Therefore, you can turn it off. It is already suggested to add an Option to [Enable/Disable] it. So everyone can use it according to their convenience.

[akinokonomi]

@AmmarSaleemG, But the UI on screenshot much differ from that of RSS Guard, and multi-line titles really does not look out of place there.

Well, it might look scary to you. Therefore, you can turn it off. It is already suggested to add an Option to [Enable/Disable] it. So everyone can use it according to their convenience.

I assure you, there is no need for a condescending tone.
I've simply made a suggestion.

[Starboy-Xo]

@akinokonomi I had no intention to hurt anyone's feeling. If I did, I apologize.
I would still request to implement this feature. So, people choose their text style (either multilinear or truncated) of their liking.
Best regards.

[martinrotter]

It is fair to say that this ticket is more or less similar to some other tickets which all want the same - more modern list of articles.

#568

[martinrotter]

One more thing. Purely technical one - current list of articles is designed to be quite performant with even 50 000+ of articles displayed IN SINGLE LIST. One of the key optimizations is that ALL items in the list must have same "height". If I would allow for multiline items, some items might naturally have different height etc. which would penalise performance.

I am not against this ticket, we just need to think about it deeply.

[Starboy-Xo]

The Card view suggested in #568 will also be of limited height to prevent irregularities in height, unless you add a Read More button that opens a Modal that draws the whole content in it, which is another hassle in terms of time.

I am using nitter to convert Tweets into RSS feed. Hence, lengthy title. Even they attempted to truncate the Tweet to 32 character length. Which I opposed and after through discussion from many contributors, it was reverted to full text. See here.

The fact that when looking into the titles, we construct a decision whether to spend time in reading the tweet or not. In full text title, we can decide halfway whether to pay heed to it or not.

Now coming to the height problem:
It is correct that they will have different height. But as a matter of fact, the UI will be more comprehensive (in terms of description) and responsive (in terms of technicality) according to the requirement of the title. It will be more appealing.

[martinrotter]

You don't get. Setting all items to same "constant" height is an optimization to allow list to contain huge number of items and be still relatively fast. If each out if 50 000 items has different height, the app must perform crazy number of graphical computations, killing performance entirely.

[Starboy-Xo]

I totally understand it.
I have just a basic level of development knowledge. But, I have a question: Is there any way that we use mathematics in adjusting the height automatically on each feed fetch?
Such as; Count the characters and multiply them with a value to draw a max height (example: 80 char Multiplied by 2 = 160px Height) and save that height into database. Then on each start, while fetching everything through database, fetch the height as well and set it right away (May prevent some performance issue).

Besides, if it is added as an option, I can compromise performance over readability.

[martinrotter]

Yes, that is possible, I can calculate the height of "first" item in article list and then set this calculated height to all other items. This way I could for example force items to be two lines tall, two lines should be "enough" for most of titles, right?

[Starboy-Xo]

Yes, two lines should be enough.
Although, this will bring a drastic change to the UI, where you will have to align everything vertically to the center (icons, text, author, date, etc.), otherwise everything will look messy. So, you have to be mindful of that.

[akinokonomi]

I had no intention to hurt anyone's feeling. If I did, I apologize.

@AmmarSaleemG, No problem, sorry for misinterpreting your words.

I can calculate the height of "first" item in article list and then set this calculated height to all other items. This way I could for example force items to be two lines tall, two lines should be "enough" for most of titles

If it goes to this, why not incorporate it into a "Article list row height" option?

That is, if row height to font size*1.5 (where 1.5 is common row height) ratio is more than 3 (making it less does not make sense, as it will look messy), split every column of article list item in two rows, where is possible.

For example, 50:(10*1.5)~3.33

EDIT 1: Oh, but it still should be enabled separately, e.g. "Allow line splitting in article list," as someone may like to have big lines without line splitting.

EDIT 2: Well, likely someone would like to see customizable row height value, too. In this case, ratio should be two times higher than value of font size * row height.

Sorry, but I still think that if article list would have items of different height, that will make a mess.

[Starboy-Xo]

@akinokonomi Agreed, it would be a mess given the current complexity of article list structure as propounded in comment by @martinrotter in #571.
Yet, I would say that our application UI should be flexible, containing all the features.

In the future, I will also suggest:

• A desktop news widget or a news ticker (similar to this) which may have the ability to run selectable feeds in various windows.
• A support for Urdu language
  • Support for Script (Noori Nastaliq) type font for Urdu(Pakistan).

[martinrotter]

@AmmarSaleemG Does this look better (notice multiline items)?

[Starboy-Xo]

Perfect!!!

[martinrotter]

Will post one alternative, then we choose.

[Starboy-Xo]

Sure, waiting.

[martinrotter]

OK, or this (item height automatically adjusts to text height)

This approach might have SERIOUS performance issues when used with big number of articles in list.

[Starboy-Xo]

It's beautiful, this should be implemented.

[martinrotter]

which variant, same size (first screenshot) or variable size (second, with potential performance issues)

[Starboy-Xo]

I choose second one, it is cleaner and more appealing.

If possible, add both as option, so people can choose according to their system speed.

Thanks in advance brother!

[martinrotter]

About to push changes.

Now, note below screenshot with rectangled options.

1. When first option is enabled, the article list will word wrap long texts and display as multiline when needed.
2. If you keep "article list row height" to value 0 or -1, then each row item's size will be computed dynamically. If you, however, set, this option to some specific number, then all rows will be set to that number. This allows you to make all rows same height, but allow for multilines at the same time. Keeping this to 0 or -1 may result in performance loss.

Difference when 2nd option is changed:

[martinrotter]

95a5341

[Starboy-Xo]

@martinrotter Hello,
It is duly requested to read it all.

I have been on this feature for few days now, it is great as for readability, truly appreciate this addition.
However, I would still request a little more workaround on this feature for further refinement.

First, let's take a look into these photos.

Referring to Pic 1:
Setting in the picture below is Article Row Height = 61px. Which gives a nice space between the borders for three liner texts. Truly incredible. Yet on two liner texts, it looks sufficiently good but more spacious.
But, when you look at that one liner text header, it makes this look truly out of form, unoptimized, and overly spacious.

Moving to Pic 2:
Setting in the picture below is Article Row Height = 51px. Which has shrunk the spaces between the titles, rendering those three liners to look unreadable unless selected (same can be done with 2 liners).

I still acknowledge the fact quoted by you:

You don't get. Setting all items to same "constant" height is an optimization to allow list to contain huge number of items and be still relatively fast. If each out if 50 000 items has different height, the app must perform crazy number of graphical computations, killing performance entirely.

Possible fix

• Auto adjust titles width with two and three liners by Counting words per title.
  • Example:
    • if below 10 words = 10 px
    • if above 10 words && below 20 words = 20px
    • if above 20 words && below 30 words = 30px
    • if above 30 words = truncate the title.
  • it would be far better if we get an option for 2nd and 3rd line to set up Article Row Height manually.

Best regards.

[martinrotter]

So, why don't you try "article row height = -1 (default)" setting? Yes, it might have some performance penalties, but if you do not have great tons of articles, you will probably not see any noticeable differences, my above statement was bit overarticulated.

[Starboy-Xo]

This is how it looks at -1:

The issue is the same, they do not look "Readable". Sufficient spaces are required to separate the articles conjoining above and below

My articles are piling up and i now have 29625 articles.

[martinrotter]

this is not how -1 + multiline should look like, you should not have any "..."

[akinokonomi]

this is not how -1 + multiline should look like, you should not have any "..."

@martinrotter, Please note that it's vertical layout. That is very likely because article browser is closed at the time article list height is calculated.
When user clicks article in list, and article browser appears on the right, it isn't recalculated, and, therefore, article list has overflown text.

Referring to Pic 1:
Setting in the picture below is Article Row Height = 61px. Which gives a nice space between the borders for three liner texts. Truly incredible. Yet on two liner texts, it looks sufficiently good but more spacious.
But, when you look at that one liner text header, it makes this look truly out of form, unoptimized, and overly spacious.

@AmmarSaleemG, To give you some more understanding on how actually limited this feature is, here is the screenshot with list that has Feed column.

As you can see, because of long feed name, every single item in list looks too spacious and unoptimized.

This is only to be expected if you want a multi line items in any list that has column layout.

---

And this is what it looks like when I select some category, a real world example:

Now, does not that look scary, and messy, enough?

[akinokonomi]

@martinrotter, The only way I see to somewhat improve this is to add a setting for some inner padding (above and below text) for list items, on par with article row height.

EDIT : Oh, but I already suggested it here #570 (comment)
I was not clear, after all RSS Guard already has Row height in settings, but by "row height" I meant line height, this https://www.w3schools.com/cssref/pr_dim_line-height.asp

EDIT2 : Though, top and bottom padding would look better, in case with list items.

[martinrotter]

@martinrotter, Please note that it's vertical layout. That is very likely because article browser is closed at the time article list height is calculated.

Yes, this is likely the cause. Height of rows is not recalculated each time some column changes its width, but probably could (and should?) be.

@akinokonomi Yes, "row height" is row height, in total. I am thinking about padding.

@AmmarSaleemG Would implementing "padding" setting be enough to solve the bug? Or do you also need/want to have row height (if set to -1) recalculated when any column is resized (to fix the behavior in vertical layout)?

@also, now texts in ALL visible columns is taken into account when deciding row height -> should this be switched so that only "title" column is taken into account?

[Starboy-Xo]

this is not how -1 + multiline should look like, you should not have any "..."

I haven't changed anything else. This is what it looked like.

@martinrotter, Please note that it's vertical layout. That is very likely because article browser is closed at the time article list height is calculated. When user clicks article in list, and article browser appears on the right, it isn't recalculated, and, therefore, article list has overflown text.

For that, we must use Config.ini file's following elements:

splitter_messages_is_vertical=false
splitter_messages_horizontal=690, 386

We can take benefit from this ^ before calculating the words.

@AmmarSaleemG, To give you some more understanding on how actually limited this feature is, here is the screenshot with list that has Feed column.
Attached Photo 1
As you can see, because of long feed name, every single item in list looks too spacious and unoptimized.
This is only to be expected if you want a multi line items in any list that has column layout.
And this is what it looks like when I select some category, a real world example:
Attached Photo 2
Now, does not that look scary, and messy, enough?

Horizontally, in the sense of additional columns, it is obvious that the things can look messy, I partially concur.
But when one is using the message preview feature with one column attached along with date, this looks fairly good ONLY if inner paddings are correctly in place and vertical widths are calculated correctly taking in account the words' length.

[Starboy-Xo]

@AmmarSaleemG Would implementing "padding" setting be enough to solve the bug? Or do you also need/want to have row height (if set to -1) recalculated when any column is resized (to fix the behavior in vertical layout)?

@martinrotter
• it is important to add padding (better if we have option for it [with -1 as Default])
• Recalculate them accordingly as article title requirement.

@also, now texts in ALL visible columns is taken into account when deciding row height -> should this be switched so that only "title" column is taken into account?

Title column should be taken into account, I don't find anything else useful in message list beside icon and date. Even Author name bloats the feed,

[martinrotter]

We can take benefit from this ^ before calculating the words.

We cannot. If I did and calculated for that smaller width, then you would get overly thick items the other way.

• Recalculate them accordingly as article title requirement.

So only take the "title" column into account?

[Starboy-Xo]

So only take the "title" column into account?

Yes

[martinrotter]

So only take the "title" column into account?

Yes

pushed this, wait for it to compile and test and let me know if better, then we proceed with padding

01efdab

[Starboy-Xo]

Ok, thanks. Let's see.

[martinrotter]

https://github.com/martinrotter/rssguard/releases/tag/devbuild

[Starboy-Xo]

Ok, with -1, now the whole text is visible.
here's the picture:

[martinrotter]

So now, the only thing to close this up is "padding"?

[Starboy-Xo]

Yes, Padding (better if we have option to edit it manually [with -1 as Default])
• Above Padding
• Below Padding.

Both customizable.

[martinrotter]

Really? Is not one padding value enough?

[Starboy-Xo]

Really? Is not one padding value enough?

No, one padding value is not enough. Because, mostly, even in MS Word, we focus on padding (space) below the text. In RssGuard, we have more customizable skins and fonts, so we will customize that as well according to our will.

[martinrotter]

It feels like crazy overengineering for me.

[martinrotter]

Now I realised. It is actually impossible with current approach to make different padding top/bottom, because the drawing itself is not done by me. The text is drawn vertically on "center". Sorry.

[Starboy-Xo]

Ok, no worries.

[martinrotter]

Padding: 6242bfa

test and let know

[Starboy-Xo]

okay, waiting for it to build.

[Starboy-Xo]

Padding value is 5px and it is 100% perfect.

Thanks a lot brother!