Post by Tim Penrose on Nov 28, 2005 13:03:35 GMT -5
Sorry for the sporadic nature of the information in this post. I am just putting down information as it comes to me. I will try to be less scattered when it comes time to write the help!!!
It was a busy 4-day holiday weekend for me (Thanksgiving; A US holiday). I only got about 15 or 20 hours of programming in.
The application has the core in place. I have the UI, with navigation tree in place. Database interaction is working excellent. After editing node content, the nodes can be saved individually. In addition to Undo and Redo, right clicking on a node provides a “Revert to Saved” option to return the node, including ALL properties, back to the previously-saved state. Nodes can be added and deleted, but not YET moved or copied. I have not written find functionality yet.
I plan to "eat my own dog food" as the saying goes. I plan to retain and extend KeyNode functionality, but I also plan to introduce a few new "directions". One of those directions is as an Authoring/Development environment. What I mean is this; There will be multiple "runtimes" that provide various subsets of the complete functionality. One of those "runtimes" is a help system. Users will be able to create stand-alone help files from their tree hierarchy. All runtimes will be royalty-free. Some runtimes, such as the aforementioned one, can be created with the free version, and will also allow royalty-free redistribution. Other runtimes (no elaboration will be provided at this time) will require the commercial version for creation and redistribution.
Another direction I plan is to beef up the PIM functionality. I don’t want to talk about it yet because I plant to turn it into something that has no rival in the current marketplace.
Currently, the only two node types I have implemented are Plain Text and RTF. RTF editing is 99% complete. I am still having problems with the table insert code (I need to interact directly with the RTF and Microsoft’s spec appears to be incomplete. I am following it and yet there are odd things occurring. I have the first section of the O’Reilly RTF book which I will read at lunch today). I still need to add code to the RTF editor so the user can right click on a table and add rows/columns. Otherwise, RTF editing is [nearly] complete (I’m sure there will be various other small additions/revisions).
The RTF editor supports the following Image Formats:
Bitmap (BMP)
Graphics Interchange Format (GIF)
Joint Photographic Experts Group (JPEG)
Exchangeable Image File (EXIF)
Portable Network Graphics (PNG)
Tag Image File Format (TIFF)
These same image formats can be used to specify the icon for the node. The Node icon, color, and font are all inherited from the node type, but can be overridden by the node.
I would like to have the first “beta” out on December 16th or shortly thereafter. I use the term “beta” loosely because it is extremely unlikely that the application will be feature complete by that date. The application should be fairly robust, though, since I like to get things proper before moving on to other tasks.
Current plans are for the initial beta to only support Firebird embedded database. I implemented compression code over the weekend. The application uses the following guidelines to load and save local repositories (files):
[myfilename].databaseformat.nlr
[myfilename] = Any name the user chooses for his/her application
databaseformat = The database format of the particular file.
Currently, only the following four are defined:
*.fbec.nlr
*.fbe.nlr
*.shsqlc.nlr
*.shsql.nlr
nlr=The file extension for association with the application.
Users can configure compression on or off. If compression is on, then all files associated with the current tree will be compressed into a single file when the user closes the file or exits the application; for example: *.fbec.nlr or *.shsqlc.nlr files (depending on the database format the user selects). When the user re-opens the file, it is decompressed so that it can be used by the native database engine. Files can be opened, regardless if they are compressed or not. This way, if something happens before the user is able to properly close the file, then only the user’s unsaved information will be lost. FYI; The relatively sparse Firebird databases I have created so far compress from around 800k to about 52k. The compression/decompression happen so quickly that it is not perceptible for files this small. I do this NOT because compression is that important, but to simplify the end-user's experience. Some databases require multiple files to function. I don't want to require that users understand the underlying databases. I just want them to see a *.*.nlr file and know that they can open it with the application.
I am currently adding the code to switch node types. Before this, I had it hard coded to RTF type. The next immediate task (within the next two or three days) is to change the way node icons are handled. Currently, the main file (database) holds a link to the image file. I am not happy with this because I want to embed the icons into the database so that the file is completely self contained. This way if the *.*.nlr file is copied to another machine, it will function identically as compared to functionality on the original machine. After that, I will re-attempt table insertion/manipulation.
I could write 10 more pages, as I have a list of 50 items left to complete. But things are moving along well.
Thanks for reading,
Tim
It was a busy 4-day holiday weekend for me (Thanksgiving; A US holiday). I only got about 15 or 20 hours of programming in.
The application has the core in place. I have the UI, with navigation tree in place. Database interaction is working excellent. After editing node content, the nodes can be saved individually. In addition to Undo and Redo, right clicking on a node provides a “Revert to Saved” option to return the node, including ALL properties, back to the previously-saved state. Nodes can be added and deleted, but not YET moved or copied. I have not written find functionality yet.
I plan to "eat my own dog food" as the saying goes. I plan to retain and extend KeyNode functionality, but I also plan to introduce a few new "directions". One of those directions is as an Authoring/Development environment. What I mean is this; There will be multiple "runtimes" that provide various subsets of the complete functionality. One of those "runtimes" is a help system. Users will be able to create stand-alone help files from their tree hierarchy. All runtimes will be royalty-free. Some runtimes, such as the aforementioned one, can be created with the free version, and will also allow royalty-free redistribution. Other runtimes (no elaboration will be provided at this time) will require the commercial version for creation and redistribution.
Another direction I plan is to beef up the PIM functionality. I don’t want to talk about it yet because I plant to turn it into something that has no rival in the current marketplace.
Currently, the only two node types I have implemented are Plain Text and RTF. RTF editing is 99% complete. I am still having problems with the table insert code (I need to interact directly with the RTF and Microsoft’s spec appears to be incomplete. I am following it and yet there are odd things occurring. I have the first section of the O’Reilly RTF book which I will read at lunch today). I still need to add code to the RTF editor so the user can right click on a table and add rows/columns. Otherwise, RTF editing is [nearly] complete (I’m sure there will be various other small additions/revisions).
The RTF editor supports the following Image Formats:
Bitmap (BMP)
Graphics Interchange Format (GIF)
Joint Photographic Experts Group (JPEG)
Exchangeable Image File (EXIF)
Portable Network Graphics (PNG)
Tag Image File Format (TIFF)
These same image formats can be used to specify the icon for the node. The Node icon, color, and font are all inherited from the node type, but can be overridden by the node.
I would like to have the first “beta” out on December 16th or shortly thereafter. I use the term “beta” loosely because it is extremely unlikely that the application will be feature complete by that date. The application should be fairly robust, though, since I like to get things proper before moving on to other tasks.
Current plans are for the initial beta to only support Firebird embedded database. I implemented compression code over the weekend. The application uses the following guidelines to load and save local repositories (files):
[myfilename].databaseformat.nlr
[myfilename] = Any name the user chooses for his/her application
databaseformat = The database format of the particular file.
Currently, only the following four are defined:
*.fbec.nlr
*.fbe.nlr
*.shsqlc.nlr
*.shsql.nlr
nlr=The file extension for association with the application.
Users can configure compression on or off. If compression is on, then all files associated with the current tree will be compressed into a single file when the user closes the file or exits the application; for example: *.fbec.nlr or *.shsqlc.nlr files (depending on the database format the user selects). When the user re-opens the file, it is decompressed so that it can be used by the native database engine. Files can be opened, regardless if they are compressed or not. This way, if something happens before the user is able to properly close the file, then only the user’s unsaved information will be lost. FYI; The relatively sparse Firebird databases I have created so far compress from around 800k to about 52k. The compression/decompression happen so quickly that it is not perceptible for files this small. I do this NOT because compression is that important, but to simplify the end-user's experience. Some databases require multiple files to function. I don't want to require that users understand the underlying databases. I just want them to see a *.*.nlr file and know that they can open it with the application.
I am currently adding the code to switch node types. Before this, I had it hard coded to RTF type. The next immediate task (within the next two or three days) is to change the way node icons are handled. Currently, the main file (database) holds a link to the image file. I am not happy with this because I want to embed the icons into the database so that the file is completely self contained. This way if the *.*.nlr file is copied to another machine, it will function identically as compared to functionality on the original machine. After that, I will re-attempt table insertion/manipulation.
I could write 10 more pages, as I have a list of 50 items left to complete. But things are moving along well.
Thanks for reading,
Tim
