Gwibber lists jump to top of page when updated

bumping this up in importance as it seems to happen on all tabs recently

whenever gwibber updates / refreshes, the tab scrolls up some amount

This also applies to the messages tab as well. It makes reading more than one page worth of messages quite frustrating.

I'm going to fix it on this weekend.

Think we need some default javascript here to scroll to stored message index in some cases.

It looks like implementing this feature will cause possibility to easy implement message reading on mouse over like it is now in google reader.

I've tuned some uncommented code here: lp:/~s-matveenko/gwibber/bug but it still does not work well.

Now scrolling returns to its previous position even after changing view: from messages to replies for example.

Also, this scrolling restoration method is not pedantic and have no corrections to scroll position when new messages arrives.

I think the best way to resolve this issue is to differ initial page loading and updating of current view and to perform updates via ajax requests. This method should do the trick very smoothly.

the correct link lp:/~s-matveenko/gwibber/bugs

Hoping for a fix sometime soon. Somewhat annoying when reading through 350 new tweets and it suddenly jumps all the way to the top again.

It wasn't like this before, though.

I hadn't spotted this bug report and potential fix.

As others have noted, the scrolling is annoying.

A fix here just adds connect/disconnect buttons to the status bar -- so you can turn off updates while you read -- not ideal, but couldn't figure out how to get the scrolling right.

http://bazaar.launchpad.net/~swfiua/ubuntu/lucid/gwibber/scrollfix/revision/20?start_revid=20#gwibber/client.py

Any news on this? 2.0.0~bzr491-0ubuntu2~daily1~karmic still suffers from this. Anything I can do to help?

I think is a good idea show a flash message when have new twitts instead jump to top. A ugly mockup is attached.

It would be useful for artists to brainstorm possible ways of showing that there are new messages, without using text to do it as used in that mockup. One possibility would be for the display to momentarily nudge downwards (as if being bumped by the newly arrived messages), before sliding back to its previous position. I'm sure there are many other possibilities.

My suggestion is simply to show a small padded area (in background colour) at the very top of the message view when the topmost message is the newest.

(See screenshot-up-to-date.png)

When new messages have arrived, the bottom of the newer message is now visible in the previously padded area as a visual hint (combined with the new position of the scrollbar) that messages are available.

(See screenshot-new-messages-avail.png)

side by side screenshots of up-to-date vs new-messages-available

I hope this can get fixed in time for Ubuntu 10.04, cause this is really annoying.

Happens on all lists for me too,
Tristan

On the screen shot provided in
https://bugs.launchpad.net/gwibber/+bug/327172/comments/13 I don't see a notification but if i am right it looks like it just doesn't jump to newest.
Personally i think:
https://bugs.launchpad.net/gwibber/+bug/327172/comments/9 is the best way to go. From a users POV

The banner display is what I've been used to in the past. Twitterrific updates and displays a banner for a couple seconds and then it disappears on the iPod/iPhone. I think that would be plenty of attention and not overly done since the scroll bar will also be shifted down on updates, making it more obvious that there are newer messages above.

opened downstream task for tracking purpose

happy to see "like" enabled.. !!!!!!

yeah, gwibber needs some serious artwork casting..
comment #9 contains an extremely good idea

perhaps a casting or contest or something on gnome-look.org ?

http://live.gnome.org/GnomeArt/ArtRequests

here's the right place for developers to request artwork.. let's try should we?
i think only developers can edit this list..

Is the consensus that a banner notification be added? Or, along the lines mentioned earlier in this bug thread, that the message view will have a current scrolled index stored and used during a post-refresh render[2]?

I suggest whichever method is selected (or both, gods preserve us) should have a option added in preferences to allow the screen render to the latest as it does today for those who like the current behavior.

[1] Basically like Twitter's web interface.
[2] I've seen this behavior in Seesmic on Android and rather like it.

an elegant form of notification is definitely an improvement to the current state.
the optimum is:
i flip a switch and its visual representation actually shows as flipped

what happens instead:
i flip a switch and the whole room turns dark so i can't see the switch i flipped

there is no problem with sending the current behaviour into the menus or preferences as an option.
the way gwibber is currently behaving though is not in line with the principles of usability described in the current hig-book.

the user is being surprised, his input is overinterpreted in a confusing manner, instead of implemented on the spot.

related issues are:
*there is no visual representation of whether or not i like a broadcast
*there is no visible button or [+] or tree symbol that would instantly expand a comment thread beneath a broadcast message
*comments are not threaded to the message at hand and displayed in context when posted
*the text input field does not visually change to indicate that i'm commenting, when i'm commenting and not writing a new broadcast message
*the status messages entered above the availability settings for IM automatically get sent to all active Microblogging accounts instead of IM accounts

where do i discuss a whole set of usability issues?
the gwibber ML is team only.. :S

I'm working on this now. I have a very experimental solution in my pre-3.0 branch, but it still needs a lot of work.

Wow. This is really annoying. If you need any help fixing it, let me know.

Yup, this affects me as well. Wish I could code to help out. Let me know if you need help testing - I can do that at least.

@mniess: If you can fix the bug , do submit a merge with the fix. [Gwibber is hosted on launchpad, you can just follow the merge procedure (1)]
No need to ask first. Anyone can fix a bug. Rather, fixing bugs is welcomed. ;-)

(1) https://help.launchpad.net/Code/Review#Proposing%20a%20merge

Please fix! :)

I would really love to see this bug fixed. This is the most annoying thing about Gwibber and, though it doesn't make it unusable, it isn't too far from there. Any way I can help? I'm a programmer, but not much Python experience.

There seems to be 2 distinct "scroll to top events", one at the beginning of the update, and another one when it is complete. I'd like to see no banner/notification of any kind. Just add the new messages to the top of the list, and the user will see them when they scroll up there themselves.

I think that's what most Twitter clients do: Remember the last position and let the user decide when to scroll up.

When I understand the code right, the actual list of messages is build from a HTML template that renders all available messages from all streams and then just display it in a Webkit view (happening in gwibber/gwui.py. My python is limited, so I'm not 100% sure about it.

I'm getting this on 2.30.0.1 on Lucid with Home and Replies.

This is planned to be fixed in Gwibber 3.0, it isn't all that simple to backport to 2.30.x.

This bug was fixed in the package gwibber - 2.31.3-0ubuntu1

---------------
gwibber (2.31.3-0ubuntu1) maverick; urgency=low

  * New upstream release
    - Move backend storage from desktopcouch to sqlite
    - Don't scroll to the top on every refresh (LP: #327172)
  * debian/control
    - Added a Depends for python-pysqlite2
    - Dropped python-desktopcouch-records to a Recommends (still needed
      for account migration, but not strickly required)
    - Made python-libproxy and python-indicate Recommends instead
      of depends
    - Bumped standards version to 3.9.1
  * -debian/patches/lp_539017.patch
    - Merged upstream
  * debian/patches/no_tray_icon_pref_ui.patch
    - Hide the tray_icon preferences
 -- Ken VanDine <email address hidden> Wed, 28 Jul 2010 10:19:29 -0400

Thanks Ken!

Fixed in Maverick!

is there already a .deb available?

and oh yeah:
thaaaaank you :D

On Sun, Aug 1, 2010 at 21:16, Frederik Nnaji <email address hidden>wrote:

> is there already a .deb available?
>

Glad to see this fixed in Maverick, but will the LTS release (Lucid) get it?

kenvin, for lucid use this ppa. https://launchpad.net/~gwibber-team/+archive/ppa the fix wont be coming to 2.30 series.