Fossil Forum

Thread view modes

Thread view modes

Thread view modes

(1) By andygoth on 2020-08-18 13:19:19 [source]

I'm confused by the thread view modes. There appear to be three mutually-exclusive modes:

  • Chronological
  • Hierarchical
  • Unformatted

What surprises me is that, functionally speaking, unformatted mode implies chronological mode. I would have thought chronological/hierarchical and formatted/unformatted to be orthogonal settings.

Furthermore, chronological (therefore also unformatted) mode implies showing the edit history inline rather than hiding it behind the [history] link. Again, I would have thought "show/hide edits" would be a third orthogonal setting.

Thoughts? As much as I'm tempted to change this, it's a bad idea to dig in and start making changes here without knowing the context of why things are the way they are.

(2) By John Rouillard (rouilj) on 2020-08-18 18:27:21 in reply to 1 [link] [source]

I agree with you. Like on Sesame street one of these things doesn't belong here.

The first two are ordering operations. Unformatted has nothing to do with ordering (per se). It's display and we could in theory have an unformatted hierarchical (really threaded displayed as a heirarchy) display showing edits as well.

That said, I am not quite sure how to group/differentiate these. I could see unformatted being a checkbox but that would mean that there should be an unformatted threaded display which AFAIK doesn't exist.

I think unformatted rose up because of unterminated html tags in the text making it impossible to view some threads. Using unformatted resulted in everything going into pre blocks that stops the mismatched html from being a problem.

This is why "unformatted" is not a per entry/response item.

(3) By andygoth on 2020-08-18 19:09:22 in reply to 2 [link] [source]

"Formatted" or "Unformatted" could be a checkbox, need to decide which sense we prefer.

Ditto "Chronological" or "Threaded".

Ditto "Show Edits" or "Hide Edits".

(4.4) By andygoth on 2020-08-21 04:44:21 edited from 4.3 in reply to 3 [link] [source]

In the absence of comments, I guess it's up to me to pick my favorite.

For /forumthread and /forumpost, I propose three checkboxes:

Label Desktop Default Mobile Default

To not break existing URLs, the "t" query parameter will continue to be read (though no longer generated) and will be mapped as follows:

Platform t Threaded Raw History Single
Desktop a
Mobile a
Any h
Any c
Any r
Any y

[Edit: I enabled Raw and History for c and r because that is current behavior.]

