This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Make it adapt to phones #57
Description
Currently Cawbird is a bit too wide to work on phones, I can think of a few things which could make it work:
- use a
HdyViewSwitcherfor Home, Mentions, Direct messages and Search views(like on the web version of Twitter) - drop the current dark view switcher
- hide the view switcher when viewing a tweet detail
- add a "back" gesture, that would likely imply having an improved
GtkStack - only use the back button for tweet details, hide it otherwise
- move either the account or compose button to the end of the header bar
- maybe don't make "back" move between views, but only back from one tweet detail, to the previous tweet detail, to the main view which started the exploration
- reduce the minimum width requests to 360px
- I'm not sure yet for the Favorites, Lists and Filters views
Activity
IBBoard commentedon Nov 17, 2019
Is there a way to simulate testing on mobiles? Because I don't know how to get Cawbird on a mobile.
From a quick look then that wouldn't play well with the rest of the UI for desktop users. And it adds another (uncommon/non-Gnome) dependency.
Already done a month ago, and I was going to merge the branch soon.
I have had some odd "why do I have so much history" moments with that. I don't know what other people think about whether we need to be able to go back between views.
(We'd also need to keep it for DMs)
Kekun commentedon Feb 13, 2020
What I do (the simple way) is just to resize the window: it should be able to be 360px wide or less.
The dependency is pretty common and is GNOME: many GNOME apps use it nowadays, including several core apps like Settings and Web. we are going to move the repo to GNOME's GitLab very soon.
Sure, it will need some good design input. :)
Kekun commentedon Feb 13, 2020
We have this adaptive view switcher, which is designed to be in the titlebar when there is enough room, and to move to the bottom of the window when the window becomes too narrow to fit it:
Cawbird perfectly matches that use case, here is how it would look when narrow:
Though ideally we'd like to redesign the available pages a bit.
thibaultamartin commentedon Feb 13, 2020
@Kekun this does look very well, I'd actually love to use this on a linux phone :)
Kekun commentedon Feb 13, 2020
Maybe these pages would work better?
IBBoard commentedon Feb 13, 2020
How would it look when not narrow? Because that's the main thing that I can't work out right now. I can't see how you can fit all of those buttons in along with everything else without it looking cluttered and losing info.
thibaultamartin commentedon Feb 25, 2020
Hej @IBBoard, GNOME Design team tried some mockup for a microblogging client. Those mockups are one year old, but it can give you hints regarding how it could look like.
IBBoard commentedon Feb 25, 2020
Intriguing. The title bar definitely looks too messy though, IMO. And that's with just three sections. Once you get Home/Mentions/Likes/DMs/Lists/Search and then have profile, post, two menus on the right and the close button (and where's "back" for when you dig in to a specific post?) then it looks like it'll be a nightmare.
I'm also not sure whether Libtidy would work well for most desktop users. My window is about 500px wide. That's not enough space to have all of the buttons at the top, but having all of the buttons at the bottom is an alien UI pattern for the desktop.
Posting as a full-window overlay makes sense for mobile, but feels like it unnecessarily swaps content on the desktop.
I'll see if we can include any of it in future, but being mockups then they make a lot of simplifying assumptions and miss some situations.
IBBoard commentedon Jul 21, 2020
For reference, Cawbird apparently works okay on Pine Phone: https://twitter.com/linmobblog/status/1285494259676741632
That's not to say we can't do better (which is why this is staying open). But it does apparently work.
ScardracS-zz commentedon Jul 22, 2020
Hi there.
Actually it works on scale-to-fit on PinePhone (as stated on the tweet) but need some improvements (probably more on OS side than app)
NO-ob commentedon Jul 24, 2020
I think the ui is pretty much flawless on the pinephone, although I dont think its possible to save images due to no right click
IBBoard commentedon Jul 24, 2020
Huh. Is there not a long-click equivalent to right-click? Or some docs about what events people should implement to get a "secondary interaction" method?
NO-ob commentedon Jul 25, 2020
I will test on another de incase it's a phosh issue and report back, just looking at the gnome docs it does mention here there is a GtkGestureLongPress event if thats what you mean
https://developer.gnome.org/gtk3/stable/Gestures.html
4 remaining items
CodedOre commentedon Jul 28, 2020
Just came to my mind, we could join the home screen and the lists-view, making Home an list.
Twitter on iOS does this for example.
I don't get it, to be honest.
As far as I know, this can be done with HdyLeaflet, which can show two widgets if there is space and otherwise shows one and the other as subpage.
CodedOre commentedon Jul 29, 2020
Updated Mockup-Version how i could imagine it if we would make Home an list.
If we would use HdyLeaflet with the lists, then the sidebar would become the "main page" and would reveal the list when selected as an subpage. But then would would also have to make sure that the home list subpage would be shown at startup.
CodedOre commentedon Jul 29, 2020
@Kekun, as you started this diskussion, what are your opinions on this?
IBBoard commentedon Jul 29, 2020
Sorry, developer thinking out loud and not being clear.
Currently, each button relates to a "page" in the UI. Clicking on a button takes you to that panel. They're all in one place and so it is consistent (unless you navigate via a link on those pages, but we'll ignore that as a "stepping in" action).
If you have the libhandy interface then Search is now separate from Home/Favourites/etc. If you click on it then a search box appears. But how does that integrate? Do we instantly replace the page content with the empty search results page? Do we only replace it when they hit Enter? What about when they search, click a tweet and then click "back"? Presumably we'll have to be able to re-select the search button rather than just switching to the search view. And then what about when they do a search and then click the search button again to deactivate it? That's not possible in the current UI. The only real option is to fake a "back" action.
And then there's the search button itself. Currently the search box is in the page and not the header. That gives us plenty of space when narrow, but we'll probably have too many buttons to do it with the search in the header.
Looking at that, I definitely wouldn't do home as a list. It's the main interface for 90% of Twitter usage. It's the thing that you can spend almost your whole time in and still get the entire Twitter experience. And yet it's relegated to being on a par with a minor feature like lists? The fact that that's how Twitter on iOS does it makes me distrust iOS apps for design inspiration! Yeah, if we did multiple feed columns like TweetDeck then a list is displayed in the same way as the home timeline. But we already do that in the UI (and use the same widget to do it).
It might work to do it for Favourites, though. Treating Favourites as a list seems more fitting. It's done by adding tweets instead of people, but it is a curated set of tweets rather than everything from everyone that you follow.
I still can't tell how the HdyLeaflet interface for lists would work, though. The best I can find is this article and a) it's mockups not final code, b) most of them look like someone playing with transitions rather than doing anything functional and c) there's no clear side-by-side of "here's what it looks like in mode 1 and here's what it looks like in mode 2".
Sorry, Missed @NO-ob's comment.
That's odd, because there's a GestureMultiPress created with
gesture_pressed_cbandgesture_released_cbfunction and a call toevent.triggers_context_menu (), which the documentation says "returns whether a EventButton should trigger a context menu, according to platform conventions".All of those interactions are legacy Corebird code that Baedert put in. If it's not right then I'm going to need someone to point me to the docs that explain how it works on mobile, rather than mobile developers just brushing it off as not their problem.
Presumably I'm not the only one with code for gestures in an app that then doesn't work on mobile because they're not the "right" gestures. At which point a brief crib sheet or explainer would be helpful to many people. Unfortunately, I've generally been struggling to find anything for a variety of GUI problems that is more than API docs that assume a strong grounding in how the system thinks (and no "how to think like GTK" articles).
CodedOre commentedon Aug 3, 2020
I am currently reworking my mockup since I want to mention a few other things, but if you want an example of an implemetation
HdyLeaflet, you can take an look at the demo delivered with the libhandy project.Re #57: Restructure name labels to shrink size
Re #57: Approximate a responsive grid layout
Re #57: Ellipsize filtered names
Re #57: Allow quote labels to wrap in tweet lists
Re #57: Make list creation responsive
Re #57: Improve alignment at narrow width
Re #57: Allow profile page to go narrower
Re #57: Adjust location & avatar at narrow widths
Re #57: Make "New List" widget shrink smaller