Customizable drawer

[DavidEdwards]

Add all options from customizing the Tabs to a new system from customizing the side drawer. This allows us to resolve requests such as #3010.

https://user-images.githubusercontent.com/1585923/219144466-d44288ee-68ea-47d5-a5f2-df11c7da5b0d.mp4

[connyduck]

I think this would be a nice addition, if you clean this PR up I'll review it!

[DavidEdwards]

Absolutely. Now the other is merged into develop, this one can be rebased and made cleaner.

I'll look into that soon.

[DavidEdwards]

@connyduck It should be runnable / testable / reviewable now. It is synced with develop.

I am leaving it on draft, as I am positive changes will need to be made.

[DavidEdwards]

@connyduck It should be in a good state now. Have a look when you have the time.

I just noticed the issue here too: https://github.com/tuskyapp/Tusky/issues/3331

@nikclayton You might want to have a look what you think too.

[nikclayton]

Will do, after I've wrapped up https://github.com/tuskyapp/Tusky/pull/3436

[nikclayton]

Just looking at the UX, I haven't looked at the code yet. I'm coming at this from the assumption that the goal in https://github.com/tuskyapp/Tusky/issues/3331 is good.

First impressions:

• Federated timeline can probably be put back on the list of default tabs
• Navigation menu doesn't show all destinations by default:
  • Notifications
  • Local timeline
  • Direct messages / conversations
• There's still a limit of 5 tabs
• Unclear why there's a limit of 10 entries in the navigation drawer
• Unclear why some things can appear in the navigation drawer and tabs (e.g., notifications) and some things are drawer only (e.g., scheduled posts).

And I think the interaction model is still backwards. The user has to think about where the are first (navigation drawer or tabs), and what they want to see there second.

But I think it should be the other way around -- the user creates / selects and configures the timelines that they want to see, and then controls where those timelines are placed.

Nowithstanding that, I also noticed an odd gap (with a divider) in the navigation menu between the bottom of the account info and the "Edit profile" menu entry, see screenshot:

[DavidEdwards]

First impressions:

Federated timeline can probably be put back on the list of default tabs Navigation menu doesn't show all destinations by default: Notifications Local timeline Direct messages / conversations

I tried to leave the list as it was. I think I only added federated and trending as defaults. Though this would be easy to change.

There's still a limit of 5 tabs

I would prefer not to get involved in that for this PR. That could always come afterwards.

Unclear why there's a limit of 10 entries in the navigation drawer

Yes, that is a good question. I am not sure why there's a limit. It is probably because I copied the code over and just edited it larger. We could certainly remove the limit.

Unclear why some things can appear in the navigation drawer and tabs (e.g., notifications) and some things are drawer only (e.g., scheduled posts).

It is a technical limitation. Some systems are activities and some are fragments. If the system uses an activity, I would have to refactor it to use a fragment. That is far too complicated. The downside is that some systems can only be accessed through intents.

And I think the interaction model is still backwards. The user has to think about where the are first (navigation drawer or tabs), >and what they want to see there second.

But I think it should be the other way around -- the user creates / selects and configures the timelines that they want to see, and then controls where those timelines are placed.

That is a much bigger question. I'm not sure I can answer it.

Nowithstanding that, I also noticed an odd gap (with a divider) in the navigation menu between the bottom of the account info and the "Edit profile" menu entry, see screenshot:

Good spot. I have removed it.

[DavidEdwards]

To do: clicking a notification doesn't open notifications if it isn't on the tabs. It should also support the sidebar.

[nikclayton]

Still working on the 22 release, and the other arch changes, so a quick drive-by comment:

It is a technical limitation. Some systems are activities and some are fragments. If the system uses an activity, I would have to refactor it to use a fragment. That is far too complicated. The downside is that some systems can only be accessed through intents

Maybe it would be easier to tackle refactoring the existing activities that don't have fragments, and turn them in to an activity+fragment combo before going further with this work?

That is a much bigger question. I'm not sure I can answer it.

So maybe we can also get group consensus on the ideas in https://github.com/tuskyapp/Tusky/issues/3331 first? Once we've got consensus on a direction we can go from there. ?

[DavidEdwards]

@connyduck What should we do with this? It is assigned to you for architecture?

I would be OK with rebasing this onto the current develop branch, if there is hope of resurrecting its' cold dead corpse. :zombie:

[connyduck]

Yes I know I said I'll check the code, but then things happened, sorry for that.

I think we can resolve all code related issues one way or another, but since I'm not making decisions here anymore, we should make sure the team actually wants this feature before we put anymore time into it.