Mockup for cawbird with libhandy

[CodedOre]

THIS COMMENT WAS MODIFIED

Changelog: - 04.08.2020: Initial Comment - 08.08.2020: - Removed Search as this idea was dropped. - Remove small-sized text in Content. - Added list modifier in Lists overview. - Added new Tweets section. - 13.08.2020: - Make content more simpler for implementation - 25.08.2020: - Modify content display for big window in Home Screen, added image placeholder. - 17.10.2020 First Change: - Changed picture placeholder trough actual image. - Used image is WebBanner from Gnome's Design Team app illustrations - Added media widget mockup - 17.10.2020 Second Change: - Removed "New Tweet as subpage" - Added image option to reply-mockup - 23.10.2020: - Modify MediaWidget Description

So, after already discussing it in an different issue, i now revamped my mockups for an "Cawbird 2.0", staying closer to GNOME's HIG and using the new Libhandy-Library.

Main Window

Like mentioned previously in another issue, the main window would have a few changes:

The buttons in the headerbar are reordered with "back" now the first element on the left followed by "new tweet". On the right side I would place an search button (more about that later) and an application menu, which would also includes the account switcher and menu. One thing to discuss would be if the application menu uses the official icon or if it would be replaced with the account picture, like with the current account menu.

The view switcher could be reimplemented with an adaptive HdyViewSwitcher.

The available Views could be narrowed down to "Home", "Lists" (which would also include favorites), "Mentions" and "Direct Messages", the last could need to be shortened to "DM's" on smaller windows.

Lists View

Since the lists view contains multiple similar lists, this would be a good opportunity to use an HdyLeaflet. This would result in the following result:

When the window is wide enough, an overview of all views are presented as an sidebar and a selected list will displayed left of it. Is the window instead too small, the user would first be presented the overview, and pressing an list name would reveal the list, and return would be possible over an gesture or the back button. The overview also contains an option button for each list for deletion and edit of an list.

The edit options could also be revamped by moving the delete button solely to this view and also adding an editable list of members, offering an delete button for existing members and an add button for new members.

Search

In order to make space in the view switcher, i would place the search button in the headerbar, where it also mostly reside in most GTK-Apps.

However, the search itself stays an independent view, so clicking the button will give you a blank view with the search entry, which is then populated with the search result.

When selecting the search button, we probably want to keep the previous view so when the search is closed again it would go back to the previous view.

Content

I would also redesign how content is displayed. For once, i would use GtkLists with a little space to the window border for an better aesthetic.

The right site of above image shows also how i would remake the detail view of an tweet:

• The tweet selected in an higher view will be highlighted with an bigger text font and an row highlighted with the system accent color.
• Threads replying to the tweet are shown in their own Lists, which has a small indent to the list with the selected tweet. Each thread get their own list, therefore giving a clear distinction between the threads.
• Selecting an different tweet opens a new detail view for the selected tweet.
• If their are tweets multiple levels above or below the current selected tweet, we should indicate this with an arrow an a "x more tweets" text.

I would use for these detail views an HdyDeck, which only shows one view at a time, but would allow an implementation of the back gestures of HdyLeaflet (as far as i know).

Media

In order to avoid pictures to be larger than the screen area, but also to follow better today's UI conventions, i suggest to make the media display a resizeable window with actual window controls. If the user did not resize the media window, it will use the size of MainWindow, otherwise it stores it own size in the settings. Thanks to HdyWindow, we are able to decide fully how content is displayed, so we can allow the media to be the only visible content in the window, showing controls only when you hover over the widget or on mobile tap on it.

The new media display should also include controls, like the still available window buttons, next and previous buttons, and additionally, a playback control for videos and view control buttons to make the media larger (as a default size, media should use their original size, unless this is bigger than the window).

Tweets

I would distinguish between two modes when tweeting.

If you create a new tweet, the user should be presented an clean "Create Tweet"- View with only the new tweet on an dialog. We display an "show emoji"-button only on desktop, as mobile users can insert emojis over the on-screen keyboard.

Images are handled like now and put into an row below the text-input after inclusion. If you have an image in the clipboard and press Insert we could append the new image to this row as well.

If you reply to an tweet, i would not open a new view/dialog, but rather display the edit screen inside the Content view so the user have the context.

---

So far for now. This are some parts how i would think we could improve how Cawbird is designed.

Feedback is welcome.

[IBBoard]

Thanks for all the work on those mock-ups. Lots of good ideas. What do you use to generate them?

Going through a few bits:

For one, i would change the address you receive after you create an account, so it lead right to the oauth page after sign up.

Which page is that? We' use the "OOB" (out-of-band) setting because we don't have a callback to send people to, so Twitter does what Twitter does.

I would also implement the oauth page inside the window using WebKitGTK. The Reasoning behind this is to simplify the process for mobile users, so they don't have to switch applications and have the complete authentication process at one place.

