Controversial posts and comments

[iByteABit256]

Closes #1105

[MV-GH]

Compatibility is kinda a problem, this will probably only be supported in lemmy 18.3. We will still support 18.0. So, some compatibility checks will need to be added. An implementation that I was thinking about was adding the version all long each sorting type. Then have a getSortingTypes(version) which filters on version. And you can get the version from siteviewmodel.

[iByteABit256]

hm ok, I'll give it a try

[iByteABit256]

Then have a getSortingTypes(version) which filters on version

This would probably mean showing UI components dynamically though which isn't done atm, right?
We'd also need to have an 'introduction version' for every single sort type, even the ones that existed from the beginning.

I was thinking of doing it for this sort specifically and show the component conditionally, leaving the older ones unaffected. It would also be useful in the case that controversial votes should be hidden according to enableDownvotes.

[dessalines]

@MV-GH w/ respect to versioning, since controversial won't come until v0.19.0

We'll adopt here what we do for the rest of lemmy, called stable mainline. In short:

• I've created a release/v0.18 branch. This branch is an orphan, and never merged back into main.
  • Fixes and all PRs made to main, then cherry-picked to the release branch.
• You can merge breaking changes into main, and use https://ds9.lemmy.ml , which should be the main branch lemmy, to test.

[MV-GH]

This would probably mean showing UI components dynamically though which isn't done atm, right?

Actually for the sort types it should already do that, But there might be some remnants where it is still hardcoded. I made some changes in this regard. As I foresaw more sort types and it was rather troubling having to trackdown all these hardcoded values.

We'd also need to have an 'introduction version' for every single sort type, even the ones that existed from the beginning.

Yes but you can just use 0.18 as we wont support any lower version anyway

[iByteABit256]

How about here for example? I guess we could have a map from component to version with a default value of 0.18, and then wrap each IconAndTextDrawerItem with an if statement for it.

                IconAndTextDrawerItem(
                    text = stringResource(R.string.dialogs_hot),
                    icon = Icons.Outlined.LocalFireDepartment,
                    onClick = { onClickSortType(SortType.Hot) },
                    highlight = (selectedSortType == SortType.Hot),
                )
                IconAndTextDrawerItem(
                    text = stringResource(R.string.dialogs_new),
                    icon = Icons.Outlined.BrightnessLow,
                    onClick = { onClickSortType(SortType.New) },
                    highlight = (selectedSortType == SortType.New),
                )
                IconAndTextDrawerItem(
                    text = stringResource(R.string.dialogs_old),
                    icon = Icons.Outlined.History,
                    onClick = { onClickSortType(SortType.Old) },
                    highlight = (selectedSortType == SortType.Old),
                )
                IconAndTextDrawerItem(
                    text = stringResource(R.string.dialogs_controversial),
                    icon = Icons.Outlined.ThumbsUpDown,
                    onClick = { onClickSortType(SortType.Controversial) },
                    highlight = (selectedSortType == SortType.Controversial),
                )

You can merge breaking changes into main, and use https://ds9.lemmy.ml/ , which should be the main branch lemmy, to test.

What I get from this though, is that we can push this to main even if it isn't intended for release 0.18, and it just won't be cherry picked for this release, but for the one where this sorting is introduced in the backend as well.

[MV-GH]

Could you not there not do something like this getSortypes(version).intersect(listOf(SortType.Hot, SortType.New, ...)) ?

That stable mainline policy will probably only be implemented once 0.19 hits. Could still be far away.

One thing you also will be able to do is add the image to the enum so that we don't have to specify it again each time.

[iByteABit256]

getSortypes(version).intersect(listOf(SortType.Hot, SortType.New, ...))

I could, but I would need to create the IconAndTextDrawerItems dynamically somehow for each item of the returned set instead of how it's done right now.

One thing you also will be able to do is add the image to the enum so that we don't have to specify it again each time

You mean the Icons.Outlined.ThumbsUpDown icon? I could create a mapping function like we do for the other fields, something like this:

fun getCommentSortTypeIcon(ctx: Context, commentSortType: CommentSortType): androidx.compose.ui.graphics.vector.ImageVector {
  // ...
}

[MV-GH]

I could, but I would need to create the IconAndTextDrawerItems dynamically somehow for each item of the returned set instead of how it's done right now.

getSortypes(version).intersect(listOf(SortType.Hot, SortType.New, ...)).foreach(
 IconAndTextDrawerItem(
                    text =  getLocalizedSortingTypeLongName(ctx, it),
                    icon = Icons.Outlined.LocalFireDepartment, // Either map, or store it on the enum itself, like we do in NavTab
                    onClick = { onClickSortType(it) },
                    highlight = (selectedSortType == it),
                )
)

[iByteABit256]

That looks good, thanks!

[iByteABit256]

@MV-GH take a look, I did it a bit differently after all

[MV-GH]

Codewise it looks great! I'll test the functionality later.

In SettingsForm for the AccountSettingsActivity, should only be a able to be set to a sortType that the instance supports. So there you need to use that getSupportedSort types too.

[MV-GH]

Almost there

[MV-GH]

More needs to be done, currently it selects the right sort type by having this thing the same index as the index in the sorttype. In the future where it would be possible for controversial to be disabled (if downvotes disables). These indexes wont lineup.

A potential solution is keep the list separate. then on the dropdown where you select the sortType you have a onSelect that updates a separate rememberSaveable that stores that index. Then in the form you have default_sort_type = actualSortTypes[actualSortType.value]

[iByteABit256]

I'm a bit confused by which indexes won't lineup. The one index is the one in the supported sort types list, which is the other one?

What I was thinking about this is to add a second parameter to getSupportedSortTypes with the enableDownvotes boolean, but if I do this now I might as well implement the actual hiding too.

[MV-GH]

That list of names gets fed to the dropdownsetting which sets the intsettingstate when you select a name. which is the index of that list

Then in form it uses that index to select a sorttype. If we use the index to get it from the filtered list instead of all the sorttypes then we can pass sortType.ordinal to the form. This way it will always have the right index.

[iByteABit256]

Maybe it's a bit of a clunky solution, I made it so that the sort type returned by the backend is matched to the supported types using indexOf, and then I pass the supported sort type to the form using the index returned by the dropdown.

What do you think?

[iByteABit256]

You dont need to add twice the same string

I removed the dialogue one, and I also removed the text field from the enum and I used the long form in the dialogue form instead

[MV-GH]

Could you rebase from main? @dessalines This isn't really a breaking change as it keeps the current behaviour for the current version (inline with the API rework).

I am kinda pushy about this because, this removes the hardcoded sorts we already have in place.

[dessalines]

Mmk, I'll start that now.