Virtual node knt file with sub-tree

[GoogleCodeExporter]

By now it is only possible to have virtual node of rtf, html or txt file.
It would be good to have virtual knt file node, so that the tree below
could also appear. That would solve the timing issues of editing bigger
files by separating them. Of course if in the future database solution
will come, that will solve it as well, but I think files anyway have
advantages, and linking tree of one with each other is great idea.
Just like junctions/symbolic links in filesystems.

Original issue reported on code.google.com by szmas...@googlemail.com on 14 Feb 2009 at 2:32

[GoogleCodeExporter]

I think that the implementation of that kind of virtual node would be expensive.
KeyNote has ways to alternate rapidly between several keyNote files.
Another option more easy could be to let open different keyNote files 
simultaneously, perhaps trying to optimize loading of nodes contents only for 
files
being accesed (similar to lazy load). But with that aproximation, each file 
should be
a serie of notes (tabs), like now.
Each of these files could be opened in read mode, if for example, as required by
issue #51, the file was locked. We could define a 'macro' knt file, that simply
pointed to several files, perhaps changing the order of the tab set.

Actually I am working in a new kind of virtual node, to another keyNote node, 
but in
the same file. It will be the base to other features, as soon I will describe.

Original comment by dpra...@gmail.com on 15 Feb 2009 at 6:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Summary: (of my posts) - sorry I introduced mess

Main issue:
1. linking knt file in a tree of another one does not have to be expensive.
   Idea is to give choice to user wheather to parse it on the beginning or, on expand.
   + surplus is faster write, which now when editing e.g. 50M file with images is slow
   + security because of distribution of files => also different passwords

2. Your idea to edit in a tab another knt file simutanouesly is also great.

3. Possiblity to link a node with a any file in filesystem would be also very 
useful.
   In that way one could not only open it from keynote-tree e.g. by double click, but also
   write comment in main kenote window. (I think that is easy to implement)

3a.As further extension very nice would be possibility to add to a particular 
node in keynote-tree, 
   sub-nodes with names of filesystem files also linked to them.
   I mean additional option when I click right mouse button on node "add file(s)".
   Dialog to mark files could appear, with shift one could mark files and then
   they would appear in sub-tree of keynote. On double click they would be opened in
   associated e.g. notepad.
   In that way it would be easy to create a documentation of project files.
   e.g. as we have keynote project it would be possible to write changes to 
   every particular source file in keynote, having a link to the file in keynote tree.
   Later on another nice dialog could be used to edit/change these links.

Secondary issues:
4. Idea for multi-user editing - see notepad++, if file is modified then ask 
user reload/preserve?
5. Lock could be implemented as option in e.g. file menu stored as parameter in 
ini file.

Original comment by szmas...@googlemail.com on 21 Feb 2009 at 2:48

[GoogleCodeExporter]

I have got one more suggestion as possible alternative to db4o database for 
keynote.
In fact database could be just an option of alternative to files storage.
I mentioned previously that portability is an issue.
In fact db4o seems only suitable for .NET and Java...
I found SQLite much more flexible in that sense, and also simple.
Look at http://sqlite4delphi.sourceforge.net/
or just http://en.wikipedia.org/wiki/SQLite
On contrary to db4o it uses sql92 standard, version 3 supports also blobs.
http://www.sqlite.org/datatype3.html
Anyway, I think knt files are anyway useful and should be always an option for 
the user.

Original comment by szmas...@googlemail.com on 28 Feb 2009 at 7:40