roost-im / roost-client Goto Github PK

Narrowing and then un-narrowing at the same position (or close to it) is a really common case. We should avoid flashing the "Loading..." bars by holding on to the previous message list. Probably we should separate MessageView into yet another model/view split. The middle model manages tails and cache state. #10 might benefit from this too, as an animated transition would want to hold onto both of them briefly.

Actual release is out now.

What the title says. Roost is currently unusable for sending from a touchscreen-only phone. (I have long heard of a way to pull up the keyboard anywhere in Android, but I have always found it to be a myth when I tried to use it on the devices I interact with.) This should be very high priority. Compose should be easy, reply is a little less clear. If we go with the Humbug "click on message" version, it could be tough to select/copy text from messages. Maybe just a little "reply" link in a corner of the header or footer of each message......geez this is getting a lot like a forum UI now :P next we'll have a "quote" button....actually, that's not a bad idea

Uh, yeah.

Uh, what?

Angular seems to blow up. Not sure why yet.

Incorrectly filed as davidben/webathena#62

It's kind of a pain, but I think it would actually work for us because we're all static content. Might be worth looking into.

I forget the exact wording and was dumb and refreshed, but I got this error trying to send a zephyr and the UI got stuck: Error checking zephyr creds: request failed

Look into what that's about and why the error-handling's not working.

Done on the client, of course.

Might be related to the new MutationObserver thing. Unfortunate. Maybe revert that along with #20... still need a DOM-based templating system though.

The auth tokens last about a month, compared to tickets which (even after renewal is implemented) about a week. We should cache the auth token in localStorage too. Do not prompt for a new server ticket until the token expires. Of course, if we need a zephyr ticket for an action, we'll have to prompt early. But if you have a client you're only using the read zephyrs and periodically send, let's avoid prompting.

Should jump less

Shouldn't be too hard.

Monospace fonts are silly. But zephyrs are currently displayed in them. Can we do something nicer with that and line-wrapping and the like?

Figure out what happened there. Maybe set up some timeouts, I dunno. I had to manually clear some variables and unthrottle.

Siiiiiigh.

Yeah, those would be handy.

See if it's worth an optimization to close sockets on idle. Do it when all tails are full or perhaps when visibility events say we've been idle for a while? Mumble server push mumble? Mostly I'm thinking about mobile here.

Balance this with state change notifications when we get around to doing that.

Uh, yeah. Been careful to avoid/polyfill anything that's not in IE9, but I should actually test it.

It makes me sad as far as layering goes, but would solve the current focusing problem. It also doesn't seem like Chrome knows to composite them yet? But they should fix that, and they seem to be working on it...

Surprisingly enough, browsers don't like it when you infinite-scroll from the top.

Can we do anything about this? Hide the scrollbar and build a fake one? Detect when you're using the scrollbar and delay doing anything to the top until the user's released. As it's kind of a nightmare.

The latter doesn't seem that terrible of an idea. We can even change the loadingAbove_ text to say something like "Release scrollbar to continue."

Actually detecting the scrollbar would probably require ALL THE HEURISTICS, but that's fine. Mousedown down on the right 10px of the screen or something.

Add UI and backend support for:

• Setting a custom zsig
• Setting a bunch of them to select randomly
• A URL to do an XHR to

That would be kinda handy probably.

Client should check for new versions of itself and ask to refresh when appropriate.

No, seriously.

Hitting shift-v doesn't keep the scroll constant. Only on retina, so it's probably some rounding problem.

After spending two days fighting with Angular. :-/ Problems with it:

• Memory usage is completely unbearable. There was that jQuery memory leak, but that's fixed. I think this is just Angular now.
• I'm not super-convinced of The Angular Way. It makes it very hard for ancestor components to communicate with descendants. I keep having to broadcast ad-hoc events. I'd rather just send a targeted message.
• Digest cycles are way too slow. I have to bypass most $apply calls and replace with manual $digests. But since a lot of stuff happens at the top-level controller, every time that changes, I still have to digest all the messages. This is pretty pointless, given that the messages very rarely change. Of course, part of this is probably that I'm using CSP mode, but I'm not losing that.
• Fundamentally, I don't need the magic two-way binding for a lot of this code. It's handy, but not strictly necessary for the meat of the app, namely the message list.
• This thing is way too complex, and the documentation isn't good enough to compensate.

Requirements for new thing

• More performant than Angular (shouldn't be hard)
• Templating uses DOM, not innerHTML + escaping
• Works with CSP

http://blog.getbootstrap.com/2013/08/13/bootstrap-3-rc2/

They renamed some things.

When narrowing by clicking a message, that's obvious.

For widening by mouse, consider something like

1. Track the last message used to narrow (either by keyboard or click).
2. Clamp that message to the screen.
3. Use that as the anchor.

When narrowing (or switching to an uncomparable view) by, say, a search box or subs list, maybe something like... find the first (last?) message on screen that matches the filter? Or perhaps the heuristic above? Not sure. Probably depends a lot on the particular filter feature.

Managing your scroll position is a problem right now. The recent positions was an experiment to automagic multiple head positions, but it seems to not work well. This bug will serve as a dumping ground for random thoughts.

Some use cases that should be served, ideally:

1. Narrow to a conversation, scroll around a bit. Unnarrow to the state you were at before narrowing
2. Having two tabs to Roost should do something... vaguely sane?
3. I have a work filter (okay, ignoring the part where our filter system sucks right now) and a normal filter. I want to keep track of both scroll positions. Read through the work filter during work, when I get home I want to read the normal filter from where I was then.
4. Read messages on another device. Going back to your first device should offer to jump you ahead.
5. Press home/end to jump to top or bottom. Return to where you were previously.

One thought: several operations should push the scroll position into the back/forward history. Or something more explicit in the UI so you don't accidentally go back past Roost. That would honestly handle a lot of use cases.

The current scheme tried to make having multiple saved scroll positions do some auto-fork thing. It doesn't seem to work well. Specifically, it makes 4 up there hard and doesn't make much sense. For reference, this is how it works:

• Store the last 5 scroll positions. Scroll position includes current filter.
• You start from some scroll position. When you scroll, you replace the previous scroll position with the new one.
• When syncing with the server, if there's a conflict and, when you update to most recent scroll state, the position you branched off of is gone, you still insert your new position. This way devices naturally fork the position history if you open two tabs and scroll independently. And we keep track of the most recent 5 heads.

While scrolling, I'll see the bubble for "Roost could not verify the sender of this message." appear in the left (the right edge of the bubble covers the first few characters of a class name) randomly. It appears there without prompt. It cannot be dismissed as far as I can tell.

UI is temporary, but sometimes the reply box covers the message. Probably similar logic to what we'll need in #13.

Anything where the browser jumps around for you gets in the way of the infinite scroll and triggers more loads. What can we do here?

That would be kinda fancy. And help a lot for visualizing things.

like humbug, would be good

when I narrow into a class/instance meme this is helpful for seeing what is really old and what is continuous

Bootstrap's column system is nice, but I actually do need it measured in pixels.

Also color-blindness is a thing to worry about.

Seriously. Also replace with sleeping owl gif or something equally amusing.

Apparently if you suspend and resume, Chrome or SockJS or somebody doesn't notice that WebSockets are now disconnected? Figure out what's going on here.

Apparently you can just tell chai.js to use assertions instead of this weird should thing. Let's use that. It makes more sense. Also mocha can be configured in "TDD" mode instead of "BDD" mode, but it's not clear that makes much difference.

Not necessarily things that would be good to do, but things that would be funny...

• Parse out /mit/davidben/Public/barnowl.jpg into /mit/davidben/Public/barnowl.jpg.
• Parse out foo^H^H^Hbar into foobar

We should have some standard styling, maybe an emblem and/or a color change, on buttons that require zephyr/zephyr tickets and, because existing ones are expired, would request new tickets. We can add some Bootstrap-y tooltip on hover to explain in more detail what's going on there. This way users are hopefully not completely surprised when they get a popup like that.

Could also decorate the login buttons with that icon too to drive the point home that that icon means Webathena prompt.

Seems getting a ticket from Webathena doesn't always goes through? Not sure yet what's going on.

WebKit/Blink doesn't do smooth scroll of overflow; scroll divs. Firefox does, actually. It's much easier to visually page down through them with a bit of animation there. Consider UA-sniffing and faking the smooth scroll.

Yeah, what that says.

Still need to figure that out.

States should not get rekeyed if they didn't change. In particular, just opening roost and not scrolling shouldn't do anything. Or selecting a state in the dropdown.

Alternatively, it should do something (namely move the state to the front), but it shouldn't change the id unless you've scrolled significantly.