cawbird
cawbird copied to clipboard
IBBoard
Mockup for cawbird with libhandy
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.
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.
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.
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.
Regarding entering the PIN, note libhandy offers HdyKeypad which is used for phone numbers but also PIN/PUK-like codes.
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.
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.
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.
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.
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.
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:
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)
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.
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.
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.
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.
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.
Although, looking at https://twitter.com/alexm_gnome/status/1232341723206033408 then I'm not convinced by the
HdyDeckanyway. 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.
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!)
Something you might take inspiration from is the mockups @bertob and I made for a Mastodon app:
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.
Ah, apologies 😅 Just wanted to share some additional ideas that might be of interest.
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...
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
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
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...
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.
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.
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.
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?