Closed dlsf closed 8 months ago
The issues with this are somewhat a design flaw with the LinkTile as a whole, it optimally shouldn't distinguish between the various DiscoverTypes internally
The issues with this are somewhat a design flaw with the LinkTile as a whole, it optimally shouldn't distinguish between the various DiscoverTypes internally
I agree, I started using it long time ago out of convenience, and it got baked into the whole app. Might be better to make it a sealed class, where each subclass will do what it has to do, or in exchange of adding a bit more code in every grid, remove it entirely. But this will require some touch ups all over the project.
A simpler solution, specific to #92, is to add a "Reply" item in the "More" menu of replies. It will open the message compose view and it will auto-insert @name_of_user
. That will kick the LinkTile
design problem down the road, but maybe it's a good enough solution?
As a side note, I will leave a few comments on the code changes for future reference.
A simpler solution, specific to https://github.com/lotusprey/otraku/issues/92, is to add a "Reply" item in the "More" menu of replies. It will open the message compose view and it will auto-insert @name_of_user. That will kick the LinkTile design problem down the road, but maybe it's a good enough solution?
I feel like it would still be convenient to copy usernames without having to open the user's profile, but that sounds like a good solution for #92, yeah. Just let me know if you want to add it to the "..." menu, make the name copyable, or both.
I think for now, we should only have that button in the menu.
I just realized that comments currently don't have such a menu, does it make sense to add it just for that one option? Or should there just be a separate button just for replies?
Oh, I completely forgot about that. Since I don't plan on adding more menu options for now, there could just be a reply button before the like one. For the icon, maybe quickreply_outlined
will do the job
Superseeded by #118
Intended as a potential implementation for #92, but also has the side effect that you can copy usernames directly from the user grid, etc.
I think this implementation kinda sucks because 1) the new
additionalData
field only applies to users and the name is not descriptive enough to clarify this on its own 2) if you add a newLinkTile
of typeDiscoverType.User
somewhere, it requires you to passadditionalData
. If you don't, it will copy the string “null” (could be fixed via a simple if condition).But I wanted to suggest this anyway.
Alternatives I can come up with are: 1) using a different widget for the long press detection 2) passing a function or something like that instead of an arbitrary
String? additionalData
, which would be much more powerful (but maybe unnecessary?)