There are a lot of sites that just dont use covers or that focus more on providing a summery and the genres of the novel in the listing, having these displayed in Shosetsu instead of the cover and title would be very helpful in finding a novel that you want to read.

My proposal:

NovelListing {
    title = ""
    link = ""
    imageUrl = null or ""
+    summery = "",
+    genre = {}
}

There could also be an extension option like this

enum ListingDisplay {
    TitleAndCover, // For displaying only the title and cover
    TitleAndSummery // For displaying title, cover if imageUrl is not null or empty, summery and genres
}
return {
	id = -1,
	name = "DEFAULT",
	baseURL = baseURL,
+        listingDisplayType = ListingDisplay.TitleAndSummery
}

The sub classes of Filter are primarily data classes, but not marked as such.
Doing so will make it easier to manipulate and configure them in Shosetsu.

Create an interface so that extensions can permanently store simple data in Shosetsu.

I will discuss with @TechnoJo4 regarding this

Depends on #50

There are some sites that change the filters based on the listing and the current state of other filters. One example would be ArchiveOfOurOwn.org. When you continue to set specific filters it will trim available filters with the available work's tags. So if there are more Female Protagonist works it will show the Female Protagonist tag unless there are more of other tags.

My proposal:
Allow an extension to return a new/modified filter list when filters are applied, and allow the extension to modify the states of those filters. On ArchiveOfOurOwn.org you can exclude a tag and it will stay in the filter list, but it will be moved to the bottom. Returning a new filter list with these states set will allow the extension to make these changes.

This also requires that the filter list has loading states where some options are only possible at certain times, so the filter list would need to load filters from the network in the background.

Description

When Shosetsu calls for results, either from a search or listing, there is no way to know if there are no more results. Leading to an unfortunate situation where Shosetsu will spam for a result.

Solution

Create a Result data class, parameters of the "Array<Novel.Listing>" and "hasNextPage"

Add a startIndex integer to Extensions.

This startIndex will be defaulted to 0

Developers have the option to override and set it to 1 if the website is programmed in that way.

Having the ID defaulted as -1 in Filter makes it difficult to maintain UI consistency.

Each Filter should have their ID specified, even if it is a useless ID

Currently Filter.Group/List both have their states set to a Map<Int,Any/T>

This is quite redundant, as Array<Filter<*/T>> can handle the job as each child Filter already has a state.

There are a few sites that have up to thousands of listing options. The easiest example would be Fanfiction.net. On Fanfiction.net you cannot get a regular list of fanfiction without first choosing one of the many options to browse. And since they continue to add more browse options a static list of listings wont last for long.

My proposal:
When clicking a extension it brings up a menu with one section of options, on Fanfiction.net these options would be Anime/Manga, Movies, and such. After that is selected it brings up another of these menus further specifying what you want to read, like Harry Potter or Naruto.

These need to be dynamically generated and even paged since things may continue to add more options, and some sites wont even have them all on the same page.

Currently kotlin-lib is dependent on an aging repository called LuaJ, that has been unmaintained for years.

Future plans is to rewrite the entirety of LuaJ in Kotlin with provide cross platform support. This will allow Shosetsu to improve the Lua experience on android, especially for other developers in the future.

Currently, Test.kt is dependent on kotlin-lib, and creates this weird use case of it being in the test directory (which is used for testing the actual code of the repository).

@TechnoJo4 , Do you agree with separating it to its own repository?

I have a feeling that the quantity of choices in Filter are somewhat overbearing.

For example, why do we have a Switch & Checkbox. Isn't the choice unnecessary when both do the same thing? Same thing with DropDown and RadioGroup.

Is Separator even needed when it is included in a Header?

Also, List is a nightmare to code for, and should be replaced with headers.

Add an option when creating a Filter.Text to mark it as sensitive information. Thus shosetsu can hide the contents of what is entered and save it to a secure location.

This will require a new "secure" preferences for an extension, but nothing major in Shosetsu.