Re: New message indicators
lynx can't show the new message indicators anyway
You are not logged in. Please login or register.
PunBB Forums → Feature requests → New message indicators
lynx can't show the new message indicators anyway
Actually it can. There is some invisible text inside the new post indicators which can be seen on text only browsers or if you turn your stylesheets off.
That is why I hope to use files, opposed to the database.
i think you'll find opening, writing, and closing files will be alot slower than using a database (otherwise why would anyone use databases)
...the mod ShawnBrown made mark topics read it can only mark them unread if your login times out while the session is still open in the browser (i think)...
The script only makes changes if the array info differs from the markup that the php has generated. So yes, it only bothers to mark unread posts as unread after they've timed out ... since they are already properly marked as unread before the timeout.
Here are the possible states and what the script does about them...
- unread & not timed-out: topic id tracked, DOM not altered
- unread & timed-out: topic id tracked, indicator turned-on
- read & not timed-out: topic and last-post id tracked, indicator turned-off
- read & timed-out: record pruned from array/cookie, DOM not altered(using the multidimensional array structure... array[forum-id][topic-id]=x ...where x=0 if unread, or x=last_post_id if read)
...if you went on the site clicked on one topic and closed the browser, then came back 30min later the topics you didn't read would be marked read...
Yes. Though it is possible to extend the persistent cookie expiration time but I've recommended in the install that it be set to mirror the forum's "Visit Timeout" (default: 600 seconds). And I'd be reluctant to suggest turning the expiration time up too much right now as the script treats a larger-than-4k cookie like a buffer over-flow and clears it. But as things stand (with the short time out), the cookie can track at least 250 posts (but probably more like 350+). To exceed the 4k limit, you'd need a forum with several hundred new posts at a time, so this isn't much of a problem with the short timeout and the current pruning.
(I do intend to add large-cookie-friendly pruning in a future version though--to support a more-or-less permanent persistent cookie. But this won't be the default setup.)
I have a working implimentation of this now. It is quite messy at the moment, but will be cleaned up in the next few days. File sizes are a possible issue, I might look into gziping / ungzipping them, but that undoubtably would have a big preformance hit. At the moment, I notice very little difference in performance though. I hope to post a alpha realase in a few days.
At the moment, I notice very little difference in performance though. I hope to post a alpha realase in a few days.
how are you testing it?
Yeah, that's what I do. I hit 'Show new posts since last visit' and then shift-click '[ New posts ]' one topic one at a time.
Ouuuuch.
That's pretty ugly itself, but for the end-users ^^
Isn't the computers supposed to do the grunt work for the users ?
I have used my forum as the testing forum. I am testing it by checking server loads, script execution time, page generation time, and just generally monitering the file sizes on a moderatly active forum. It seems quite flawless at the moment, althogh I am not conformatable with realeasing it yet. Although the code is functional, I am sure there are some bugs there somewhere.
I might of found a good solution to the file size issue - Simply, instead of ziping / unzipping the read posts file on each page view, do it when the user logs off. Although, this could have problems if a user closes the browser window, or similar.
Here's another mod that will clear the new message indicator after you read a post. It works on the server side by keeping track of topics read in the database, but I think its load is pretty light.
PunBB Forums → Feature requests → New message indicators
Powered by PunBB, supported by Informer Technologies, Inc.