Merge lp:~oldmanuk/gwibber/twitter-user-messages-tab into lp:gwibber/1.2

[Dominic Evans]

[Dominic Evans (oldmanuk)]

I consider this now ready to be merged. User's tab will always display a link to the external profile page for that user and also copes with user's who have protected their updates.

[Greg Grossmeier (greg.grossmeier)]

Works well. Would be nice to support laconica/identica as well.

Also, I have one, slightly large, concern: Users now are accustomed to being brought to the user's profile page in <default browser> instead of it doing this. It might make sense to provide this function as part of the right-click menu instead. Right click -> "Open User's timeline in new tab"

With this patch there is no way of getting to the uesr's profile page from gwibber.

[Dominic Evans (oldmanuk)]

> With this patch there is no way of getting to the uesr's profile page from gwibber.

Not true, once the user's tab has loaded there is a direct link to their external profile at the top of the tab.

[Greg Grossmeier (greg.grossmeier)]

Ok, true. But I still think the user experience is hurt if they have to first open a new tab then click on another link to get to a user's profile page.

I'm not saying this feature is unwanted; the opposite in fact. I'm just expressing my concern over the choice of interface implementation.

[Dominic Evans (oldmanuk)]

"OK, true. But I still think the user experience is hurt if they have to first open a new tab then click on another link to get to a user's profile page."

I did consider this whilst implementing the function. But once the functionality is available in gwibber I couldn't really think of why anyone would really need to view the external profile page - and if they did then it would still be available to them from the tab.

I wouldn't want to add a context menu to choose but perhaps I should add another preference checkbox to allow them to choose if profiles are opened externally or internally, defaulting to internally.

[Greg Grossmeier (greg.grossmeier)]

Either way, for this to be considered for merging it needs to be consistent between all services (that apply). So, that means the required changes need to happen for identica/laconica/facebook/etc.

Whether or not it is merged I think should be up to Ryan as it is a large change in the way things are done.

[Dominic Evans (oldmanuk)]

"Either way, for this to be considered for merging it needs to be consistent between all services (that apply). So, that means the required changes need to happen for identica/laconica/facebook/etc."

It will happen for identi.ca and laconi.ca, but not for facebook (as their API doesn't support it)

However, I wouldn't necessarily hold out the merge waiting for identi.ca & lacon.ica support as we're not currently targeting a particular milestone. Once we have the focus of a milestone release date then we can consider whether it would need to be held out waiting for the identi.ca/laconi.ca support. Until then, it makes sense (to me) that we merge now while the impact is lower, and I will develop the accompanying identi.ca/laconi.ca support whilst simultaneously getting decent feedback from the twitter community on whether it is a good feature / worthwhile / performant etc.

I will wait to hear what Ryan thinks though :)

[Ryan Paul (segphault)]

I'm pretty comfortable with your implementation. I think it's fine to merge this now. I'd like to have it fully supported for identi.ca/laconi.ca too before 1.0.

At some point in the future, I think it would be advantageous to have a single config item in the preference dialog that the users can toggle to specify whether links should load in tabs within the client or in their browser. This option should be applicable to search, tag, group, user, etc.

review: Approve

[lp:~oldmanuk/gwibber/twitter-user-messages-tab]

171. By Dominic Evans on 2009-02-03

Merge from lp:gwibber prior to merging into lp:gwibber