i avoid registry like the plague - i tend to keep all settings in ini files in the app directory for easy moving.
note that chs has current "virtual folders" which you can set up specifically to display virtual views of the data - the "Favorites" folder is just a virtual folder that says "show all data items not in recycle bin and with the favorites field set to true"
the "quick paste" virtual folder shows all items added in the last week.
so the idea of virtual folders is exactly as you say and easy to create virtual folders that save the results of past searches. when i add more complex searching i will add a button to say "create a virtual folder from this search", which should make it even easier.
im not sure exactly your file and user nodes but i think we might be on same line of thinking.
right now, chs uses 1 database.
in that database are 2 tables, one for the items (clips) and one for the tree. each item belongs to one node in the tree. the tree nodes are arranged in a hierarchy. all items in the table have the same fields (this is super important for later discussions).
one of the benefits of saying that each item(clip) in the database has same fields is that its easy to drag and drop and move items between nodes in the tree (groups), and it makes sense to do 2 things i really love:
1) have a recycle bin
2) have recursive display of items(clips), so if you click on "all" you see all records, etc.
so right now, chs works with one database, which it expects to be a in a specific format with a specific set of fields.
--
now
what would be interesting would be
if we added the ability for chs to manage multiple databases.
each database could be like a root node.
within each root node would be like a mini tree seen in current CHS view.
thse different databases would be automatically "discovered" by looking at subfolders in some directory.
so that merely copying in another database subdirectory would make that database available as a root node in the tree.
each database node could have its own set of columns, its own recycle bin, etc.
they would basically be independent databases with no interaction, but just be very easy to switch between, depending on what you wanted to work on at any given time.
there's something quite appealing about this, but my main concern is writing something like this, a very general tool, without too much attention on what it would actually be used for.
basically what we are describing sounds like what Brilliant Database does.
but brilliant has some really cool form designers, web export, and all sorts of nice extras.
and if you wanted to use it to organize home collections, let's say dvd movies.. i don't think we are going to do better than something like this:
http://www.collectorz.com/ which has organizers customized for a particular task, which are inevitably going to be funner to use and more tailored to the task.
it would be a fun project if someone was commissioning me to do a specific custom application that they knew they needed and that didn't exist elsewhere - but i've learned the hard way (and still keep making the mistake anyway), that trying to build a general purpose tool without really thinking through the specific applications, is a good recipe for trouble.. i mean look at the dvd database screen at collectorz:
http://www.collector...s/mainthumbnails.gif surely a tool like that is better for organizing your dvd movies..
however,
we also have the situation where we have this tool, which is a pretty serious database tool, which could be used for lots of stuff,
currently only usable for notes and clipboard storage, and it seems a waste not to go some extra steps to make it a more flexible tool..
i'm especially attracted to the idea of being able to customize the columns completely, and the idea that the tool might take advantage of special tools, IFF they exist in the database. If you want to keep track of creationdate, lastviewdate, parent hierarchy, favorites, then it could help you add such fields, if not don't add them.
it definitely seems like it would be a cool tool; and there is nothing major i can see that would make it not doable, i just wonder if it would actually be useful to anyone but a couple people..
importing and exporting to excel, printing, etc. are all easy
the other thing that adding the ability to work with other database would do is let you make a more flexible program that didn't try to combine all items into the same databases.. ie clipboard clips could be in a separate database node than personal notes. todo lists could be in yet another. this would let you have custom fields for each database. and i like the idea that each "database" is essentially just a subdirectory on your disk that can be copied and shared, etc.
i'd have to rewrite most of the group-tree management code to handle such a situation, and of course there would be all the column customization code and code dealing with rendering and smartly displaying columns, and im sure some serious headaches when switching between databases and trying to remember views.. right now you can save a "preset" view of the column configuration through the menu.. well that wont make any sense once there are different databases with different columns, and preset column customization views would have to be stored within each database rather than in a file (i think this is actually what you suggested you would prefer anyway
).
sounds fun - the real problem is just that its not a small job (frankly its been a HUGE amount of work so far, much more than i anticipated) and i still don't know if there is even an audience for this tool - let alone the super generic one.
