More specialized desktop and mobile layouts

[bertob]

The navigation model is currently not ideal on either desktop or mobile:

• On desktop it's weird to have sidebar items for some things, and view switcher items on the right for others
• On mobile it's weird to have a huge sidebar for what would otherwise be a normal primary menu

Using the new AdwBreakpoints it should be possible to have independent layouts for the two cases, which would help improve the layout for both. Here's a strawman proposal:

• For desktop I'd move everything to the sidebar, so you'd essentially have three new things in there (below Home): Notifications, Conversations, and Search
• For mobile I'd make the sidebar a normal primary menu on the right

The Elk sidebar is a good example of what I have in mind for the desktop layout, it'd also be nice to separate the less important items (Explore, Local, Federated) in a separate section below the main section:

[bertob]

Experiment for a split view layout for the desktop size:

[GeopJr]

Looks great so far!

Here's a quick attempt at the desktop one (no breakpoints yet) (https://github.com/GeopJr/Tuba/tree/experiment/feat/redesign)

The sidebar needs a complete re-write so I didn't bother for now

(It's probably a bit early to ask but) should the top left sidebar button open the account switcher or the current users' profile and instead put the switcher in the menu next to it?

should the scroll to top button switch to the left side? (it's removed in that branch)
and should the compose / new post button be visible on all views or just home?

[imhemish]

Just to say, KDE's Tokodon also somewhat looks like this

Looks awesome!

[bertob]

Nice, that's a great start! A few notes:

• The background colors on both panes should be darker, not sure where you'd get the correct values though, cc @Exalm
• The sidebar is too wide, so it looks empty. I'd make it about 220px wide.

I pushed my initial mockup here, including a mobile layout: https://gitlab.gnome.org/Teams/Design/other-app-mockups/-/blob/master/tuba/tuba.png

should the top left sidebar button open the account switcher or the current users' profile and instead put the switcher in the menu next to it?

I was thinking it'd open the account switcher, but good point about needing to have the link to your own profile somewhere. Maybe it's fine if that's available only from the account switcher?

should the scroll to top button switch to the left side? (it's removed in that branch)

I was thinking we could try having it be above the new post button.

should the compose / new post button be visible on all views or just home?

Just home.

Some open questions, mostly so I don't forget:

• The new account chooser and primary menu
• On mobile, should search be a view in the view switcher or a button in the headerbar?
• Where do the other views go on mobile? I was thinking probably into the primary menu, but could maybe also try a new pattern, e.g. an overview menu at the end of the view switcher, like Elk does:

[alice-mkh]

not sure where you'd get the correct values though,

That's just using new widgets. Really don't do the new styles yet please, it's really hard to get it right without at least toolbar view and you will most likely get it wrong at least somewhere. :) Just keep the raised header, etc and switch over once the new widgets land - libadwaita demo is doing the same thing atm.

[GeopJr]

Current state + some more questions:

The compose button will follow the android behavior of 'hide on scroll down' and 'show on scroll up after some distance' (the scroll to top button relocates when the composer button gets revealed or hidden)

In general:

• should the profile handle be ellipsized? the current Tuba release and the mockup do that (angela@gnom...) but after some more thought, I'm not sure if it should. It can be used for impersonation e.g. angela@gnome.org and angela@gnome-fake.example would be shown as angela@gnom... The downside is that it can look a bit weird if both the name and handle are too big
  
• should the home & star icon change to the ones from the mockup?

On desktop:

• should the 'Announcements' and 'Follow Requests' items move to the headerbar menu?
• should the 'Tuba' title be visible on the sidebar?

On mobile:

these are mostly additions to the open questions

• still not entirely sure about the sidebar. If the entries move to the main menu in the headerbar, it's going to be somewhat limiting (no icons or badges, might be overwhelming)
• the bottom bar is an AdwViewSwitcherBar, it's not meant to be extended both functionality and style wise. If the search button or a button that opens the sidebar is to be added to the bottom bar, we have to create our own widget instead. Style-wise the closer to the mockup I can do with just CSS is the screenshot below, if we create a custom widget, we will be able to have more control over its layout. The downside is it might not follow future HIG changes automatically or always match AdwViewSwitcherBar (& some other issues).

Another pattern would be the Google Messages one of top left being the sidebar toggle and top right being the account switcher:

[LukaszH77]

should the profile handle be ellipsized?

Maybe only for narrow window sizes?

should the 'Announcements' and 'Follow Requests' items move to the headerbar menu?

How about moving them into Notifications? Just like there are Posts, Hashtags, News and For You in Discover or Accounts, Posts and Hashtags in Search.

should the 'Tuba' title be visible on the sidebar?

I think so. That's what Files and Settings do and it can help find Tuba window among the others.

[GeopJr]

How about moving them into Notifications? Just like there are Posts, Hashtags, News and For You in Discover or Accounts, Posts and Hashtags in Search.

I have some issues with nesting tabbed views (views with tabs like the main, explore or search one), it will look weird having two switchers for a single view:

(quick edited screenshot mockups, the second switcher will be something else like "All" and "Mentions" for the notifications tab)

[LukaszH77]

OK, but why would you need to have double switchers here? Just show one switcher after clicking Notifications in the Sidebar

[bugaevc]

should the profile handle be ellipsized? the current Tuba release and the mockup do that (angela@gnom...) but after some more thought, I'm not sure if it should. It can be used for impersonation e.g. angela@gnome.org and angela@gnome-fake.example would be shown as angela@gnom... The downside is that it can look a bit weird if both the name and handle are too big

So I'm using Tuba with two accounts that are both bugaevc@some.domain, and it ellipsizes before the domain name! Given that I have the same avatar on both, I can't distinguish between them at all.

So something should definitely be done about this. That being said letting it break into multiple lines also looks bad.

Could the account switcher perhaps be a popover that's be wider than the sidebar?

[bugaevc]

This is what it looks like. A few low hanging fruits would be reducing those giant margins and removing the prominent delete button (surfacing the delete functionality somewhere else):

And this is what it would look like with the account switcher in a popover:

[GeopJr]

OK, but why would you need to have double switchers here? Just show one switcher after clicking Notifications in the Sidebar

On desktop, yes but on mobile the double switchers cannot be avoided (since on mobile Notifications and Conversations are no longer on the sidebar but instead on a switcher)

So I'm using Tuba with two accounts that are both bugaevc@some.domain, and it ellipsizes before the domain name! Given that I have the same avatar on both, I can't distinguish between them at all.

My initial question was mostly about the posts on a timeline (where impersonation can happen by ellipsizing the handle). On the account switcher I think the stack looks better than a popover but it would match Fractal. I think ellipsizing is somewhat needed even on the popover for extra long domains.
In the meantime, the rows have a tooltip text with the account handle being hovered:

[bertob]

This is looking great, can't wait for this to land! Is there a branch to try the current state?

should the home & star icon change to the ones from the mockup?

I think you get the new home icon for free when adwaita icon theme updates

should the profile handle [in the timeline] be ellipsized?

This seems separate from the navigation changes, so I'd split it out to its own issue

should the 'Announcements' and 'Follow Requests' items move to the headerbar menu?

Move to the headerbar in which cases? For now I think it's fine to keep them in the sidebar, I think.

should the 'Tuba' title be visible on the sidebar?

No strong opinion, feel free to keep it for now.

still not entirely sure about the sidebar. If the entries move to the main menu in the headerbar, it's going to be somewhat limiting (no icons or badges, might be overwhelming)

Hmm? Which entries are moving to the primary menu?

the bottom bar is an AdwViewSwitcherBar, it's not meant to be extended both functionality and style wise. If the search button or a button that opens the sidebar is to be added to the bottom bar, we have to create our own widget instead. Style-wise the closer to the mockup I can do with just CSS is the screenshot below, if we create a custom widget, we will be able to have more control over its layout. The downside is it might not follow future HIG changes automatically or always match AdwViewSwitcherBar (& some other issues).

For now I'd try the following as a next step:

• Keep search in the headerbar on mobile, only move it to the sidebar on desktop
• Keep the view switcher (Home / Notifications / Messages) the same as now on mobile, simply hide it on desktop
• Leave styling changes etc. for later

For the account switcher a popover would be the more standard pattern, and it'd cleanly solve the truncation issue. It'd be good to have some kind of inline check to indicate which account is selected when there's more than one, but that's a separate issue :)

[LukaszH77]

This is looking great, can't wait for this to land! Is there a branch to try the current state?

feat/sidebar/match-moockup-order

[GeopJr]

Move to the headerbar in which cases? For now I think it's fine to keep them in the sidebar, I think.

Sounds good, they weren't in the mockup (not sure if they were in a release then so that checks out) so I assumed they were hidden

Hmm? Which entries are moving to the primary menu?

All of them (sidebar items) I assume, on mobile, according to the original post "On mobile it's weird to have a huge sidebar for what would otherwise be a normal primary menu"

For the account switcher a popover would be the more standard pattern, and it'd cleanly solve the truncation issue. It'd be good to have some kind of inline check to indicate which account is selected when there's more than one, but that's a separate issue :)

I'll follow Fractal's design then!

[GeopJr]

Is the current progress good enough for the 45 release or should it be postponed until the mobile headerbar & workflow is done / decided?

Summarizing:

Mockup	Current
Top left open shows the account switcher popover, top right is a menu with all the sidebar items (?)	Top left opens the sidebar

Also I just noticed two other differences in the mockup:

• Posts no longer have a 3-dot menu button (moved to right click / long touch?)
• Relative time unit is in full (h => hours)

[bertob]

Yeah, IMO the current version is more or less ready for a 45 release. I'd still be interested in trying the no-sidebar thing on mobile, but it's a bit experimental to have so much navigation inside the primary menu so it might not work out :)

