First release of Maemopad+

Maemopad+ (the package name is MaemopadPlus due to problems with the "+" character) is a tree-structured notes editor, based on maemopad. It will be able to take typed-notes -AND- sketches. After the 2006 OS release it might also store voice-notes. Notes are saved in a single xml datafile. Currently it also saves UI stuff and last-datafile-opened info. Early experimentation phases.

Version 0.1 - Test release
http://www.ehore.com/apps/maemopad+/...us_0.1_arm.deb
this is a test release and should be treated as such.

BUGS
- it won't save sketches yet
- sketches are sketchy
- using GtkCTree, will convert to GtkTreeView asap
- initial GtkCTree (well, the treewidget) width should be smaller (so the horizontal scrollbars should not be displayed)
- i18n is incomplete

TODO
- keep last modified date for every node
- save text properties (font face/size, color, style) for every node
- add brush size and ink color picker
- save the sketches!
- maybe add a "set default text properties" kind of thing, for newly created nodes
- Create a "sample node" (or a series of nodes, like an app demo?)
- Add about box
- Test against low memory conditions and rewrite portions accordingly

I will release the sourcecode mid-march, after my N770 arrives and I test/develop the code some more.

Good news that, a simple note-taking utility is a basic need that's sorely lacking on the 770 right now. Thanks for your effort ! But why XML ? How does one reuse notes taken on the 770 on another platform ?

Several options:

* Write an XSLT which can convert the notes to any other format (HTML, CSV, ...)
* Write a "MaemopadML" editor for any other platform in any language you like.

Why wouldn't it be XML? Structured file formats is exactly what XML should be used for...

Well, a lot of something-pad programs are plain text editors, which are good enough for a lot of quick note-taking tasks, and we don't have one on the 770, so I'd be happy to have that first. Once I've written down my meeting notes or whatever, I shouldn't have to write anything else (XLST or yet another editor :-) to reuse my text anywhere else !
Also, a text editor can also serve to edit a lne or two of Python code on the go, but an XML editor can't.

Don't think of it as Notepad, think of it as Jotter

We've got text editors galore: Notes, Maemopad, vim, nano, ... - what's needed is a proper note pad/taking application. Horizon is that if you can write on the device, hopefully Maemopad+ will be for more text-oriented input.

I've had a PDA of some sort or another for years. Never have come across the perfect note taking app. I usually wrote the note to a Post-it and stuck it to the outside of my Palm 5

thank you all for the comments.

the purpose of the xml file (or it could've been any other datafile) format is mainly the tree-structured view. i could've made it so you pointed a "data directory" and the nodes were simply files in that directory. i didn't because i liked the single-datafile idea better, it's tidy and easier to back up. to view the notes outside, an XSLT formatter would do the trick. you won't be able to view sketches with that tho, (i will save the sketches in png (or maybe pixmap) and uuencode/base64encode it into the xml stream) so will probably have to add functions to import/export sketches (and don't forget voice notes) in the future. or you could use clipboard functions, they will work.

Have you considered using sqlite for storage? It might be better for memory consumption because you only need to load the tree and the current note into memory.

Or have you considered only having the structure in the xml and actual data in files? i.e replace data with file name. With bigger data this looks like better way. uuencoding pictures looks like unneeded bloat. It might work fine for few notes but storing more data inside the nodes may become problem in future (memory,speed). sqlite is a good choice too, it is used in GPE PIM applications. I think they used xml too but later found it simply does not scale with more data.

in fact i considered sqlite but didn't act on it. looks like it's a better way, yeah.

as for using xml as a data-index file, well, i don't see the need for it. the data directory idea and storing the files and the structure on the filesystem is better.

but, would using the data directory method (the one i described in my last post) confuse the users? it's way more compatible than a sqlite db, but i'm worried about the ease of use for the average user. what do you think?