Quote from: JiiBs on September 10, 2024, 09:09:17 AM

So it’s more like a tracker or compiler that places focus on a user of interests comments within a thread and sort of filters it out.

That's a great suggestion... In fact, I'd go so far as to say it's a superb suggestion. Actually, screw superb, that's the kind of suggestion that defies single-adjective description. It's the kind of suggestion that could only have formed inside of a beautiful mind. Which is probably why I did it back in 2022. Tongue

All kidding aside, yeah, that's a good idea, and it's something I once tried, and plan to try again in the future. My first attempt went wrong because:

(*) I've been hacking on code for a really long time, but I haven't done much with PHP, so when I started to dabble in SMF patches, I kind of just treated PHP like it was dynamically-typed C and didn't really bother to internalize any of its idioms or learn much about it. The first patch I sent theymos for this contained a small mistake that convinced him that if he examined it more closely, he'd probably find other mistakes, too. (Something to do with not handling non-scalar URL parameters, IIRC.)

(*) The particular files that need modifying contain many differences between theymos' baseline and mine. That means that theymos would have to take a lot of time to carefully extract the relevant changes from a set of diffs that won't correspond very closely to his source code, and then carefully splice those extracted changes back into his modified files, while also trying to consider all of the hazards that I'm unable to see and account for from my end.

I think that if I took another stab at it now, with the benefit of more experience, I could probably produce a cleaner patch that theymos would be more likely to merge. But, my plan is to see if I can first get him to merge basically the same feature for PMs (because that code agrees more closely between our branches), before attempting to get him to merge the feature for posts.

Anyway, long story short: It's a good idea that I hope to be able to get past theymos at some point. Wink

Quote from: un_rank on September 10, 2024, 10:17:40 AM

I noticed that if you do not fill in a bitcoin address in your forum profile information,'Bitcoin address' it does not show up on your profile at all, can the same be done for (...)

I like that idea.

The thing is, though, that even when a fresh set of eyes can tell that something looks goofy/wrong, to the people that have been staring at it for many years, that wrongness can look comfortingly right. Cheesy

It's one of those ideas that, while I personally like it, I'd feel better if some others chimed in about liking it, too, before I spend time on it.

Quote from: un_rank on September 10, 2024, 10:17:40 AM

Secondly, I have always been curious about the local time displayed on profiles, is it set automatically or defined by those that add time offsets to their profile?

The latter.

Quote from: un_rank on September 10, 2024, 10:17:40 AM

And is there a reason this is public?

As I understand it, it's displayed there so that people can guess at your typical availability.

I suppose, not being able to set your own time offset without also revealing it to everyone is (as you said) not ideal from a privacy perspective.

I could add a new "Show others your local time?" profile-setting, but I'd like to see some support for that idea from other members before working on it.

Quote from: un_rank on September 10, 2024, 10:17:40 AM

The final little bug, if we are going to have N/A for age that is not filled in, why not have it for any other detail not available on the profile?

I think maybe just abandoning the "N/A" idea is better than spreading it to other fields. Then, the rule could be (relative to your earlier proposal) that if something is blank, just don't show it at all.

As an example, instead of my profile looking like this:

It would look like this:

(I left the signature field because I'm used to seeing that at the bottom and it looks pretty odd to me without it, and also because removing it affects the table layout a little too much.)

Quote from: bitmover on September 10, 2024, 06:19:03 PM

Hello PowerGlove!

Hi.

Quote from: bitmover on September 10, 2024, 06:19:03 PM

I noticed that these icons are not always displayed correctly.

Nice catch!

Quote from: bitmover on September 10, 2024, 06:19:03 PM

I see the same inconsistence in the Updated Replies page.

Yup, that's actually the source of these inconsistencies, I think...

I'm pretty sure (educated guess) that the watchlist feature relies on the code in Recent.php, and that code has a section near the bottom that looks like this:

Code:

if ($is_topics && !empty($modSettings['enableParticipation']) && !empty($topic_ids))
{
$result = db_query("
SELECT ID_TOPIC
FROM {$db_prefix}messages
WHERE ID_TOPIC IN (" . implode(', ', $topic_ids) . ")
AND ID_MEMBER = $ID_MEMBER", __FILE__, __LINE__);
while ($row = mysql_fetch_assoc($result))
{
if (empty($context['topics'][$row['ID_TOPIC']]['is_posted_in']))
{
$context['topics'][$row['ID_TOPIC']]['is_posted_in'] = true;
$context['topics'][$row['ID_TOPIC']]['class'] = 'my_' . $context['topics'][$row['ID_TOPIC']]['class'];
}
}
mysql_free_result($result);
}

That $is_topics variable is a (badly named, IMO) boolean that's true for ?action=unread requests and false otherwise (so, false for ?action=unreadreplies requests, and presumably for ?action=watchlist requests, too, depending on how theymos did the watchlist code). So, those little faces will appear correctly for "Show unread posts since last visit.", but they won't appear for "Show new replies to your posts.", probably based on a performance-related decision to skip that query for ?action=unreadreplies requests...

I can see why the SMF devs might have done that, because, in that context, you must have posted in each of the displayed topics, and it's silly to run a query for an answer that you already have. What I don't get is why they didn't (when $is_topics is false) just loop through all the topics and do a $each_topic['class'] = 'my_' . $each_topic['class'], though.

Anyway, now (again, just guessing) that this code affects the watchlist, too, I think it makes sense to simplify that if-guard, and allow that query to run in more contexts, so that the icons are always correct and agree with the icon-legend at the bottom of each page. That's as simple as theymos commenting-out the $is_topics part of the condition, like this:

Code:

if (/*$is_topics &&*/ !empty($modSettings['enableParticipation']) && !empty($topic_ids))

While I'm on this subject, I think that those two links ("Show unread posts since last visit." and "Show new replies to your posts.") are very badly titled/named. The first one suggests that you're going to see posts rather than topics, and the second one suggests the same, but for replies to your posts.

Really, I think the first link's text should be "Show updated topics since last visit.", and the second link's text should be "Show updated topics that you've posted in.", both of which better reflect what they actually do.