Microblog port to Akonadi pushed into a branch

Mon Oct 29 00:28:24 UTC 2012

On Mon, Oct 29, 2012 at 12:56 AM, Sebastian Kügler <sebas at kde.org> wrote:

> Hi Martin,
>
> On Saturday, October 27, 2012 19:23:46 Martin Klapetek wrote:
> > I've just pushed my port of Microblog declarative plasmoid in a branch -
> > mklapetek/akonadi_port (kde:declarative-plasmoids). Setting this up needs
> > kdepim-libs from master, kde:libkfacebook (currently in kdereview),
> > kdepim-runtime from master with this[1] patch, SocialFeed qml plugin from
> > kde:scratch/mklapetek/socialfeed and this Microblog branch. If you want
> to
> > try microblog too, you can get the new microblog resource from
> > kde:scratch/mklapetek/akonadi-microblog-ng - I'm not aiming to have the
> > microblog-ng resource in 4.10 though, but it might be finished by then
> and
> > just released separately.
> >
> > It's not yet finished, but it's fairly usable already. Here is what
> works:
> >  * listing stuff
> >     * facebook goes 3 days back (limit 400 posts) with number of likes
> and
> > comments
> >     * microblog for now goes 20 posts only
> >  * displaying facebook comments by clicking on the status (probably needs
> > better discoverability)
> >  * posting to networks
>
> Very nice. I've tried to build it and am looking at it (well, the microblog
> parts at least, I don't have a fb account). The build of the microblog
> resource fails, complaining about
> akonadi-microblog-ng/libkmicroblog/microblogjob.h:27:30: fatal error:
> libkoauth/koauth.h: No such file or directory
> I don't have that lib. Where can I find it?
>

Ah well, I forgot that one. It's at kde:scratch/mklapetek/koauth. It's
splitted from the microblog dataengine and cleaned up a bit. I also haven't
touched the microblog-ng for a while (or tested), might be broken. I'll put
it in order first thing in the morning.

>
> SocialFeed wouldn't compile, missing the onShowPost(...) declaration, I've
> added it and pushed it to master as you asked. :)
>

Thanks :)

>
> > Issues:
> >  * the scrollbar is baaad, unusable even (because of the non-uniform
> > delegate height), not sure what to do about it
>
> I've seen that as well, once the model refreshes with all the differently
> sized widgets, the scrollbar position vs contentHeight seems to get screwed
> up. We'll need to create an as simple as possible test case (maybe using a
> timer to add different text items to a ListView?) and debug the scrollbar
> code, or maybe even deeper. :/
>

I'm happy to help!

>
> >  * when using mouse wheel to scroll, sometimes it just stops scrolling
> and
> > you have to either scroll the wheel /really/ fast or drag the list, I'm
> > unsure why that happens, I suspect it's the item snapping to the list
> edge,
> > but I don't understand qml that deeply to see how it works exactly
>
> Have you tried changing the snap to item property of the ListView?
>

I have now :) Both the snapping options have similar behavior, only NoSnap
works perfectly fine with mouse wheel. But the snapping is quite nice to
have... :/

>
> >  * sometimes the plasmoid can get really really slow or even freeze when
> > scrolling very fast as it tries to fetch all the avatars and post images,
> > this might need some optimizations
>
> We should be able to limit that through KIO somehow, in fact KIO should not
> slow down the system in that way. Are you using the preview dataengine for
> this? Using this with the microblog plasmoid, I've not seen any problems
> with
> that in scrolling performance. (It downloads, caches the images, but still
> has
> to copy them at least twice (KImageCache -> DataEngine -> QML Runtime).
>

I want to put it through a profiler to see exactly where the hold up is,
but since it happens only the first time when the images are being fetched,
I'd assume that would be the bottleneck. I'm not using the dataengine, but
I am using the same code (slightly modified, but uses the same KImageCache
as the dataengine), which I've put into kdepim-libs [1] so that the
resources can fetch the images while downloading the other content while
there's internet connection, makes the experience better when browsing it
offline.

[1] -
http://lxr.kde.org/source//kde/kdepimlibs/akonadi/socialutils/imageprovider.cpp

>
> >  * actions on posts do not currently work (liking, replying and sharing),
> > I'll try to have them working for 4.10, in the worst case, we can have
> just
> > "read-only" version shipped (if we're going to ship it by default) and
> just
> > hide those buttons
>
> What's the actual problem?
>

The way it should work is changing the Akonadi item and calling a
modification job (nobrainer), which takes it to your resource and that
handles it. But in the resource I have actually no way of knowing what was
changed. This needs support for "parts" in the resource de-/serializer, so
then the resource can say "this item has this part changed". Should be
fairly easy, I tried quickly hacking a prototype code and failed, then I
didn't have time to finish it.

>
> >  * refreshing the list pushes garbage/no data into qml, I'm not yet sure
> > where this problem originates, simple reloading of the applet fixes it
>
> Maybe again a setRoleNames() in the DeclarativeModel screwing up? Where's
> that
> happening, does it still happen if you don't use
> PlasmaCore.SortFilterProxyModel?
>

I actually use proxy model on the c++ side. And I haven't investigated this
properly (but it's near the top on my todo), so I don't know where exactly
this happens. It does show proper amount of items, just their data are
"undefined" in qml.

>
> >  * clicking the status fetches all the comments, but the list is not
> > updated (even though the model emits dataChanged)
> >  * there's no user info yet, but the facebook contacts are in Akonadi, so
> > should be easy to just fetch the info and display it
> >  * there's still some code that's unneeded, will be removed
> >  * post times do not get updated, I'm not sure how to refresh the post
> > times in the whole model
>
> Why would you want that? Posts are one-off items, they don't change posting
> date all the time. If you want to display things like "3 minutes ago",

Yeah, that's exactly why :)

> and you
> do it like this it will "refresh' during scrolling (since the delegate is
> destroyed when going off-view and when becoming visible it's recreated.
>

The problem arises when you don't scroll the view. Then you can easily have
a "few seconds ago" when it really was few hours ago (think of having the
plasmoid on desktop, covered with windows and seeing it after few hours).

>
> Label {
>                 text: fancyDateFormatter(postDate)
> }
>
> From a UI point of view, a possible solution without too many timers is to
> display "Posted just a moment ago" for "really new" posts and using a
> single
> shot timer to change that into the posting time (4:41pm which is not
> relative
> to $now, and therefore you don't have to change). For single delegates that
> only refresh once that is I think an acceptable trade-off between usability
> and wake-ups. For most posts (all that are older than "just a moment ago",
> we
> don't need to start the timer at all).
>

Hmm...I might change to the full time instead of relative, at least for the
first release, it's a low-priority one.

>
> > I'll be more than glad if anyone can help with any of the issues :) Feel
> > free to hack directly on the branch to make it more awesome. Or just
> > awesome.
> >
> > [1] - https://git.reviewboard.kde.org/r/107021/
>
> Mighty cool stuff, by the way. :)
>

Thanks :)

-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121029/d0b5456b/attachment-0001.html>