I'm not keen on this. 1) it introduces more dependencies, 2) all those desktop users (and presumably many mobile users) who are already logged in with their default browser can't just click "Authorise", 3) lots of password managers are integrated with browsers (especially on desktop) so you won't have those, and 4) I'm sure there used to be advice (if not a rule) from Twitter to specifically not embed a browser because it defeats the idea of "we can't get hold of your password, so we just request a token". Numbers 2 and 3 are a big annoyance for me on apps like Steam that insist on using a built-in browser when I pay using PayPal.

The edit options could also be revamped by moving the delete button solely to this view

Maybe. It would certainly be cleaner. But what's the cost in terms of having to go in to each list (which then loads the latest tweets) just to delete it? As a user, I'd rather be able to just delete from the list of lists without viewing each list.

and also adding an editable list of members, offering an delete button for existing members and an add button for new members.

That's probably a separate feature request anyway, but I don't use lists so it is WAY down the priority stack.

However, the search itself stays an independent view, so clicking the button will give you a blank view with the search entry, which is then populated with the search result.

When selecting the search button, we probably want to keep the previous view so when the search is closed again it would go back to the previous view.

I suspect I'm going to need to do a lot of reading and tinkering to find out how to make that work 😁 But it is the right thing to do.

For once, i would use GtkLists with a little space to the window border for an better aesthetic.

Personally, I was never particularly taken with the way Baedert was redesigning the app. And I don't like the "Lists" view as we have it. All that the spacing will do is make me have the window a little wider. We already have the whitespace inside the list.

The tweet selected in an higher view will be highlighted with an bigger text font

It already is, so we're good there 🙂

and an row highlighted with the system accent color.

That seems like a bad idea. We're already making it bigger, so why mess with the colour as well? Do you have any examples of that as a good UI/UX pattern? I'm not even sure what "accent" colour most themes have (if any) other than the selection colour, which should be reserved for selections. Nothing in the GTK3 Widget Factory appears to use an accent colour in that way.

Selecting said answer would expand the row to an separated box with an small indent which shows replies to selected reply.

Interesting. But that feels like it'll get very messy very quickly! Also, each expansion is a new request and you're rate limited on requests, so making it to easy to burn through your requests probably isn't helpful overall.

Replies to replies and the tweet the selected tweet is replying to are shown in an smaller style, and selecting these would open a new tweet detail view.

Shrinking the text size seems like a bad idea. We already have people having issues with font sizes being too small (#33).

If their are tweets multiple levels above or below the current selected tweet, we should indicate this with an arrow an a "x more tweets" text.

There probably is something better that we can do. But we can't know how many more tweets there are without fetching them. If we've fetched them, why not show them?

Personally, I'd like to just load them in automatically but keep the selected tweet at the top of the page (so you get more and more space to scroll up in to, and the scrollbar shows your position, but the widgets don't move as it loads). So far I've not found any way of getting GTK to do that.

[CodedOre]

Thanks for all the work on those mock-ups. Lots of good ideas. What do you use to generate them?

Thanks! I just use the regular Inkscape with Gnomes Mockup-Resources. I have uploaded the source for the mockups in an repository on my profile.

---

Initial Setup

For one, i would change the address you receive after you create an account, so it lead right to the oauth page after sign up.

Which page is that? We' use the "OOB" (out-of-band) setting because we don't have a callback to send people to, so Twitter does what Twitter does.

Oh, that's probably quite unclear. I meant the authentication site with oauth site. And for my suggestion you could create a link to the signup-page, witch has as argument context with oauth and later the oauth key. This is also the url twitter uses when you click on "sign up to twitter" if you're opening the authentication site.

I would also implement the oauth page inside the window using WebKitGTK. The Reasoning behind this is to simplify the process for mobile users, so they don't have to switch applications and have the complete authentication process at one place.

I'm not keen on this. 1) it introduces more dependencies, 2) all those desktop users (and presumably many mobile users) who are already logged in with their default browser can't just click "Authorise", 3) lots of password managers are integrated with browsers (especially on desktop) so you won't have those, and 4) I'm sure there used to be advice (if not a rule) from Twitter to specifically not embed a browser because it defeats the idea of "we can't get hold of your password, so we just request a token". Numbers 2 and 3 are a big annoyance for me on apps like Steam that insist on using a built-in browser when I pay using PayPal.

Well, you're right about that. I could argue that Gnome Web (which is the browser most suited for Linux Phones) would use the same password storage like WebKitGTK (as it uses this as well), but i can agree that this is too much effort for too less advantage.

---

Lists View

The edit options could also be revamped by moving the delete button solely to this view

Maybe. It would certainly be cleaner. But what's the cost in terms of having to go in to each list (which then loads the latest tweets) just to delete it? As a user, I'd rather be able to just delete from the list of lists without viewing each list.

