Feature - Implemented Stopping auto-scrolling to new posts in chat

H

Hairy

New member
Mafia chat currently scrolls to the bottom of a chat window if any new content is sent to the chat. This makes it difficult to go back and read older material in a busy channel.

It would be nice to have an option to prevent this behaviour. A bonus luxury feature would be some indication that new content has been received when scrolling is disabled. Would such a thing be practical?

Cheers
Hairy
 
I'd like to see this same feature request applied to the gCLI: when a verbose or intensive script is running (or automating adventures) it can be a SUPER hassle trying to go back up and read something that catches your eye without halting outright.
If the gCLI could be logged like chats and loaded into the browser via quick button that would work (though I wouldn't want the gCLI to be saved from day to day like chat logs... way too many files of mostly repetitive info) and, if the gCLI worked like chat, wouldn't that help alleviate the problem of ambiguity that was had with the amount of memory dedicated to the gCLI history? I don't actually really know how it works, but chat seems to be logged as far back as one is logged in without problem so I'd assume similar would be possible for the gCLI.
 
I think the proper UI design is to have the bottom of the scrollbar "sticky" but the rest of the scrollbar non-sticky. This may be a JRE limitation, I'll look into it.
 
I sometimes get that by error (well it sincerely looks like an error) where the bottom of the CLI is the only thing that scrolls and the top is locked for some reason. Restarting Mafia is the only way to get out of it. It doesn't stop me from doing anything, but it looks odd. Not happening often enough for me to verify it as a java-bug (which is most likely is) or a mafia-one so will not report it more officially than this :)
 
bordemstirs said:
If the gCLI could be logged like chats and loaded into the browser via quick button that would work (though I wouldn't want the gCLI to be saved from day to day like chat logs... way too many files of mostly repetitive info) and, if the gCLI worked like chat, wouldn't that help alleviate the problem of ambiguity that was had with the amount of memory dedicated to the gCLI history? I don't actually really know how it works, but chat seems to be logged as far back as one is logged in without problem so I'd assume similar would be possible for the gCLI.
Click to expand...

Slight veer. Much of what is written to the gCLI is also written to the Session Logs so I'm not sure what "though I wouldn't want the gCLI to be saved" is supposed to mean since it already is. If I were going to make a FR I would ask that everything written to the gCLI be "unHTMLed" and then written to the session log.

My recollection from tweaking the buffer size is that the gCLI and Chat share much of the same underlying classes so I'm not sure that it is really true that the gCLI does not work like Chat. A specific example where that is true might suggest some easy code changes to make them work the same or provide reasons why they should be different. By the same token I'm pretty sure, as the person who did it, that the buffer sizes for Chat and gCLI are the same so if there is a different experience between the two as far as scrolling or how far back things go then it is almost certainly related to data volume and not code.

In Ye Olde Ancient Tymes many tools that displayed scrolling output would let you pause and resume scrolling using ctrl-S and ctrl-Q (IIRC). However before multi-threading that would sometimes pause the underlying process. Inevitably, the solution was to tee the output to a second process and pause that process or write everything to a file and use tail -f (again, IIRC).

Since KoLmafia is multi-threaded I wonder if this should really be a FR that it be possible to pause all scrollable buffers and scroll back without pausing the underlying process or losing output from it?
 
From my viewpoint, Holatuwol's suggestion would definitely be an improvement on what currently exists, but Roippi's would be much more elegant. Thanks for thinking about this.

Cheers,
Hairy
 
It seems a little bit _too_ keen to stop scrolling at this point. I think it sometimes even decides to stop when I haven't scrolled up -- I haven't figured out exactly what's going on, though. It might be reasonable to require the window to be scrolled up as much as 10 lines before the stop is applied.

Thank you very much for implementing this.
 
Made a couple of changes that should address the issues. There was an unfortunate race condition between swing and the chat system.

I increased the dead zone from 50px to 300 px. As you point out, you likely still want autoscrolling if you're only scrolled up a line or two.
 
Yeah I'm pretty pleased, it "feels" right.

I might look into some other tweaks. If you have a chat tab open and have scrolled up, there's no indication that a message has been received on that channel (other than the scrollbar getting incrementally smaller). I'm trying to think of what would be a good indicator.

Also, if you're scrolled up and enter a command (chat or gCLI), the display should probably pop down to the bottom?
 
roippi said:
Yeah I'm pretty pleased, it "feels" right.

I might look into some other tweaks. If you have a chat tab open and have scrolled up, there's no indication that a message has been received on that channel (other than the scrollbar getting incrementally smaller). I'm trying to think of what would be a good indicator.

Also, if you're scrolled up and enter a command (chat or gCLI), the display should probably pop down to the bottom?
Click to expand...

Could you print "Channel X has new messages" to the Events tab and thus highlighting that? Won't work if you scroll a bit up on that I guess though.
 
You must log in or register to reply here.
Back
Top