Skip to content
This repository has been archived by the owner on Feb 2, 2021. It is now read-only.

Threaded threads #78

Open
wants to merge 42 commits into
base: master
Choose a base branch
from
Open

Conversation

cyisfor
Copy link
Contributor

@cyisfor cyisfor commented Jun 1, 2020

Making threads look like a tree, so you can see who's replying to what.

Cy and others added 30 commits May 30, 2020 21:23
(#fff) is not a good background color to compose posts in, that are then displayed with the dark background color.
Pleroma will send records that cause brutaldon to make pleroma-specific responses, which the mastodon python module wigs out on claiming it doesn't support that "feature set" so allow for a feature set to be specified...
Recreate the mastodon object if there's an error complaining about a missing feature set. Only happens for status_post I think. Could be further generalized...
No need to list the preference fields three times in three places in the code. A class decorator ought to be able to sleuth them out from the model itself. Should make it easier to add new preferences.
Because when you add one field to a class, you clearly want to add two fields to a class, and there's no need to consider the field you never asked to add to be something other than a field.
A setting to not censor sensitive images if you think you're not in danger for looking at them.
Add a preference to open details by default.
    I couldn't tell who was replying to whom, so I thought I'd give a shot at implementing a tree of threads, instead of a flattened list, with only the root distinguishable from the rest.
Doing some token based temporary flattening for django
It was saying stuff was unhashable, but I thought I was just hashing by post ID.
Python's dynamic typing doesn't make this easy...
I think I got it working.
If we have multiple roots ever, we need the whole thing in a big <ul></ul>
Is nothing in reply to the root post? Nothing at all?
More debugging...
Trying to find why only the one post comes out with no replies
I can't imagine how, but...#
Trying to find how to thread stuff is harder than I thought it would be. Where's the root?
The top level roots acts like any other level, I noticed.
Trying to add the leftover toots that don't reply to anything at the end.
1) initialize seen to empty
2) get all posts not in seen
3) add posts to seen because the generator was iterated over lazily
4) wonder why it looks like there weren't any posts in seen

yeah... leftovers has to be lazy too.
We have the post ID, so why would Pleroma not send us the post? Request any missing posts it hasn't sent us, to try and get a thread that doesn't lose all its replies.
Right, I forgot I was in the middle of changing the name post to toot. Thus explaining why op.post had an empty result, since op.toot was what I changed.
Oh for Pete's sake I'm an idiot. The descendants array isn't going to contain the root post at all, because it's totally separate. That's the missing post everything was trying to reply to!
I thought the root post only displayed once. Maybe it needs to be removed?
Cy and others added 2 commits June 1, 2020 03:46
Right, the template is where the duplication of the root is, since now the root is just the first "descendant" in the tree.
Now that everything is a <li> can set the margin-top value to make a gap, instead of making a visible "invisible" hr. And with the template thread.html fixed, it seems to be working, showing everything as a tree, instead of a flat list.
@jfmcbrayer
Copy link
Owner

I've been playing with this on a branch. I absolutely love the idea, and the implementation is pretty close. It breaks down on mobile, though – the screen becomes wider than the viewport. Do you have the CSS skills to fix it up?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants