FeedReader for OpenMoko
Michael 'Mickey' Lauer
mickey at openmoko.org
Wed Mar 21 23:45:20 CET 2007
Hey Zecke,
> department of confusion confirms zecke has been seen hacking Gtk for
> the last three hours. The result is a comparsion between Qts
> Interview Framework and Gtk's one and a RSS reader. If you consider
> that Gtk's stuff was created back in 2002 (and even earlier) it is
> actually quite good.
Glad to hear that.
> Well http://page.mi.fu-berlin.de/~freyther/FeedReader.png a
> screenshot, and the source http://page.mi.fu-berlin.de/~freyther/
> openmoko-rssreader-0.0.1.tar.bz2 and it would be appreciated if svn
> would be made to work soonish.
Yeah! That's quite an achievement for a quick hack.
> I decided to use libmrss as this is a small but powerful and rather
> complete reader and composer library. And the autofoo usage is quite
> clean and obvious. This allows me to only concentrate on the
> userinterface.
Wise choice!
> - How should the config dialog look like? How to add categories for
> the filter bar? Screenshots would be welcome. E.g. a quick add that
> shows a GtkEntry and a ComboBox to select the group and a complete
> management dialog that allows you to move and delete existing feeds?
Thanks, we have forwarded this to the graphics-designer. They will
complete the specs asap.
> - HTTP authentication. I have never seen a private livejournal page
> how would a password dialog look like? What keyring do we have at
> OpenMoko? Where to cache passwords :)
I'm afraid I don't have an answer yet...
> - Integration into messages. The messages application could poll the
> feeds according to the SkipHours and then open the feed reader to
> download the feed.
Sounds interesting.
> - Offline viewing of feed data. Should we cache the data?
Yes.
> how much data should be cached?
I'd like to have an API in libmokocore that allows you to query the
amount of cache you are allowed to use per-app and allows you to query
the path for caching data. That way libmokocore can control this
depending on global preferences, heuristics, and information about the
attached storage devices.
> If a user presses refresh should we keep the
> old data in case of connection errors.
Yes.
> - Should we cache images from the feeds?
Yes, but please honor the overall caching limit (see above)
> - The "refresh all button", Is it bound to the active categroy? e.g.
> refresh all feeeds in the current category/filter or is it global?
Sounds like you should use the popupmenu facility of the
MokoToolButton here.
> - What should we do with the extra toolbox buttons. Currently they
> say "Rent me" and "Buy more Mate". I would not mind to display Ad
> Click advertising on these buttons but if you have a better use
> shout. E.g. one could control the font size of the TextView?
Pretty good idea. Since we only have 4 slots for action buttons, I
feel it's a waste if we don't map them to actions.
> - Commercial feeds (sorry both are german) like spiegel.de and
> heise.de only publish their headlines and force you to visit the real
> webpage. Should one try to display the HTML within the feedbrowser or
> switch to the webbrowser?
Try to display HTML -- even if it just knows about a couple of tags. A
full-fledged webbrowser won't be there very soon.
> - Is the SMS dbus interface specified yet? Would one send the URL or
> text of the article both?
Please bear with us for some more weeks, that's under construction.
> - How to report progress and errors? Should the Footer be used to
> display messages?
Yes. That's pending the StatusBar API in MokoApplication which will be
implemented early April (if no one beats me to it) and/or the
openmoko-footer GSoC project.
> - much more I forgot because I ran out of caffeine... and missed my
> last bus...
D'oh.
> My personal agenda for this is:
> - Use GAIM HTML tokenizer and display HTML inside the GtkTextView
> - Use ModelFilter and ModelSort for searching, sorting and
> filtering the feed
> - Fight with the Column Header sizing
> - Implement caching of feed data (e.g. in sqlite)
> - Do the loading of feeds inside a GThread
> - Instead of hardcoding the feed data use GConf
> (- Release the Qtopia version as well)
Great plan! Welcome on Board. It's pleasure to work with you together
in a project again.
Cheers,
--
- Michael Lauer <mickey at openmoko.org> http://openmoko.org/
============================================================================
Software for the worlds' first truly open Free Software mobile phone
More information about the openmoko-devel
mailing list