It's definitely non-trivial.  :-\

Hi, Urlwolf, welcome to the thread. Your comment about text notes bing all you need is the perfect illustration of how hard this problem is. What works for you would never work for me. I use OneNote and find its layout and drawing capabilities restrictive because it doesn't have full set of drawing tools the way Word does.

I think the idea of rolling a file-management system into the app is the bank safe that breaks the camel's back. Sure it's doable - but I think realistically the cost is too high. Better to stay focused on the core principles. My personal version of these would be:

• Speed - The app must be highly usable for both mouse-centtric and keyboard-centric users. Extra keystrokes and mouse clicks must be all but eliminated. Common functions must be riduculously easy to access.
• Flexibility - The app must be highly configurable, to the point where it can actually have different UIs for different users. This is the only way you are going to come up with something that will satisfy everyone form the "text only" users to the "lots of pictures and layout" users. Ideally, the app should make it possible to visualize information in ways that are not possible with existing tools or even UI metaphors. The idea of templates or canned designs must be part of this, though, so you don't have to assmble the app prior to using it. The UI should allow tweaking and refinement over time.
• Interoperability - Nobody uses ONLY a note taking program, and the program shouldn't act as though it's alone in the world. Other apps should be able to access its metadata. It should play well with the OS. It should not require a proprietary API to get working with other tools.
• Portability / shareability / synchronizability - If I use the app at home and at work, there should be some smart way to move my info around without creating headaches. If I want everyone in my office to run the app, users should be able to share data without a lot of headaches.

I think the last item, while desirable, is a pretty tough nut. We might want to wait a LONG while before adding it in (Version 4?) but the architecture of the app should be in place to support it from the beginning.

BTW - I'm all in favor of using old-fashoned concepts wherever possible. F'rinstance, I'd like to see a substantial set of command line parameters for the app, almost to the point of it being like its own API. This would solve a lot of problems. If you could pass the app a unique ID on the CL and have that note come up, you could easily make desktop shortcuts to individual notes, gaining a lot of file system functionality for very little cost. If the app could return detailed information based on CL queries (or via a scripting library) it would be that much easier to make it interoperable with existing tools.

I'd seen this site referenced on a GEOS-related e-mail ist I belong to.

Neat that some of these older GUIs are now being open-sourced (GEM.) I still remember being excited when BeOS was announced.  :-[

Hi Rover -

I think I'm with Mr. Franks on this one. You've defined database requirements - but we're not talking about building a database engine. We're talking about building note taking software. Program functionality comes first, starting with interaction design. Technical stuff follows on as appropriate. Why would you start working on plumbing before the blueprints are even drawn? (Note: "Because I'm a plumber!" is NOT really a good answer!  ;) )