We could keep the option to delete the list from the overview. I have mostly a problem with the big red "delete" button on the detail view. If you're already there I would think there would be no problem in clicking "edit". But that is my opinion.

---

Content

For once, i would use GtkLists with a little space to the window border for an better aesthetic.

Personally, I was never particularly taken with the way Baedert was redesigning the app. And I don't like the "Lists" view as we have it. All that the spacing will do is make me have the window a little wider. We already have the whitespace inside the list.

Can you explain this further?

Selecting said answer would expand the row to an separated box with an small indent which shows replies to selected reply.

Interesting. But that feels like it'll get very messy very quickly! Also, each expansion is a new request and you're rate limited on requests, so making it to easy to burn through your requests probably isn't helpful overall.

As far as i can tell by the behavior of Cawbird this would not make that much of an difference, as right now replies are only loaded when selecting the tweet. With this we would only change where they would be displayed.

Replies to replies and the tweet the selected tweet is replying to are shown in an smaller style, and selecting these would open a new tweet detail view.

Shrinking the text size seems like a bad idea. We already have people having issues with font sizes being too small (#33).

Okay, good point there.

[IBBoard]

And for my suggestion you could create a link to the signup-page, witch has as argument context with oauth and later the oauth key. This is also the url twitter uses when you click on "sign up to twitter" if you're opening the authentication site.

We could add a "sign-up" button. But it seems like a minority use case. Most people will be looking for a Twitter client because they have a Twitter account. I don't think many people will get Cawbird first and then go "Oh, it needs a Twitter account?"

For once, i would use GtkLists with a little space to the window border for an better aesthetic.

Personally, I was never particularly taken with the way Baedert was redesigning the app. And I don't like the "Lists" view as we have it. All that the spacing will do is make me have the window a little wider. We already have the whitespace inside the list.

Can you explain this further?

Corebird had a "next" branch that later became "master". It was a redesign by Baedert. I can't rebuild it at the moment because of various GTK4 errors, but it was much more of a "each tweet is a rounded rectangle with lots of space around it" design. I never liked it because it wasted so much space.

Interesting. But that feels like it'll get very messy very quickly! Also, each expansion is a new request and you're rate limited on requests, so making it to easy to burn through your requests probably isn't helpful overall.

As far as i can tell by the behavior of Cawbird this would not make that much of an difference, as right now replies are only loaded when selecting the tweet. With this we would only change where they would be displayed.

Yes, it's still just one interaction. But it's an "expand a thing (suggesting we already have it loaded)" interaction rather than a "here's a whole reload of the page (so it's probably a heavy-weight action and you won't do it too often)" interaction.

[Kekun]

Regarding entering the PIN, note libhandy offers HdyKeypad which is used for phone numbers but also PIN/PUK-like codes.

[CodedOre]

Alright, i have updated a few things.

Setup is now gone, as the WebKit-idea is dropped. I would also not use HdyKeypad, as i believe an number-only mode of Squeekboard should do it as well, without having to make big changes in the app.

I have made the small text tweets to normal size. However i am still the opinion that the use of clearly distinguishable lists would be good to distinguish between different reply-threads, and we should show more reply levels than just one to have a clearer look on threads.

And i added a mockup for tweeting, where i need some feedback.

[IBBoard]

Search is now gone, as the WebKit-idea is dropped.

??? Embedded initial setup was dropped, but I think the search is fine.

we should show more reply levels than just one to have a clearer look on threads.

Find me a way to a) reliably find multiple levels using just the Search interface available to apps and b) using standard widgets in a way that is clear to people and I'll look at it! As it is, the "multi-level self-reply" followed by a single-level of direct replies of mentioned people and direct replies from other people is the best improvement I could manage.

I'm also re-considering the spacing on the main tweet list. DMs and Lists already have the white space (at least on the initial lists) and the titles look odd without the spacing (Search uses headers to get the same background colour). So maybe spacing everywhere is more consistent.

But at the same time I don't like first main window example. What part of UX and HIG says that the app gets to override the user's preference for width? If I make my browser or text editor wider, it's because I want more text on a single line. Why would Cawbird not do the same? Why should it cap it at (say) 500px? Also, I can't find any example apps with large spaces like that.

[CodedOre]

Search is now gone, as the WebKit-idea is dropped.

??? Embedded initial setup was dropped, but I think the search is fine.

Well, i should write what i mean... I meant obviously Setup.

[CodedOre]

we should show more reply levels than just one to have a clearer look on threads.

Find me a way to a) reliably find multiple levels using just the Search interface available to apps and b) using standard widgets in a way that is clear to people and I'll look at it! As it is, the "multi-level self-reply" followed by a single-level of direct replies of mentioned people and direct replies from other people is the best improvement I could manage.

As far as i can tell the new Twitter API v2 (which apparently you have to switch to eventually) will include the possibility to track conversations using an conversation_id, so this may solve a).