The 3 dot menu and time unit thing are not essential and can be discussed separately / after the next release.

[LuNeder]

Hey! Sorry for reviving this old issue, but may I ask how's the layout chosen?

On Plasma Mobile, the PC layout seems to be used even with a screen resolution that should be used for mobile. I'm on postmarketOS on qemu, using the flatpak tuba.
On phosh it shows the mobile layout as expected (tho on phosh I did use the apk version instead, but on plasma the apk version complains about libGLESv2 so I need the flatpak one)

Maybe a setting or command-line flag to force either layout would be nice to add?

Edit: Nevermind, I installed phosh and now it works (on plasma). If phosh is installed (even if not used) it works (both apk and flatpak) with the correct layout.

[GeopJr]

Did this happen with other libadwaita apps (prior to your workaround)?
Unfortunately, I do not have a mobile device to test on but if it happened to all libadwaita (or other GUI toolkits or widget libraries) apps it might be worth it to report it to plasma mobile

FWIW, the layout is based on the window size (for all libadwaita apps that are convergent)

[LuNeder]

Did this happen with other libadwaita apps (prior to your workaround)?

Haven’t tried any other adwaita apps on kde tbh, but I can try and let you know

(also the desktop layout looks really good (on desktop), congrats! (it’s not common to even have a desktop layout on gtk apps these days so tuba really impressed me))

