Experimenting with the UI
Alejandro Gómez
- Tabs with different searchs (for instance to follow various hashtags
at the same time).
- Tabs for viewing conversation threads such as replies or DMs and
have them updated when new relevant tweets are sent. I use Twitter
mainly for interacting with friends and frequently have couple of
conversations going on at the same time, it would be nice to spawn new
tabs when a conversation starts: it eliminates the "noise" of other
tweets.
- Tabs for lists (currently is being implemented so that's great).
- Being able to make a search in the current timeline (searching for
terms or regexes within the tweets that I'm viewing).
Right now I'm experimenting a bit in that direction:
https://github.com/alejandrogomez/tyrs/tree/experiments
Here is a brief description of what I've done so far concerning to the
UI.
I have implemented a `TimelineBuffer` widget, which has a timeline
associated to it and is able to render the new statuses as the
timeline it contains is updated. The timeline it contains is a
`Timeline` object, with a function (an API call) that retrieves its
corresponding new statuses and optional arguments for that function.
As an example, we could have a timeline with the API call
`GetUserTimeline` associated to it and it will be the "home" timeline;
and another one with `GetSearch` API call associated with the arg:
"#tyrs" and it will retrieve the tweets containing that hashtag.
There is also a `BufferList`, which contains an array of
`TimelineBuffer`s and provides functions to add, remove and update
those buffers. This would be the main widget of the application,
possibly wrapped by a frame.
I'm just trying some ideas and I will probably reach a point where is
not feasible to continue but maybe we can learn some lessons and get
ideas for the future.
Let me now what you think about having a list of buffers where we can
dynamically add and remove timelines. Sorry for the lack of a better
structure on this message but I'm on a hurry. I would be more than
happy to discuss and elaborate more on this.
Nicolas Paris
Alejandro Gómez <alejand...@gmail.com> a écrit :
You've done some great work! Moving the old array to a `BufferList`
make sense, as we want something dynamic. It would be awesome to have
dynamic buffers. I liked as well how you moved the container/get_conf,
seems more natural like that. It seems to have lots of good ideas.
About `Timeline` object, sounds good, but you still have API calls who
isn't affect to timeline (like follow/unfollow). I will think about
this one more closely.
I'm not sure how you handle update threads, I use to don't update all
of theme, as some of theme isn't really important, and the twitter's
API isn't the fastest API known! Especially if you update timeline every
minute.
As I always said, I'll be happy to merge codes, but as I'm not an
expert with git, I rather avoid conflict merges (yeah, I like the
auto-magic merge of github!) So I guess small commits will be easier.
Thanks for this!
Nicolas
ibid
so I'm glad to see there's some work on it already.
I would like to be able to set certain buffers to load when tyrs
starts.
Alejandro Gómez
You've done some great work! Moving the old array to a `BufferList`
make sense, as we want something dynamic. It would be awesome to have
dynamic buffers. I liked as well how you moved the container/get_conf,
seems more natural like that. It seems to have lots of good ideas.
About `Timeline` object, sounds good, but you still have API calls who
isn't affect to timeline (like follow/unfollow). I will think about
this one more closely.
I'm not sure how you handle update threads, I use to don't update all
of theme, as some of theme isn't really important, and the twitter's
API isn't the fastest API known! Especially if you update timeline every
minute.
As I always said, I'll be happy to merge codes, but as I'm not an
expert with git, I rather avoid conflict merges (yeah, I like the
auto-magic merge of github!) So I guess small commits will be easier.
Nicolas Paris
Alejandro Gómez <alejand...@gmail.com> a écrit :
> >
> > You've done some great work! Moving the old array to a `BufferList`
> > make sense, as we want something dynamic. It would be awesome to
> > have dynamic buffers. I liked as well how you moved the
> > container/get_conf, seems more natural like that. It seems to have
> > lots of good ideas.
>
>
> Thank you! I'm just trying the concept of a list of buffers that can
> be added and removed on the fly, and I will also like to be able to
> move them. About the container, maybe it's not neccesary, we can
> export the variablesconf, api, buffersand so on from tyrs and import
> them with:
That would be so cool to moves buffers between them on the fly. I'm up
for it.
>
> from tyrs import conf, api, buffers
>
> I think that it looks more compact and elegant.
Sounds good.
>
>
> About `Timeline` object, sounds good, but you still have API calls who
> > isn't affect to timeline (like follow/unfollow). I will think about
> > this one more closely.
>
>
> About that, when we recognize the types of timelines that we can have
> we can modify the timeline class to receive the API's instance. And
> subclass the `Timeline` class for each kind of timeline:
> `SearchTimeline`, `MentionsTimeline`, `ThreadTimeline` and so on; so
> they know what API call they have to perform to update themselves and
> can also use any other function of the API.
>
> Is just an idea, I will try to experiment with that to see if it
> works in practise or not.
I think it could works fine indeed.
>
> I'm not sure how you handle update threads, I use to don't update all
> > of theme, as some of theme isn't really important, and the twitter's
> > API isn't the fastest API known! Especially if you update timeline
> > every minute.
>
>
> Still very provisional.
>
> I think that could be better to update a timeline when the user
> navigates to it, and maybe update its adjacent timelines also, since
> it is more likely that it's going to navigate to those timelines
> next. Or update timelines on demand.
Unfortunately, Tyrs does not retrieve statuses asynchronously. If you
ask specifically to update, it will block the UI, and wont be able to
go between buffers smoothly. But I'm sure we could work something out
to make it possible. Those with counter still need to be update
continuously, as it notify (I like to be notify when a new mention is
retrieve). But it's only details to think about, no big deals.
>
> As I always said, I'll be happy to merge codes, but as I'm not an
> > expert with git, I rather avoid conflict merges (yeah, I like the
> > auto-magic merge of github!) So I guess small commits will be
> > easier.
>
>
> If you want to push some code to this branch you can open a new
> branch and get my code merged on that branch. I'm doing it as sort of
> an experiment to test some ideas and learn from them in order to
> implement them seriously in the future.
Good idea, I'll try to do that tonight (French time).
>
> I will continue pushing what I do to that branch so we can see if this
> ideas work at all. Let me know your suggestions and critiques please.
>
> On Wed, Jan 25, 2012 at 4:33 AM, ibid <martin....@gmail.com>
> wrote:
>
> > Dynamic buffers would be an excellent enhancement. It sounds
> > complex, so I'm glad to see there's some work on it already.
> >
> > I would like to be able to set certain buffers to load when tyrs
> > starts.
> >
Thanks again for your time, and everything!
Nicolas