[Edit: Oops, y actually means the history of a particular comment, not the whole thread. Thus, the "Single" column. Oops #2: `y displays in raw mode.]

Also to preserve existing URLs, in addition to "t" I will keep the "raw" and "hist" query parameters. All I do is add "hier".

(Hmm, "hist" doesn't seem to be implemented, only documented. Oh well, keep it anyway!)

Legacy/New Parameter Description
Legacy t Mode selection, as above
Legacy raw Show a single raw comment with no border
New single Show a single comment rather than the whole thread
New hier Show hierarchical threads, boolean
New hist Show edit history, boolean
New plain Show raw comments, boolean

[Edit: Uh oh, raw is actually rawer than raw, in that it doesn't even display the frame around the post. Thus, I will go with plain instead, letting raw continue to do what it's been doing.]

Sound good? I don't have time to implement now, but it's better that we come to an agreement before I write code. (In fact, time got away from me and I'm now at risk of being late for an upcoming meeting. Oops!)

[Edit: All these edits are getting messy! Time to reply instead. But at least I'm making a good test case thread!]

[Edit: This is a test edit whose sole purpose is to see what happens when old posts get edited after newer posts which themselves have been edited.]

(5.1) By andygoth on 2020-08-21 04:05:02 edited from 5.0 in reply to 4.2 [link] [source]

I fear I got everything muddled up, but being able to safely do that is the point of thinking everything through before trying to code anything. Turns out this is rather hard!

Having four booleans implies sixteen combinations, but it makes no sense to combine hier with single. That brings us back to modes. There are three primary modes (Threaded, Chronological, and Single), plus two remaining booleans (raw and history), for a total of twelve combinations. Do they all make sense? Let's see:

Mode Raw History Description Default For
Threaded Normal threaded mode Desktop
Threaded Threaded with edit history
Threaded Threaded without formatting
Threaded Threaded with edit history and no formatting
Chronological Normal chronological mode Mobile
Chronological Chronological with edit history Mobile (old)
Chronological Chronological without formatting
Chronological Chronological with edit history and no formatting
Single Single comment
Single Single comment edit history
Single Single comment without formatting
Single Single comment unformatted edit history

Looks like yes, they do all make sense. However, what doesn't make sense is picking Single from a listbox. Single mode can only be entered in combination with selecting a particular comment, which is done by clicking the [History] and [Source] links in the border of that comment. This leaves us with Threaded and Chronological, which I'm going to have to keep as separate links in the page header so the user can change modes. When in Threaded, display Chronological. When in Chronological, display Threaded. When in Single, display both.

Okay, now I'm going to chart everything out using this revised perspective:

Platform Query Description t plain hist
Desktop t=a Same as t=h N/A Effective Effective
Mobile t=a Same as t=c N/A Effective Effective
Any t=h Threaded mode N/A Effective Effective
Any t=c Chronological mode N/A Effective Effective
Any t=s Single mode N/A Effective Effective
Any t=r Same as t=c&plain&hist N/A Ignored Ignored
Any t=y Same as t=s&plain&hist N/A Ignored Ignored
Any raw Like t=s&plain, no border Ignored Ignored Ignored
Any plain Unformatted Effective N/A Effective
Any hist Edit history Effective Effective N/A

Now we're getting somewhere!

The [History] link, which currently points to t=y, will change to t=s&hist or t=s&plain&hist, depending on whether or not in formatted mode.

The [Source] link will continue to point to raw.

(6) By John Rouillard (rouilj) on 2020-08-21 21:43:47 in reply to 5.1 [link] [source]

Yup that looks like a reasonable matrix.

What controls are you planning? Are these all links, or do you you have a form with history and raw checkboxes?

The nice part about links is it will work without javascript. The bad part is you would need three clicks (and page loads) to get (on desktop) starting in threaded mode with links:

  chronological, history, raw

Click one changes to chronological mode; click 2 to chronological with history and click 3 to enable raw mode. So after three clicks, you end up with links:

   threaded, no history, formatted

while displaying in chronological, history and raw mode.

With a form, you could check history and raw and have chronological be a submit button (or have a separate submit/Apply button). One submit/round trip and you get to the desired state.

IMO the number of times history and raw will be used, there is no issue with using links. Each link sets/unsets its one option, but it's just my uninformed opinion.

However this is something to consider before start of coding.

(7) By andygoth on 2020-08-21 23:29:37 in reply to 6 [link] [source]

I'm planning to display "Chronological" and/or "Threaded" as links, followed by "History" and "Raw" as checkboxes.

When in threaded mode, the "Chronological" link is shown.

When in chronological mode, the "Threaded" link is shown.

When in source mode (reachable via a [Source] link), both "Chronological" and "Threaded" links are shown, and the checkboxes are hidden.

To be honest, I feel I should say "Hierarchical" rather than "Threaded" and "Unformatted" rather than "Raw" to match the existing UI. Is that okay with everyone?

At this moment, I'm happily hacking away in my andygoth-forum-refactor thread. It's turning out to be a huge effort, but one I find well worth my time. Much refactoring is required to get the forum code into a condition that can support this new functionality. Because this is a refactoring process, I'm trying to make each change be its own check-in so that they can be examined separately, proving the correctness each step of the way. Otherwise it'll look like I just rewrote the whole thing all at once, which will make code inspection vastly more difficult.

(8) By andygoth on 2020-08-22 02:45:20 in reply to 1 [link] [source]

I have a seemingly-working version now. Please try out the andygoth-forum-refactor branch and post about your experiences.

In addition to the already-discussed changes, when a post is edited, its serial number now includes a revision number. For example, "4.3" means the third edit to "4.0". Posts that have never been edited don't show a revision number at all.

The baseline code always displays edited posts unformatted. Do we want to leave this alone, display edited posts the same way as current posts, or add another option to control the formatting of edited posts? I chose to maintain the baseline behavior because I imagine there was some reason for it.

(9) By sean (jungleboogie) on 2020-08-22 16:01:34 in reply to 8 [link] [source]

Thank you for making the changes! drh has pushed these changes to the hosted Fossil repo where we can all try and see the changes. I like the edited post count modification as well.

One small warning was generated when I built this morning.

cc -I. -I./src -Ibld -Wall -DFOSSIL_DYNAMIC_BUILD=1 -DFOSSIL_HAVE_FUSEFS  -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -o bld/forum.o -c bld/forum_.c
./src/forum.c:772:7: warning: variable 'mode' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
      default: webpage_error("Invalid thread mode: \"%s\"", zMode);
./src/forum.c:794:7: note: uninitialized use occurs here
  if( mode!=FD_CHRONO ){
./src/forum.c:737:11: note: initialize the variable 'mode' to silence this warning
  int mode;
           = 0
1 warning generated.

(10) By John Rouillard (rouilj) on 2020-08-22 16:43:55 in reply to 9 [link] [source]

I like the change. The chronological/hierarchical links work without javascript.

However the check boxes do nothing useful and are confusing.

Should they even be displayed if js is disabled. E.G. the version graph on the timeline page isn't displayed if js is not working.

Alternatively would adding a submit button only when javascript is disabled work? It could make it look like the left hand chronological/hierarchical is covered by the submit button. Maybe adding a div with a border around the checkboxes/submit button would work to reduce confusion?

(11.1) By Stephan Beal (stephan) on 2020-08-22 17:02:32 edited from 11.0 in reply to 10 [link] [source]

If someone wants to take that on, my recommendation is: when emitting the HTML, simply add the CSS classes "hidden" and "reveal-at-startup" to those elements, then emit a piece of JS which removes those classes from all elements matching the second class. Something like...


(That's tedious to type from a tablet.)

Noting that MSIE does not have forEach() but we have a polyfill for that in style.c.

That will hide the elements in non-JS environments and reveal them if the JS runs. Our CSS already defines the hidden class and the new JS code makes extensive use of it.

Note, however, that near-future plans for the forum will make writing/responding to posts impossible without JS unless someone else steps up to maintain noscript legacy versions of the affected features. (You Have Been Warned.) Reading posts won't (or shouldn't) be affected, at least not according to the current plans.

(12) By sean (jungleboogie) on 2020-08-23 01:40:47 in reply to 8 [link] [source]

Probably outside the scope of what you wanted/considered, but I'll ask/report it anyway.

If I'm in c or h view with unformated text and reply to a post, I'm switched back to the formatted view. This is (probably) only a disadvantage me because I like to cheat and see how people are crafting their markdownn in posts. This means opening two tabs to see it and other tab to reply to it. Is it logical to assume the "replying to" text should be in the same view/mode you were viewing the thread in?

(13) By andygoth on 2020-08-23 15:20:23 in reply to 12 [link] [source]

Sounds reasonable to me. I tried my best to avoid making any changes to posting, so I didn't even think about that.

(14.1) By Richard Hipp (drh) on 2020-08-24 15:02:22 edited from 14.0 in reply to 1 [link] [source]

Edit history not shown when not in "history" mode.

At is a thread on the SQLite forum started by an anonymous poster. They did not format their text very well. I tried to edit it, but now it appears that I am the original poster.

Before the refactor, it shows the post as "by" the original author with an additional notation of "edited by" for the editor. I think that would still be useful.

For now, I have revised my edit to make it clear that I am not the original poster. But I shouldn't have to put that disclaimer in the text of the post, I would think.

(16) By andygoth on 2020-08-25 13:48:26 in reply to 14.1 [link] [source]

Does this help?

(17) By Richard Hipp (drh) on 2020-08-25 14:42:25 in reply to 16 [link] [source]

Working concurrently, I made an alternative fix which is now on trunk and which is now installed on the server. Revisit the reference link to see the new header style.

(15) By Richard Hipp (drh) on 2020-08-24 15:34:54 in reply to 1 [link] [source]

More formatting problems...

Again over on the SQLite Forum:

As before, someone submits a misformatted query, though this time their query was formatted using Fossil Wiki. I tried to correct the formatting without changing the mimetype. And it looked fine on preview. But then when after I pressed "Submit" my edits were apparently formatted as Markdown. This caused severe distortion.

I went back and did a second edit, changing the mimetype to Markdown. That fixes the display. (SQLite Forum is a production forum - I can't leave misformatted entries there, waiting on Fossil bug fixes!) But now the formatting for my first edit is correct in the history display.

I don't know where exactly the problem is or how to reproduce it, but there is still a serious issue in the refactored forum display.

(18) By anonymous on 2020-08-27 21:54:56 in reply to 1 [link] [source]


editted => edited

See src/forum.c

5 instances altogether