For now the idea is that if you're in the search view (or the
subscriptions view) and you click 'New Message', we should
snap you back to the main view.
This may or may not be the right behavior in the long term.
(imported from commit 43c24e1af9e80225ff9be8a62f4c8c925960436a)
Previously we were iterating through all zephyrs twice on the server, now
we are moving part of that to the client so the client has an index of
Zephyrs that it generates itself as part of add_message.
(imported from commit c07a6c36911fa2eae6f216c34331be34b2aa8178)
Take a look with 'git show -w' to ignore whitespace changes,
there are some tiny tweaks to try to make sure we close
tags that we weren't properly closing.
(imported from commit 44cba1b8859842fd85a39a3062963af617556ca8)
You don't care about that content anymore. We probably want to clear
even more aggressively than this.
(imported from commit 29f6910a12e1b722f5801db644b04f54cf5bfd63)
I still don't love it visually, but it's getting there.
Some obvious issues:
Personals window is totally unstyled
Clicking 'new message' should perhaps give you a fresh new window
not something prepopulated with old stuff. Think about this.
(imported from commit 8b28fd084d550db404eabbe63c056fa6866c0697)
Put a little 'x' by the class or class-instance indicator, to make
it more analogous to the planned behavior of the view-in-context
search box.
(imported from commit fa01001cffa6a6094ba5fbdcbdc965addb2efa1c)
The purpose of this is to ensure that we can reference a zephyr by its ID
and get all the data about the zephyr; in the future we may not have all
such data stored in TRs as we do now.
(imported from commit 9128ddd01b46396fd276124ca1e6430538d3dd63)
Today I'm of the mindset that searching is a fundamentally
distinct operation than narrowing, so this reflects that.
(There would be a separate screen and UI for searching,
I guess.)
(imported from commit 432a4088612dafd06184bec228b63056961325dd)
unhide -> show_all_messages
narrow_indicator -> currently_narrowed_to
narrow -> searchbox
This is a little clearer about what these buttons/functions
do, which will be useful as we add a little more complexity
associated with searching.
(imported from commit b51e745ea71c212d6735e04011eaea5e71bf6d5a)
I'm not exactly sure that this is the interface we'll want for
this, but it's the start of an experiment.
(imported from commit ea18a9b05106546475bc151229955ddafd8e7b8e)
This was a historical artifact of how that used
to be a search icon right by a textbox.
(imported from commit 6f73bc8b5d174e4c07f1503ffd08650110e80420)
I have some serious concerns with this implementation,
but I think it's still an incremental improvement.
(imported from commit 6ed8d2545c727e25bf85b98a1528dbf3d155bc92)
This is mostly working; things that need to be implemented:
- Ask users for their Real Name
- Personal replies need skinning
- Miscl UI changes to match mockups
(imported from commit 3638cf5ec2ba2306004ba6db6fa4c25c47f76517)
Here we check if a class exists. If not, we prompt the user to create, sub,
and send his message to the class. If the class exists but we're not subbed
we prompt the user to sub.
This commit also added a decorator to views.py and refactored out some
redundant code.
(imported from commit 7234ef6c080f2a6de6ff0922635dddd90032f7fe)
Here we pull in the jqueryui library and a style sheet to provide a widget
to do autocomplete for various fields. We populate a list of all ever-seen
classes, instances, and people (C/I/P) into JS arrays and then pass them to
jqueryui.
Each time a new C/I/P appears, we reinitialise the autocomplete functions
so they will notice the new data.
(imported from commit f1ab69c99d21f68ccf40c015bd43960f463c6ff2)
Previously, if hamlet wrote to iago, and then hit "r" on his own message,
the form would prompt hamlet to reply to himself. Now, Humbug will DTRT and
prefill the form with iago instead.
(imported from commit cb3260d1d0bc89b184dac84ebf1e5642d0bc1606)