it might be worth it to report it to plasma mobile

Ye, I’ll also report to plstmarketOS the lack of libGLESv2 as a dependency of tuba in their apk repos

I’ll do some more testing to try to figure out exactly what fixed the layout problem (libGLESv2 or something else that came with phosh) and report back.

[alice-mkh]

I suspect this is the same issue as https://gitlab.gnome.org/GNOME/libadwaita/-/issues/809. The person there clearly has unset gtk-xft-dpi (and everything else as well, hence aliased text), so settings portal doesn't provide it.

Breakpoint conditions in most apps do account for it too (that's what sp unit is for), and if it's at 0, it won't be triggered.

Now, settings for this kind of stuff were never standardized, and xdg-desktop-portal-gtk/gnome do expose the needed keys, but -kde? It doesn't. And I suspect it also has keys that -gtk/-gnome don't expose.

So you need to have xdg-desktop-portal-gtk.

But that's not enough. Before the switch to portals.conf that was it, but now gtk also needs to be listed there alongside kde. GNOME's config does this, but KDE's apparently doesn't (and why would it?)

TLDR this part of portals was never really properly designed and we're seeing it explode now :(

I can add a workaround to libadwaita to have it treat gtk-xft-dpi=0 as default value, like gtk does for text, but it will still be fundamentally broken...