Considering b), I think if we give each replying thread it's own list below the selected tweet should give an clear distinction between them. I also updated the content part of my mockup for this idea.

I'm also re-considering the spacing on the main tweet list. DMs and Lists already have the white space (at least on the initial lists) and the titles look odd without the spacing (Search uses headers to get the same background colour). So maybe spacing everywhere is more consistent.

But at the same time I don't like first main window example. What part of UX and HIG says that the app gets to override the user's preference for width? If I make my browser or text editor wider, it's because I want more text on a single line. Why would Cawbird not do the same? Why should it cap it at (say) 500px? Also, I can't find any example apps with large spaces like that.

The reason for capping the text on a certain size is to provide better readability. A common rule in the print publishing for example is to have 58 characters or 11 words per line before doing a line break to ensure a text is better to read, and for my knowledge this also applies to text on a screen.

I do know that we have currently a big space on an desktop sized window and it might a worth thinking how to use it. I currently think we could display some detail information there, so expect an update to the mockups in some days.

[IBBoard]

As far as i can tell the new Twitter API v2 (which apparently you have to switch to eventually) will include the possibility to track conversations using an conversation_id, so this may solve a).

Well, yes. Now that Twitter have added an API for it then it'll be a lot easier! But it wasn't there when I posted and Twitter only ever made things harder for devs before 😉

Considering b), I think if we give each replying thread it's own list below the selected tweet should give an clear distinction between them. I also updated the content part of my mockup for this idea.

How would that play with accessibility? Currently you get a list of replies and the screen reader reads "Reply list with X items" and then reads the tweets. You can then use the arrow keys to navigate down through the tweets. If each tweet is an individual list then it's going to be a nightmare for screen readers.

The reason for capping the text on a certain size is to provide better readability. A common rule in the print publishing for example is to have 58 characters or 11 words per line before doing a line break to ensure a text is better to read, and for my knowledge this also applies to text on a screen.

I'm familiar with the readability of long lines of text. Which is why most people won't full-screen it. But what if the user maximises it because they follow art accounts and they want the images to be big? Why do we define the maximum size for that rather than the user?

I do know that we have currently a big space on an desktop sized window and it might a worth thinking how to use it. I currently think we could display some detail information there, so expect an update to the mockups in some days.

Sounds interesting. I guess it'll be easier for something that isn't the home timeline. But from what you've said about the HdyLeaflet, we'd have to find a way to do it so that the timeline is the default bit, not the equivalent of the list-of-lists.

[CodedOre]

Considering b), I think if we give each replying thread it's own list below the selected tweet should give an clear distinction between them. I also updated the content part of my mockup for this idea.

How would that play with accessibility? Currently you get a list of replies and the screen reader reads "Reply list with X items" and then reads the tweets. You can then use the arrow keys to navigate down through the tweets. If each tweet is an individual list then it's going to be a nightmare for screen readers.

That's a good point, I hadn't thought of that...

But if every new Thread would be it's own list, would it then be possible to let the screen reader reads "Reply list with X threads" and then selecting first a thread and then going through the items in this thread?

---

Considering the window space story, i have now four mockups below what could we do with an big window, while keeping the text capped at an certain lenght.

First of all the current state in my mockup:

So, the first idea i had was to simply display a second column with some content. At first i thought about displaying more tweets in one view, but this would probably not doable considering how to handle this when scrolling down:

Next idea was to display some extra information, like your own account on the home site or the list information on the list view. But there again would be the question what to put there:

And finally what I would prefer now would probably this: Keeping the text capped and placing things like the tweeter and retweet, like, etc. counter on the sides, which could look like this:

[IBBoard]

But if every new Thread would be it's own list, would it then be possible to let the screen reader reads "Reply list with X threads" and then selecting first a thread and then going through the items in this thread?

Not that I've found. I thought it would make sense to say "Quoted Tweet" before reading the quoted tweet (so that it differentiates the quoted content from reading tweet content) but it needs a widget with a description that isn't a container to do that. And I'm not going to add a dummy icon just to force it to do that (especially since "read on hover" then wouldn't behave consistently with keyboard navigation reading)

So, the first idea i had was to simply display a second column with some content.

Yeah, I'm sure there are people who would love multi-column views (although that's normally in the context of showing a home timeline and replies and something else) but I agree it won't make sense here. Splitting one timeline between two lists would be a nightmare, and having some kind of "scroll the first list then the second list" behaviour would just be confusing and weird!

Next idea was to display some extra information, like your own account on the home site or the list information on the list view. But there again would be the question what to put there.

I can see the point with the lists (although putting it at the top seems more consistent, as you had it before) but putting your own profile info in there on the home timeline seems like we're filling space for the sake of it. I know who I am, I don't need my home profile to tell me!

And finally what I would prefer now would probably this: Keeping the text capped and placing things like the tweeter and retweet, like, etc. counter on the sides.

I'm still not 100% convinced on hard capping the length, but a "responsive" view that unstacks widgets if it can would make good use of the extra width (assuming anyone ever makes the app that wide!). If only I had the first clue as to how to do that in GTK without loads of really hackish code! (Ditto the length cap - pixels!=characters, and different fonts are different widths, so there's a lot of calculation to work out the "right" width to cap off at)

[IBBoard]

I've just been looking at package versions, and whenever this gets implemented then it's going to have to be a big version jump, because we're going to drop several OSes.

According to pkgs.org, we can reliably get libhand 0.0.13+ on Fedora and Debian (because we don't support Stable anyway), but not on CentOS and only on Ubuntu 20.04+ and openSUSE Leap 15.2 and Tumbleweed (not Leap 15.1).

But Leap 15.1 goes EOL in November, so it's mainly CentOS and old Ubuntu that we lose.

I don't know what we miss by being limited to 0.0.13 features.

[CodedOre]

I don't know what we miss by being limited to 0.0.13 features.

We would miss HdyDeck, which was introduced in 0.80.0 and would certainly help with implementing the Content-Part.

With 0.80.0 libhandy has also gone beta, so it has the libhandy-1 identifier, so we would need to handle an stable and an alpha library, for example in meson.

So, i would propose to use at least version 0.80.0. Using libhandy-1 would of course limit us again, as I don't know if Ubuntu would backport the stable libhandy into 20.04.

---

As a side note I would also want to note that I will start working on the port to libhandy.

[IBBoard]

Anything above 0.0.13 limits us to Fedora and Debian at the moment. I'm running openSUSE so we can't cut that off(!) and cutting off support for Ubuntu's current LTS seems unwise. 0.80.0 was only released in May, so the chances of most distros picking it up soon seem slim.

I could try rebuilding it from the Gnome:Next repo for the official builds, but that's a lot of maintenance overhead and doesn't help for each distro's official packages.

And before anyone suggests it, no, Flatpak and Snap are not a suitable solution 😉 I've already had to accept a pull request to update the Gnome version for the Flatpak, rather than just letting the host distro deal with all that stuff.

[CodedOre]

Anything above 0.0.13 limits us to Fedora and Debian at the moment. I'm running openSUSE so we can't cut that off(!) and cutting off support for Ubuntu's current LTS seems unwise. 0.80.0 was only released in May, so the chances of most distros picking it up soon seem slim.

Also true... I have look at pkgs.org and apparently even Arch don't have libhandy-1? So I still have hope this could change.

[CodedOre]

But I will avoid using HdyDeck.

[IBBoard]

If and when it becomes more widely available then we can update and look at using newer features.

Although, looking at https://twitter.com/alexm_gnome/status/1232341723206033408 then I'm not convinced by the HdyDeck anyway. Why is my "deeper" item coming in over the top? And where does it disappear to? Is it a side menu that I can always pull back in or is it swapping or what? It doesn't feel like it's clearly conveying the interactions and relationships between views, IMO.

If it works with gestures where stacks don't then that's positive (for the minority who uses gestures). But I'm less sure about the actual implementation.

[CodedOre]

Although, looking at https://twitter.com/alexm_gnome/status/1232341723206033408 then I'm not convinced by the HdyDeck anyway. Why is my "deeper" item coming in over the top? And where does it disappear to? Is it a side menu that I can always pull back in or is it swapping or what? It doesn't feel like it's clearly conveying the interactions and relationships between views, IMO.

If it works with gestures where stacks don't then that's positive (for the minority who uses gestures). But I'm less sure about the actual implementation.

I strongly suggest you to give the demo of libhandy a try (with Gnome Builder you just need to clone the repo and run it), as this can better explain how HdyDeck works than I could do with text here.

It would allow for an easy way to implement a detail view with a back gesture, so I found it a good option for when you open a tweet detail view.

[IBBoard]

Just had a quick test of it (for reference - it's in "examples" in https://gitlab.gnome.org/GNOME/libhandy, not the separate "libhandy-demo" that you can find).

It's basically what I'd picked up from the few snippets of video that I'd found. I can't see us using most of the widgets and I still think that the default animations are wrong (under/over rather than slide). I'm not really taken by all the movement either - windows shouldn't move and stay where they are!

(Also, it looks like I might need to update my Adwaita-derivative theme - some bits don't get styled well by default for me!)

[BrainBlasted]

Something you might take inspiration from is the mockups @bertob and I made for a Mastodon app:

[CodedOre]

Most of the things covered by this mockup is already included in mine as well. I also already started working on it in my personal fork of Cawbird.

If you have something that could be improved in my mockup, I am glad to hear it, but otherwise I think we already have an consensus on how we will implement this.

[BrainBlasted]

Ah, apologies 😅 Just wanted to share some additional ideas that might be of interest.

[CodedOre]

No problem. Like I said, if you have an suggestion what could be done better, you can mention it.

It is just that the mockup was already complete...

[BrainBlasted]

Perhaps at mobile sizes the main list could fit snugly to the window?

Also, for GNOME apps we're moving toward circular avatars, with HdyAvatar providing that in a neat way. Would be cool to have avatars consistent across third party apps and the GNOME core. See: https://gitlab.gnome.org/GNOME/Initiatives/-/issues/20

[CodedOre]

Perhaps at mobile sizes the main list could fit snugly to the window?

Could be an option, however i plan to use an small indent in the tweet detail view, see the Content section of my first comment.

Also, for GNOME apps we're moving toward circular avatars, with HdyAvatar providing that in a neat way. Would be cool to have avatars consistent across third party apps and the GNOME core. See: https://gitlab.gnome.org/GNOME/Initiatives/-/issues/20

Already discussed.

[CodedOre]

Another topic: As I do my ongoing work in porting Cawbird to libhandy, the problem with 1.0.0 vs. 0.0.13 becomes greater and greater. Between libhandy0 and libhandy1 there were quite a few differences made, and even with some tricks to make the difference not that noticeable it becomes more and more an problem.

@IBBoard, in order to take full advantage of libhandy I think it will be necessary to do a minimum of 0.0.80 for libhandy. I am aware that a lot of distributions not having this now, but the way it is currently going we would already have a sort-of legacy version compiled for libhandy0 with special tweaks, so it could be easier to continue the old UI for these versions. So far i also did not modified background code (only UI Classes), so it should be doable to maintain it...

[IBBoard]

Okay. I was considering making a big UI rewrite into "v2.0", so we can always branch at that point. I don't expect we have many CentOS or openSUSE Leap users, and Ubuntu LTS users will have the option of moving to a non-LTS or sticking with the 1.x branch (which will just get bug fixes) while looking jealously at Debian users 😄

Maybe someone will put libhandy in a PPA or something. Unfortunately there isn't an existing build of libhandy on OBS that I can mirror, so it's not something I can trivially bundle.

[mufeedali]

in order to take full advantage of libhandy I think it will be necessary to do a minimum of 0.0.80 for libhandy.

You should be targetting >= 0.90.0, which was when the API froze. Most rolling distributions now have 1.0.0, so that's not really a concern. Fedora also has a libhandy1 package.

[CodedOre]

You should be targetting >= 0.90.0, which was when the API froze. Most rolling distributions now have 1.0.0, so that's not really a concern. Fedora also has a libhandy1 package.

That is basically the plan. For the new UI the only target is libhandy. >= 1.0.0, which will probably mean that for Ubuntu LTS we will continue updating the v1 branch of Cawbird.

[CodedOre]

Alright, I now added a mockup for how i want to remake the media widget. This would be large change compared to the current way to display this (but I would say in a better way).

Also, @IBBoard, in the mockup for tweeting, i have to options on how to display the entry to reply to an tweet (both images on the left). What would you prefer when I would implement one of these?

[IBBoard]

Yeah, the media widget mostly makes sense. Just not the rounded corners, please! Images are rectangular, so we shouldn't be cropping corners. Zoom controls have always been at the back of my mind and the current "Image X of Y" was something I hacked in quickly because of #172.

The only thing that might be confusing is the back/close buttons. Is it a separate dialog? (In which case, what does back do?) Or is it a sub-page of the main window? (In which case, that REALLY doesn't work for people who use it in a narrow column but want big images, and suddenly making the media window have a way to close the entire app seems like it'll frustrate LOTS of users!)

I'm also assuming that zoom is only for images, not videos.

And could we do a progress bar (rather than a slider) for GIFs? Something that shows when it's looping, but doesn't let you move it.

With the tweeting mockups, it looks like the difference is whether we keep a dialog or turn it into a page? Given that 1460px tall by 600px high then a page is going to have a LOT of space on it! Would there be any benefit (or drawback) of using the overlay for normal tweeting?

For tweeting replies then I'd go for in-line. It wouldn't integrate as nicely with the current "right-click and reply" actions, but I the mockups are moving to "always visible" buttons (which probably makes more sense anyway). Hopefully attaching images will be okay as well without too much clutter.

[CodedOre]

The only thing that might be confusing is the back/close buttons. Is it a separate dialog? (In which case, what does back do?) Or is it a sub-page of the main window? (In which case, that REALLY doesn't work for people who use it in a narrow column but want big images, and suddenly making the media window have a way to close the entire app seems like it'll frustrate LOTS of users!)

Well, i did thought of the media widget to work similar to how i currently implemented the modifier widgets in the SettingsDialog: to be an subpage which is opened in the main window, with back to return from the view (and close just because it's still the main window). However, for the use case you mentioned (narrow column but want big images) a dialog would be the better choice. Even tough you could just resize the window for that.

And could we do a progress bar (rather than a slider) for GIFs? Something that shows when it's looping, but doesn't let you move it.

Actually a good idea. Noting that for when I will implement the widget.

With the tweeting mockups, it looks like the difference is whether we keep a dialog or turn it into a page? Given that 1460px tall by 600px high then a page is going to have a LOT of space on it! Would there be any benefit (or drawback) of using the overlay for normal tweeting?

As it was mentioned in the mockup comment, my thought was that if you create a new tweet, it would only be on mobile a page, and on desktop an dialog, but it is probable much easier to just make it a dialog, especially as there is not a real distinction between this running on mobile or on desktop. So I drop the mobile page variant of "Create a new tweet" from the mockup.

For tweeting replies then I'd go for in-line. It wouldn't integrate as nicely with the current "right-click and reply" actions, but I the mockups are moving to "always visible" buttons (which probably makes more sense anyway). Hopefully attaching images will be okay as well without too much clutter.

I added the image placeholder to the mockup. Seeing this, it is most reasonable to use it in-line. The pop-up looks cooler with the keyboard, but coolness doesn't help if you loose the context of which tweet you replying to...

Speaking of which, I think it will be helpful to mark the tweet you replying to with the accent color, which should be doable, as we probably can use a style class taking the color of the the "select" style of an ListBoxRow.

[IBBoard]

Even tough you could just resize the window for that.

I don't want to resize my window every time I want to full-screen an image and then resize it back again afterwards 🙂 My main window is just the right width for showing tweets without taking too much space or getting to line lengths that are bad for reading fatigue (which they definitely could do on a 1440p monitor!).

And if the image doesn't go wider than the window then there's little point in clicking most images because the preview is most of the window width anyway!

Speaking of which, I think it will be helpful to mark the tweet you replying to with the accent color, which should be doable, as we probably can use a style class taking the color of the the "select" style of an ListBoxRow.

Interesting. It looks okay in your mockups and does add some useful context, but I'd have to see how it works in different themes (and whether I need to change my Adwaita Dark Green theme!).

[IBBoard]

Just skimming some tickets to see what we still have to do and noticed #21 requesting an unread counter.

We do track how many tweets are unread (so that we can say when there are zero) but the UI is a bit small at the moment, but the libhandy buttons might be big enough to handle an "unread badge" that goes to "99+". Would that work? Can the buttons do that?

[CodedOre]

We do track how many tweets are unread (so that we can say when there are zero) but the UI is a bit small at the moment, but the libhandy buttons might be big enough to handle an "unread badge" that goes to "99+". Would that work? Can the buttons do that?

First of all: Wasn't there a problem with "You can't place you viewport at a certain point in a ListBox"? Think I've read this in one issue...

Secondly: libhandy functionality doesn't contain a special new button for this case. So what I would do would be similar to that "Show x more Tweets" in my Content-view mock-up: Utilizing an ‘GtkListBoxRow‘ with the counter and when activating it to show the new tweets.

[IBBoard]

I don't think we've got any problems with viewports and list box positions. I've had to do some odd things so that scrolling offsets work, but I got "scroll to keep things in view" working across the multiple lists for the TweetInfo page. Unless I'm forgetting something.

What I was thinking of for #21 is a badge rather than a special list box row, though. The idea is that rather than just seeing "I'm on the home timeline and I've got a dot showing that there are one or more mentions in my Mentions timeline - is it worth me checking" then the dot is bigger with a number in and you get to see that there are N new mentions waiting (or, probably more useful, you're looking at mentions or searches or something and you can see that there are 30 new tweets waiting on the home timeline).

We could do it as a tooltip, but that doesn't help mobile users and it still requires some interaction rather than just making the information visible to the user.

Currently we have BadgeRadioButton to customise Gtk.RadioButton and do a custom rendering over the top. But we're in full control of the radio buttons for the tabs. I don't know if we can do the same with libhandy.

[CodedOre]

I don't think we've got any problems with viewports and list box positions. I've had to do some odd things so that scrolling offsets work, but I got "scroll to keep things in view" working across the multiple lists for the TweetInfo page. Unless I'm forgetting something.

Could just be me misremembering something.

What I was thinking of for #21 is a badge rather than a special list box row, though. The idea is that rather than just seeing "I'm on the home timeline and I've got a dot showing that there are one or more mentions in my Mentions timeline - is it worth me checking" then the dot is bigger with a number in and you get to see that there are N new mentions waiting (or, probably more useful, you're looking at mentions or searches or something and you can see that there are 30 new tweets waiting on the home timeline).

We could do it as a tooltip, but that doesn't help mobile users and it still requires some interaction rather than just making the information visible to the user.

Currently we have BadgeRadioButton to customise Gtk.RadioButton and do a custom rendering over the top. But we're in full control of the radio buttons for the tabs. I don't know if we can do the same with libhandy.

Haven't checked it, but as far as I know you can place a simple dot badge in the ViewSwitcher using the notify packing property.

But we would need to modify the ViewSwitcher to add a number to that badge.

Will look into possible solutions tomorrow. Already late here in Germany.

[IBBoard]

Maybe something to add as a libhandy feature request 🙂

[CodedOre]

So, like I (and you) already mentioned, we have the "needs attention"-badge in a view switcher.

The idea is that rather than just seeing "I'm on the home timeline and I've got a dot showing that there are one or more mentions in my Mentions timeline - is it worth me checking" then the dot is bigger with a number in and you get to see that there are N new mentions waiting (or, probably more useful, you're looking at mentions or searches or something and you can see that there are 30 new tweets waiting on the home timeline).

I have tried how it could be placed with my mockup, but to be honest: I doubt there is a good point where you could place an big label with an potential big number, especially when we are dealing with the "narrow" style of the ViewSwitcher... So, I personally would not pursue that idea.

However, I have created two prototypes for an "You have unread tweets" inside the tweet view.

Either by doing it with an app-notification:

or with an action bar at the bottom:

[IBBoard]

The bars may be useful for the current view, but they're not helpful between views because we will run out of space if we show "N more tweets in [view]" for each view.

There looks like there should be plenty of space in either placement of the buttons. This is a really quick "24px circle" paint. The notification text is the same size as the button text, but it might be okay (and appropriate) a couple of pixels smaller. It's how "notification badges" look on most interfaces, and it's not obscuring anything. We can probably get away with 22px circles.

[CodedOre]

Yes, that could work. It probably leaves the question on the implement it.

We could extend ’HdyViewSwitcherButton’ with an overlay showing such an label, I guess. It would just require to also extend all other view Switcher with that functionality.

[IBBoard]

That's my concern - I don't know how deep the changes will need to be. We should be able to use Cairo to paint over the button in the draw() function (as we do now for the dot on the radio button). But if those buttons are within another widget then the dependencies could get messy.

At least we'd be doing it in Vala rather than C, though!

[CodedOre]

Don't think we need to use Cairo for this. Should probably be doable with an GtkOverlay and a special themed label, if you ask me.

Mentioning @Kekun and @exalm as libhandy programmers, maybe they can say something to this topic.

[alice-mkh]

Not properly supported, sorry. You can always draw stuff on top of the switcher, but that's a hack; and GtkStack only has a boolean value that we can use, needs-attention. If you want that, it will have to go to GtkStack first.

[IBBoard]

I did consider an overlay (it's how I'm doing the "delete DM" selection buttons), but I didn't know whether that was more or less trouble than the current approach that Baeder uses.

@Exalm - is it worth supporting "notification badges" in a future version? Especially given their prevalence in mobile, and the origins of libhandy. Or are you saying that the underlying GTK stack needs to support it before the libhandy widget can support it?

[alice-mkh]

Or are you saying that the underlying GTK stack needs to support it before the libhandy widget can support it?

Yes. I mean, do you see any API for setting the number a badge can use?

[IBBoard]

I don't know how libhandy implements it, so I don't know what APIs there are and aren't for any widget. CodedOre has been dealing with all of that so far.

Coming from an OOP background, the fact that it's not there doesn't mean that it can't be there. I'd normally try to make an interface that defines the numeric property and then connect to changes in that if it exists, or fall-back to the needs-attention property if it doesn't implement the interface. But maybe C doesn't make that easy.

[CodedOre]

I have taken a small look into the code for the ViewSwitcher.

The HdyViewSwitcherButton could be extended by an GtkOverlay with an label with special css to give it a the label look. Should be doable.

But then we need to extend HdyViewSwitcher* (three of them) to give this label some information. My idea was to extend these classes just for Cawbird (and adding the needed information over an different way than the other) and call it a day, so my question at @Exalm was more about if this would be the right approach for an app-only extension.

However, as @Exalm also pointed out, if this should be upstream, we also need to extend the GtkStack, as this is the one given the ViewSwitcher all information over the items. However, there would be the question if upstreaming this would make sense (are there other apps which could benefit from such an feature?).

It would also bump up the requirements to GTK4, since GTK+ 3 don't get new features.

[IBBoard]

It might be a long-term benefit to upstream it, but I can't see Cawbird moving to GTK4 any time soon. We're already going to be cutting off some older Ubuntu users (IIRC) because of the minimum version of libhandy that we want to use. GTK4 currently seems to cut off ALL Ubuntu and Debian users and lots of other distros.

[alice-mkh]

My idea was to extend these classes just for Cawbird (and adding the needed information over an different way than the other) and call it a day, so my question at @Exalm was more about if this would be the right approach for an app-only extension.

I have no idea what you mean by "extend" here. If you mean subclass, it's impossible, because:

1. HdyViewSwitcherButton is private
2. None of those classes are derivable