Topics #33
Labels
Comments
|
The topic of the current issue should go in the prompt when it is not in the body (in a cell on the topic list or in the editor when it is editable) rising into the prompt and falling into the body as necessary. |
|
What if the topics were sections, and the comments individual cells in that section. |
ElDragonRojo
added a commit
that referenced
this issue
Aug 5, 2013
* The talk list and related talk view can now be sorted in ascending or descending order via a control in the navigation bar. (Refs #38) * This is accomplished with a boolean property and the sort descriptor of the fetch request. * Sort direction is saved and restored from user defaults. * The title is now the topic, i.e. the topic of the selected issue. (Refs #33) ## Refactoring * Pare down the fetch request automatic accessor to make it easier to refresh the fetch request, potentially with new data, and do so. * The reloadList: method now serves a legitimate purpose, reloading the fetch as well as the table view, which can still be reloaded directly. ## Style * Took out all that commented table view code from the talk list. * That code was replaced with the simple, naïve implementation. It remains implemented this was in the talk view controller, so we can compare the two.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The title of an issue is currently inlined for display, but this is awkward for creation. It seems like a talk list aka conversation should have a topic, which is the other part of the issue that isn't the talk, i.e. the title.
This issue is an implementation of issue #31
A GitHub issue is represented in Lemacs as a conversation, its topic, and its first talk.
A GitHub comment is represented in Lemacs as an additional talk, in this case added to current conversation.
In the other direction, adding a topic in Lemacs should have a text field for the topic and a text view for the talk.
Replying in Lemacs creates a talk, and adds it to the current conversation, regardless of whether the reply happens while looking at the conversation or zooming in on one of its talks.
We could eliminate that distinction in the UI by eliminating replies from edits, which would necessitate removing the jump feature (refs #21) and also require making the conversation view always display talks in their full size, possibly with a disclosure feature so you could collapse loudmouths (refs #32).
The text was updated successfully, but these errors were encountered: