These podcasts have been strangely amusing to listen to.
I just wasted a bunch of time reading about various Windows phones throughout the ages. I'm not sure what I expected, but it wasn't a very interesting process.
Regarding SyncTERM, maybe it could allow for user-configurable keybindings. (This isn't a feature that I care about, but it might resolve the complaint that Deuce mentioned.)
Website suggestions:
Drop the Subject field from the Comments area in episode.ssjs, or add a line break between the Subject and the comment textarea.
Use something other than Stocktastic - maybe a nice Nightshade theme. Or HotDogStand - I could bring that back.
You could probably combine the Home and Episodes pages into one, perhaps with a smaller version of your graphic at the top. The current Home page isn't really doing much.
Regarding SyncTERM, maybe it could allow for user-configurable keybindings. (This isn't a feature that I care about, but it might resolve the complaint that Deuce mentioned.)
Drop the Subject field from the Comments area in episode.ssjs, or add a line break between the Subject and the comment textarea.
Use something other than Stocktastic - maybe a nice Nightshade theme. Or HotDogStand - I could bring that back.
With SyncTERM, I think a simple key-mapping would suffice and be pretty easy to do. Deuce, I'm sure, feels differently.
Re: Episode 3: Kibibits and Mebibits and Little Lambs Eat Ivy
By: Digital Man to Echicken on Tue Jul 28 2015 05:13 pm
With SyncTERM, I think a simple key-mapping would suffice and be pretty easy to do. Deuce, I'm sure, feels differently.
I've never seen a key-mapping interface I really liked. The whole menu system to do that is what would be painful, not the code to handle configured key maps.
Audio synchronization fixed, but no noise gate used this week (sorry).
techdorks.net) and I noticed that the "security headers" are missing from the message. These header fields identify the sending client (hostname, IP address, etc.) and the protocol used (in this case, I'm assuming HTTP).
I'm guessing this is because the call to MsgBase.save_msg() isn't being passed a "client" instance (from where it pulls the data for the security
Yeah, I had initially played with that, but wanted to hold off a bit until I saw if people changed the subject at all. This is much more likely to happen with posts through the web interface than posts via DOVE-Net.
I've never seen a key-mapping interface I really liked. The whole menu
Re: Episode 3: Kibibits and Mebibits and Little Lambs Eat Ivy
By: Digital Man to Echicken on Tue Jul 28 2015 17:13:07
techdorks.net) and I noticed that the "security headers" are missing from the message. These header fields identify the sending client (hostname, IP address, etc.) and the protocol used (in this case, I'm assuming HTTP).
I'm guessing this is because the call to MsgBase.save_msg() isn't being passed a "client" instance (from where it pulls the data for the security
I can offer a 99% guarantee that no 'client' instance is being passed to MsgBase.save_msg() in whatever part of ecweb saves a message. I didn't even know that was a thing that could/should be done. Would be an easy fix if that's all that's needed.
But now that I've discovered that you're using the Entertainment sub, I'm ju replying from my BBS. That web shit is for suckers.
Audio synchronization fixed, but no noise gate used this week (sorry). Miscellaneous topics including SyncTERM, Apple Watch and Windows Phone. Enjoy!
http://mp3.techdorks.net/episodes/techdorks-2015-07-28-ep3.mp3
I've known maybe one person who had a Windows phone. He was really into it and really liked it.
Damn. I guess that means that there isn't going to be some sort of fix for setting that last read message pointer, threaded messages or no. :'C
It wouldn't be a fix as much as an added feature (it's not as if ecweb
is meant to do this right now yet doesn't.)
Because it's a pointer and not a per-user per-message read/unread flag, I'm not crazy about what the reality of this feature would look like.
By clicking on the top thread in a given sub, which would contain the newest message, you would essentially mark all previous messages as "read". It'd be like jumping to the last message in a sub from the
prompt on the terminal side, except not as obvious since you're not browsing messages sequentially.
But then again I rarely use the web interface and this wouldn't affect
me much.
If this is how people want it to work, then that's how it can be. I don't recall if there was any consensus about the proposed feature.
cons. I hadn't thought of the fact that threading marking all messages below a current read would mean _all kinds of stuff_ would get marked as read. I don't know, though, maybe this would be the best, if there were a
I don't use the web interface at all any more, but I have a couple of users who won't come back until I have it enabled again. I can't do that
because of the network that I'm on right now, but when I can do it again
the lack of marking of any sort of new reads was really bugging the hell
out of them. I think an optional checkbox, signifying that it'll be writing the last_msg pointer or whatever, and that it'll contain messages from other threads below (if threaded) would be a good work around without re-engineering the whole capability of synchronet's MsgBase capabilities.
What I will probably do is place some kind of indicator on threads that contain new messages. These threads will always be at the top of the list when viewing a sub. Users can start by reading the bottom-most of these threads, then work their way up.
I used to have a "new message scan" on an old version of ecweb, but it was shitty. The concept didn't carry over to the web very well.
So you had people who were interested in using your BBS as a discussion forum, but not in the traditional textmode BBS way? That's kind of neat.
As in ... your ISP won't let you serve a website?
Fair enough - an indicator for threads containing new messages would help them, but of course pointers would need to be updated for that to be useful.
This would essentially require a 'settings' page to be created, and per-user settings files to be created (as needed) and consulted at various times. It wouldn't be a lot of work, but I feel like it would be a bit clunky and the wording surrounding this particular setting could be confusing. I might rather skip all of that and just update pointers as needed without approval. With appropriate visual cues, I suspect most users would figure it out. (Or not - but if they can't, I won't have much sympathy.)
What I will probably do is place some kind of indicator on threads that contain new messages. These threads will always be at the top of the list when viewing a sub. Users can start by reading the bottom-most of these threads, then work their way up.
Shit, that'd work. I mean, I'm assuming that you're talking about with last_msg/applicable pointer updating too, I mean.
Yeah I think we discussed that a bit earlier. I never really had thought through some of the real problems that would exist with implementation of it from the web-interface side before that. Were you like AJAXing that or using a static page? And was it threaded? Just curious...
point seems to be that they just don't want the trouble of trying to learn a new text interface, but they want the interaction that I've got on my
Nah, the admin of the network that I'm on. As in my roomie. He's rather.... particular.... about the services that he runs on his network. ...
as it is. If you want to flame him for it, I can get him to log in long
Yeah I guess I was viewing it more as just a lone standing checkbox... I've got a really horrible head for working with UI, though, so my ideas
Thanks for even considering this, echicken. I thought you were out of the game on this one. Even if the code doesn't happen, I appreciate the
The IMAP server has a thing that stores all seen messages (for non-email). I'm not sure if I've tested it.
Yes - an indicator of which threads contain new messages, then updating them as they are viewed.
I think that the new message scan that I had did provide a threaded view. IIRC it was pretty clunky. There was probably some AJAX involved, without the AX part. I don't really remember - it was part of the first version I think.
Well, I guess you need to give the users what they want. Pointing and clicking can be fairly intuitive. All the same, I've yet to meet a textmode BBS interface that stumps me for more than a few seconds - but then again I'm an enthusiast.
I've hung up my flamethrower for the night, so I'll leave it where it is. I don't see what the big deal would be, but then again I am not as particular as some. I ignore the incessant hack attempts and search-engine crawlers that seem to drive other people around here nuts, and am no worse off for it (so far so good, seven or eight years on.)
I'm a bit reticent to introduce a vague "Update pointers?" checbox into the login sidebar module, and likewise to introduce a "Settings" page with only one setting on it. I figure visual cues plus experience should be enough. Others may disagree. I welcome differing opinions, because mine are not strong on this matter.
I'm still around. My time is spread between work and a bunch of other projects, but I will still make bugfixes and feature additions when I can.
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 333 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 02:26:09 |
| Calls: | 574 |
| Calls today: | 1 |
| Messages: | 235809 |