Modern Vespa

Ah... that makes sense, and is consistent with what happened here. Thanks for explaining!

If I'm understanding this correctly, this button affects the little grey triangle on the icons to the left of the topic list (the "take me to the last unread post" button), which shows the topics that the user has commented on.

If that is the case, I don't see a connection between the toggle button and the icons in the main topic list, and can understand why you're struggling with finding a solution.

No, not those icons. It applies only to the synthetic "Replied To" index -- the list of topics that you've replied to over your entire history at Modern Vespa. See the image below for the area I'm referring to.

Once you've replied to a topic, it shows up in that list. Additionally, in the topic itself, you'll then have three preference buttons instead of two -- the last one signifying whether or not that topic will show up in the overall "Replied To" index.

The only reason that button is there is that some people rely heavily on the "Replied To" index to keep track of the topics they are participating in, and sometimes you reply to a topic with heavy traffic that you don't want to see coming up in that index repeatedly.

Maybe it would make more sense if it was a much more generalized "ignore" button, though the ramifications of ignoring a topic completely are fairly drastic.

This may appear to be an odd request...

Just like one can 'ignore' a poster's signature, would it be possible to 'ignore' any image posted by a particular individual?

I can't imagine who you have in mind, Jim.

I couldn't possibly comment further.

whoops

Well shit.

Should be fixed now.

ngl, I'm sweating a bit.

Now that you've fixed that can you do me a favour and let me disable that click on an attachment appearing as full screen OR let me pinch zoom it. I keep accidentally tapping and ending up in full screen with no zoom ability whereas when the image is on the page as per normal i can pinch zoom. (Windows and Android).

Oh, interesting.

I don't know that it's worth a preference -- just more complexity. I'd be more inclined to scrap it altogether.

It doesn't even do fullscreen images on iOS -- just desktop and iPad.

I'd be happy for you to scrap it - I too find it pretty damned annoying, especially with touch-screen devices.

What if it were desktop only?

Being impatient I've gone ahead and excluded devices that appear to have touch from getting the image fullscreen behavior. It should now be on desktop only.

Note that this also excludes the iPad, since it has touch.

Excellent - no longer works on my Lenovo laptop.

Most of my windows computers are touchscreen ...

I figured those would be in the mix somewhere.

Isn't it touch that makes the fullscreen feature awkward, though? It seems like that's the main driver here.

But, as above, Windows touchscreen PCs no longer support that annoying full-screen feature, thanks to Jess, so your 'ask' has been fulfilled. Or am I completely misunderstanding the implication of your sentence?

I'm equally unsure if I've grokked the ask correctly.

yes which is why I not only don't want it on phones but also don't want it on desktop. I don't want it anywhere

That's still a little bit ambiguous. I think you are agreeing that you don't want it where touch is active, because of the possibility of accidentally triggering full screen. Is that correct?

This isn't really desktop vs mobile, so let's strike those words from the conversation. This is about touch interfaces vs non-touch interfaces.

I don't want it on anything. touch or non touch.

Why?

Touch or not touch is the main question.

it's just a preference.

ok, never want it on touch device. If it had some zoom support then would like it on non-touch device but otherwise no.

And as that is what is currently active, you have your wish.

nope. on a non-touch pc clicking goes fullscreen but does not give me any zoom controls. in fact depending on the page zoom I had before clicking the image, full screen can be effectively a zoom out.

Okay. Giving up now. Sorry I even asked.

JFC.

It's been the case for literally years that the system by which topic references, e.g.: are turned into topic titles, e.g. ...has been incredibly useful, but also incredibly inefficient. For the one or two topics that might be casually pasted into a post, this isn't a big deal. However (and there's always a "however" in these missives) this completely grinds to a halt when used with even a modest number of topic references.

One thing that might not be apparent is the same system that makes topic references work also forms the literal heart of the MV wiki that I created so many years ago. And with many wiki pages having many tens of links on them, this makes the wiki unbearably slow for link-heavy pages.

And it's been that way for years.

The main issue is that the processing of topic (and wiki) references is amateurishly procedural. I wrote this a long time ago. Probably 15 years, at least. And at the time, it worked well enough, though I do remember distinctly someone creating a topic full of topic references, and it quickly brought the server to its knees.

At some point along the way, I added HTML cacheing of each post to the server's repertoire of tricks, which means that generally only one person has to wait on a post full of links to be processed. This, plus the fact that the server is running on much better infrastructure these days, means that the issue has largely been ignorable.

Except for the @!#$ wiki. the main page of the @!#$ is pathetically slow to load.

So last night I spent all of half an hour remedying this long-simmering issue, refactoring the function that processes the wiki-specific version of these references. To my delight, it actually runs pretty well now.

The new procedure goes like this: This takes the processing of the wiki main page (which used to take, I kid you not) from 125 separate queries down to only 9 or 10. And instead of taking many seconds to load, it now comes up in about 200ms, if the database is warm. Sometimes a bit longer if the database is cold, but still always under 1s.

I am satisfied with that.

And because I can't help myself, I re-wrote the function that does the same for topic references (not just wiki references). This was substantially more complex (because reasons, mostly to do with page numbers and post IDs) but it is also similarly efficient now.

Not that anyone would ever notice in the first place.

I'm not so sure! I, for one, certainly notice how well cared for and zippy MV is. I'm sure many of us feel the same way.

Thank you!

Certainly! I actually was thinking that you might appreciate the wiki improvement, in particular.

The blink is back - it must be a function of the background, somehow (currently Vespa oriented).

I guess we can't rule out some browser-specific reaction to what is admittedly a complex background.

Hmmm.

I'll be curious to know if you detect a pattern to it at all -- some threads but not others, jumping to unread vs opening it up from the start, and so on.

Using the 'back' button or refreshing a thread seem to produce it - among other situations - I can't try everything! At the moment very quick, but when I first came back to MV after 8 hours or so it took a bit longer, so very noticeable indeed, hence the heads-up.

Chrome browser with Adblock Plus, Privacy badger, etc, none of which throw up any concerns so I doubt any contribution - Win 10 64b.

When it's just the usual patterned background, no 'blink' is discernible - but just posting this with the current background produces it. 100ms or less.

It could very well be as simple as the browser running out of cache memory and needing to re-download some of the resources -- triggered by a larger-than-average background image hogging up the space in the cache.

Definitely not sure how to debug this.

Just power-cycled the PC - first time for many, many days, and the blink seems to have gone. So a cache or fragmentation problem might be likely.

Not one to fuss over then.

It still might indicate that the background image is unreasonably large. Which, I mean, it is. So at least I've been warned.