A to do widget would be nice, touch the screen and it will check it off and timestamp it..
Either that or import the Outlook To-Do list... or both *as separate widgets*

All.

I am happy to look into using the Remember the milk API to make a widget. I am wanting to get people's feedback as to what functionality they would like / expect in an initial widget offering.

You can see the available commands in the API here : http://www.rememberthemilk.com/services/api/methods/

From my first look into the API, I am thinking of adding functionality to :

- view a users lists - (I am trying to see if you can get a list task size easily so that you could do a tag cloud type visualization based on number of tasks / priorities / tags)
- click on a list to view tasks
- be able to set a task as completed / uncompleted
- be able to view notes associated with a task
- be able to change the due time of a task (maybe ?)
- be able to change the priority of a task (maybe ? )

Anyhow, let me know.

Cheers,
Aran

Thank you!

In my usage of Remember the Milk, the features I use most are:

* Due Date
* Notes
* Priority

I occasionally use:
* Location
* Tags

I rarely use:
* Time Estimate
* URL

However, for an initial version, I would be perfectly happy to be able to simply view my current ToDo items and check them off. Anything more than that is just extra icing on the cake -- nice and appreciated, but not necessary.

Thanks again for taking this on!

Ok.

I just got my API key approved about 10 min ago, which means I can start to get things rolling now.

The Authentication routine for the API is really not geared to flash at all (normally you have to supply a callback URL (html page) to your users if they authenticate properly etc) -  I will post some messages on the developers mailing list / remember the milk engineers to see if we can get over the initial stumbling block of authentication methods for the all flash envirnoment of the Chumby. Once that is happening, the rest should be easy enough...

Aran

For some reason, the forum wouldn't let me submit more test in a post so here is the rest:

NOTE - You will only have to do this authentication thing once, but this process is integral to how the RTM API system works, and I cannot make it any easier.

NOTE - You can choose to revoke a 3rd party application at any time, in which case the token which was generated in the above steps will no longer work to authenticate.

I am hoping to have some early tests of the whole authentication process done by early next week (time permitting). I would like to get some people to test it to make sure it is all working as intended for everyone. The widget itself might be really basic on the 1st build just to make sure the authentication token is working as it should. If all goes well, I will continue to develop the widget to a decent feature base.

If you have any questions/feedback, please ask.

Cheers,
Aran

Ok, I put you down as a chum...

Hi misterhee,

the authorization worked well for me, I was just a bit confused I had already your token when opening the widget's config first time. But as soon as I reset the token everything went well.

Now I can see some debug output with list IDs on my virtual chumby

I went through the process.  The widget comes with a token already activated (see here for what the activation widgets shows on the first screen:  http://www.flickr.com/photos/8293992@N08/2369871176/ ) so I had to reset it. 

When I reset the token, I got a new URL.  I pasted the URL into my browser, logged in, but didn't see the expected activation page.  I tried pasting the URL a second time, and it worked (presumably, because I was logged in this time).  I then activated and the widget and the RTM page told me that it had worked.

Now the widget is showing the debug info and the names and IDs of my RTM lists.

Thanks for the clarification Duane.

So the transferring of config settings (without special naming conventions) is expected by design and not by accident? I re-examined the wiki, and I can see the line about the _var entry (but had not seen it before obviously). Can you maybe update your config widget example with both a public and private variable (with comments) so that any new developers will read about the functionality.

I am just wondering whether sharing settings when sending to a chum is actually desired. I think personally, due to the standard workflow of always configuring widgets from default once I add it to a channel, that it is a bit counter-intuitive to have it work one way in normal circumstances but another when sending.

Maybe a tickbox in the send dialog UI - "send config setting" (yes/no) would help users to understand that it is 1) capable in the first place 2) give them control.

Just my 2c anyhow...

Yes, the copying of the original widget's parameters is by design. That way one can send a widget configured to point to specific external content instead of something completely generic, ie "Check out this YouTube video", "Check out my vacation pictures on Flickr", etc, where the content token really isn't a big secret.  The "_private" naming convention allows the author control over the circumstances under which this is not appropriate.

It's one of the few places where we don't default to the behavior that maximizes security - in retrospect, we probably should have made parameters non-copyable by default and used a "_public" prefix instead.  Unfortunately, that horse has long left the barn.

@cahorton

Yes. Sorry for the lack of of updates. I have just gotten back from holidays (without a laptop) so I have not forgotten about the RTM widget.

done:

- all authentication routines
- all XML calls to / from server to get at raw data for lists / todo's / notes
- create scrollable UI controls to view lists/tasks scaleably

todo:

- combine data from list calls and todo calls to give the user data they actually want to see on screen.

unfortunately when you make a call to get tasks on the RTM API, it doesn't give you a list name that the task is a part of. There for in order for the widget to a) show you what lists you have and b) show you the number of tasks in a list, or the details of a specific task, you have to make multiple server calls and combine the results to get what is actually required to show to the user.

I am about 80% complete on this task as I have created XML parsing / combining for lists and notes and I am finishing off the tasks side of things. When I am done with this, it should also give the option of viewing due or near due tasks as the inital screen instead of the lists view

- make the UI usable for end users

it is in a ugly debugging state at the moment, so some beautifying is required.

I will endeavor to have a widget to test (by chums) before the end of the week. Sorry if I am over explaining / complicating what I am up to, but that's what you get when you ask a developer what they are up to