Archive for April, 2009

Archive for April, 2009

My Ultimate Aggregator

Posted on

I want a feedreader that is also a mublog client and an activity stream aggregator. That is, like Bloglines+Socialthing+Tweetdeck, as a desktop app.

Content could be categorized (automatically, by source, or by metadata from the source) as “short” (like twitter/, “medium” (like tumblog-style stuff, or content from backtype), and “long” (blog posts etc), as well as by any actual categories/tags on the content (including hashtags on tweets, etc), and by source.

The left pane could let you filter by only certain categories (select one or more sources/categories/lengths, union each kind and then intersect, ala (source1 union source2) intersect (category1 union category2) intersect (length) ). Each kind of category would be separated by a line or something, with lengths at the top (there’s just three), then sources, then categories. Unread counts next to all of them.

Right pane in river-of-news (or, more like tweetdeck) style. Style should be smartly selected based on item. Tweets/mublog posts should link the username, @replies and #, etc, and show the avatar. Feeds with mediaRSS show thumbnail lieu of avatar. Feeds with a feed image show that. Otherwise, show favicon. Keep all items the same size, with snippets, etc, and click/otherwise select to expand.

Action links associated with each kind of data. Comment links for feeds with a <comments> tag on items, “show comments” for ones with wfw:commentRSS, long-term it’s be great to post a comment from the feedreader. “favourite”/”reply”, etc for the mublog, “bookmark too” for, etc.

Allow the user to associate multiple authors together (also try to do automatically) and maybe assign an avatar if there isn’t one: so that all of one person’s content displays and archives in a consistent fashion.

*Keep archives*! Make it easy to search through, or browse through, read content by category/author/source. Allow the user to file content under custom categories.

Have awesome keyboard shortcuts. j/k/space/enter/n/d… check out gmail/greader/mutt/trn for inspiration.

Be modular. Don’t just hardcode all the services/formats you want to support: take a hint from libpurple and others and just make *everything a plugin*. That way I can have NNTP support and you don’t have to care.

Support feed:// … I know it never took off, but supporting it isn’t hard and may yet prove useful.

Provide sane import/export of all data.

Provide posting support. In the plugins that implement it, of course. This means being able to update my mublog, bookmark to, etc 🙂

*Be portable*! It’s really not that hard to do 80% of your work in a cross-platform manner, so just do it already! Use a cross-platform GUI framework for your initial GUI and add native UI plugins for some platforms (looking at you, Apple fanboi’s) later.

Would I pay for this? Yes. I mean, it would have to be libre software (I’m not going to pay you to restrict my freedom!), but I would pay quite a bit for something like this. I dunno, if I were to pick a number, $40? Something like that. If I don’t figure it out and write it myself. GUI programming is not exactly my strong suit, but I’m playing around with it.

GUI Toolkits

Posted on

They all suck.  I’m not kidding.  I’ve tried Qt, GTK+, Tk, even Shoes.  Shoes is the best of the lot so far, but none of them seem to get right the one thing I’ve come to take for granted on the web: layout.

Take the following HTML snippet, for example:

<input type="checkbox" />
<div style="display:inline-block;margin-left:40px;margin-right:40px;">

You may crtisize the form of this snippet, but it’s pretty clear what it does: one row with a checkbox, a label next to it, a two-line element with a name and description, and finally the text “HAI”.

In Shoes (the one that makes this easiest) this is almost:

stack {
flow {
stack {
para 'name'
para 'description'
para 'Free'

Though apparently I need to know the width I want for the name/description pair up front (in pixels or percents) or it will try to take up the full window and thus wrap to a seperate line.

The thing is, though, it’s not really the toolkits’ fault. Layout isn’t a thing they’re supposed to be good at, and they’re certainly not used to use fluid-layout types who care what happens when the window gets resized (with all fairness to toolbars, which handle that ok). Most simple apps are designed to have their main window one size and not changed, which makes absolute positioning of everything possible. Toolkits have enough to deal with drawing widgets and interacting with the desktop environment and OS to get events.

The thing is, widgets are a solved problem. Really. If I want to throw some widgets on a window and hook up event handlers, I have umpteen choices available to me. Yet another new toolkit is not the answer, since it too would likely get bogged down with the same details, and if it didn’t have good bindings to a lot of languages might end up like shoes, which is bound to its own custom VM.

I think, then, I have something that may begin to resemble a solution. Why not use a syntax that is much better at expressing the nature of a layout? Why not, in fact, use XForms (with some lightweight subset of CSS)? Then we just need scripts to convert the layout descriptions into the widget and positioning code for each different toolkit. Then the developer can wire up events using their favourite toolkit, regenerating the widget part of the code when changes are made to the UI.