This implements a list_render closure class that allows for
progressive, responsive rendering of long, scrollable lists, with
filtering support.
It isn't used, at present.
This shows a preview of a node given a reference to it like:
<tag id=“id” class=“className”></tag>.
It's intended to be used for reporting errors that are introduced by
developers in features such as the upcoming progressive list rendering.
The height of the settings page content is not quite as tall as the
settings page could allow which makes for an empty white space at the
bottom of the settings content container.
The tabs can have text inside them that is wider than 90px, especially
in some unexpected cases (e.g. a translation longer than the original
English string).
This type of tabs can be seen in the following popover menus:
- Stream subscriptions
- Help (with hotkeys, formatting info, etc.)
- Settings
Now text wider than the tab is ellipsized so it doesn't cause any
problem with the rest of the layout, except in the help popover (where
it gets wrapped).
The "Copy" button will only be shown for "View Source"
or "Topic editing only". Also replaced "Copy to clipboard"
with "Copy and close" to make autoclose less surprising.
Fixes#4238.
This moves respond_to_mention() and reply_with_mention() to
compose_actions.js. These methods are basically thin layers
on top of compose_actions.start().
This module extracts these two functions that get called by
several other modules:
start()
cancel()
It is a little bit arbitrary which functions got pulled over
with them, but it's generally functions that would have only
been called via start/cancel.
There are two goals for splitting out this code. The first
goal is simply to make `compose.js` have fewer responsibilities.
The second goal is to help break up circular dependencies.
The extraction of this module does more to clarify
dependencies than actually break them. The methods start()
and cancel() had actually been shimmed in an earlier commit,
and now they no longer have a shim.
Besides start/cancel, most of the functions here are only
exported to facilitate test stubbing. An exception is
decorate_stream_bar(), which is currently called from
ui_init.js. We probably should move the "blur" handler out
of there, but cleaning up ui_init.js is a project for another
day.
It may seem slightly odd that this commit doesn't pull over
finish() into this module, but finish() would bring in the
whole send-message codepath. You can think of it like this:
* compose_actions basically just populates the compose box
* compose.finish() makes the compose box do its real job,
which is to send a message
I think this is more pythonic?
We could also get rid of LoggingCountStats altogether, since it's now just a
special case of CountStat (is_logging == data_collector.pull_function is None).
But I think it's nice to keep the distinction since they behave so differently.
Removes the circular dependency of CountStat containing a DataCollector, and
DataCollector containing a function that takes a CountStat as an argument.
This will allow us to appropriately generalize CountStat to include
LoggingCountStat and CustomPullCountStat. It'll also make life easier when
we introduce DependentCountStat.
The previous zerver_* names were unwieldy and not very readable. This also
puts more of the useful information in one place; in particular, makes it
easier to skim a CountStat declaration and see if we're collecting it at a
user/stream granularity or a realm granularity.
It turned out to not be that useful once we added subgroup. The previous
design of the CountStat object also assumed more reuseability of the *_query
strings than what ended up happening.
The filter_args also had some carrying costs:
* It's hard to be confident that filter_args other than the ones explicitly
in our tests would have had expected behavior.
* The filter_args/join_args system is the most complex part of the CountStat
object, and makes understanding the *_query strings unnecessarily
difficult for a new contributor.
Useful for the upcoming check_realmauditlog_by_user_query, if nothing else.
But I suspect it will indeed get use; looking for events around or within a
certain time is pretty natural for an audit log.
The main argument against I would say is that this should actually be a
joint index with something else. I'm not sure what that something else
should be, so just optimizing for what I think
check_realmauditlog_by_user_query will need for now.
Groundwork for allowing stats like "Monthly Active Users".
CountStat.interval is no longer as clean a value as before, so removed it
from views.get_chart_data. It wasn't being used by the frontend anyway.
Removing interval from logger calls in counts.py is not a big loss since we
now include the frequency (which is typically also the interval) in
CountStat.property.
The comment explains this change is fairly good detail. This change
is designed to fix complaints that sometimes clicking on a message to
reply doesn't work, which we can reproduce as being caused by clicks
that happen simultaneous with a few pixels of mouse motion at the same
time as the click.
Comment and commit message rewritten by tabbott for clarity.
Yago González
Tim Abbott
Brock Whittaker
Rishi Gupta
Raghav Jajodia
Steve Howell
Joshua Pan
hackerkid