gwibber-team team mailing list archive

[Steve Smith <tarkasteve@xxxxxxxxx>]

At Dominic's suggestion I've pushed this branch into launchpad:

 	 bzr branch lp:~tarkasteve/gwibber/message-component

Cheers,
Steve

On Tue, Jan 27, 2009 at 8:52 PM, Steve Smith <tarkasteve@xxxxxxxxx> wrote:
> Hi,
>
> There's a first-cut of this available here, comments welcome:
>
>    http://haltcondition.net/~ssmith/gwibber/
>
> Some implementation notes:
>
> * I'm currently using GObject signals for sending status updates back
> to the client.  This is probably OK for a few signals but it may be
> more pythonic to use a proper observer pattern base-class for
> communication between components (keyword support, etc).
>
> * Currently the text-view area wants to default to multiple lines and
> won't shrink.  I can't work out how to override this, suggestions
> welcome.
>
> * There are still some other parts that probably belong in the message component
>
> Cheers,
> Steve
>
> On Fri, Jan 23, 2009 at 2:04 PM, Steve Smith <tarkasteve@xxxxxxxxx> wrote:
>> On Fri, Jan 23, 2009 at 1:32 PM, Ryan Paul <segphault@xxxxxxxxxxxxxxx> wrote:
>>> Hi Steve,
>>>
>>> I think it's a good idea, but it's beyond the scope of what I'm
>>> comfortable with doing for the 1.0 release. So, I think that it's
>>> something that would probably be good to do in a separate branch and
>>> then we can merge it post-1.0.
>>
>> Seems reasonable, any thoughts on a timeline for 1.0?
>>
>>> I think that using GtkSpell on a TextView
>>> would probably be a reasonable improvement.
>>
>> That's what I was looking at.  In particular I was going to base it on
>> the input area for Gajim, this also implements custom keybindings
>> which opens up some possibilities for power-users.
>>
>>> Another feature that I'd like to see implemented further down the road
>>> is support for auto-completing nicknames. That's something that could
>>> also be done in the custom widget at some point in the future. Anybody
>>> else have any thoughts on input changes that they would like to see?
>>> Other things that come to mind are perhaps using background color-coding
>>> to indicate which protocols are active.
>>
>> URL shortening could be more interactive.  At the very least there
>> should be some feedback that a URL is being processed, but it would be
>> nice if raw URLS were shown but highlighted; a right click (or an
>> inline button) would give the option to shorten.
>>
>> Cheers,
>> Steve
>>
>