DonationCoder.com Software > Clipboard Help+Spell

Programming Question...

<< < (4/7) > >>

kfitting:
The more I think about this, the more excited I get.  I can think of bunch of things I could use a program like this for.  From applications at work (personal database for parts, lists of all types) to uses at home (organizing collections).... wow.  Once again, a database would work, but databases require so much programming and setup time.  Besides there are lots of people that use Excel for storing data.  This would be (for data only!) a glorified Excel. 

Concerning trees: it would be kind of neat (though another level of complexity) to be able to have file specific nodes and user nodes.  File nodes would travel with the file.  In my scenario, amongst the team we could have certain nodes for certain parts of the trainer.  But, my user nodes would stay on my harddrive.  When I open the file, the program looks at the file nodes, then the user nodes and builds the tree from them.  This way I could make my own searches and have access to them without cloggin other people's views. 

Couple quick things:
- import/export to excel is key!  We must deliver our wirelist in a common format, plus people shouldn't have to reenter all their data.
- Minimal impact on the user's machine.  Registry keys should be avoided as much as possible, no-install version, etc.  Perhaps user ini files would work.

Man, I'm getting all excited about this.  Going to be hard to wait, but some things are worth waiting for.  Your the programmer!

Kevin

mouser:
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.collectorz.com/images/movie/screenshots/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.

kfitting:
Hmmmmmm.... So nodes would not contain views (filters) into a database, they would contain databases?  In some ways this is awesome.  Like you said, one program to view all kinds of databases.  I like the idea of that.  But, could nodes have different types?  Right now I can see the desire for three types:

- database node (contains entire database like you suggested)
-filter/view node (could be below a database, or could be high level allowing to filter through multiple databases at once?)
-user defined (ie, drag the records you want into the node)

wow. That's cool.  And highly useful. 

Concerning user vs file nodes.  Basically, the tree structure the program shows the user is based off of two things: the node structure contained in the file and the node structure the user has on his desktop.  This way I could have certain nodes (read filters) for specific work I'm doing, but not affect others who are using the same database.  But, we could also have common filters that everyone would be able to use.  As more databases are managed, this gets slightly more confusing... but still a worthwhile idea to consider.

Concerning the collecter software you mentioned.  I looked at the screenshot... I personally don't like it.  I realize I may be in the minority (see below) but I would prefer a straight table view.  The other problem is that you have apps for DVDs, apps for CDs, apps for books, apps for blah.  One specific database for one specific thing.  I love excel for this type of data storage... but imagine Excel with filtered nodes and the quick filtering system a la CHS.  Yes I realized the virtual nodes in CHS, exactly how opera handles email and I love it!  I think every program should come with them (well, maybe not every program...).

Concerning Brilliant database, one of the reason I'm not intrigued by it is that it has all the forms stuff.  Forms are cool, but then you have to set them up.  This program would be ready to use almost out of the box.  Import your excel spreadsheet, create some new nodes with rules and you're there.

cracksloth had some good posts over on the Keynote forums about data storage and how certain types of data are best stored certain ways.  He argued that a note program doesnt benefit from a database behind it, but there is data that does.  In other words, I think "mini database" fits CHS better than notes program. 

All of that rambling aside, I understand your concern for creating an app that only one person will use.  I wish others would join in here and give some kind of feedback.  But, if you make it generic enough, people will find uses for it that you never imagined (look at Keynote).  If people want a clipboard tool, they have it.  If they want a to do list, they have it.  If they have a collection they want to organize, they have it.  And, if you can implement what you're talking about, they can have it in one program shell!  I could go from searching through my parts list database to looking at what tasks I have going on right now, to looking through the clipboard to find that errant piece of data I copied three days ago.  The power here is phenomenal.  Don't understand all the multiple database stuff?  Ok, use one database at a time. 

Sorry, I am extremely biased about this program.  I would love to see it come about.  BUT that is because it fits MY working style.  You need to decide if the extra work and sweat are worth it.  However, if you code it generic I believe you could have your cake and eat it too.  I defer to you and to the opinions of others.... but this would be awesome!

Kevin

mouser:
yeah, i should say it's definitely the write way to talk about these things, to hear what one person themselves thinks they want - so it's definitely more useful to hear what you want personally than to hear what you think everyone would want, so these discussions are useful.

ok i understand what you are saying about user nodes - i'll have to think about that, since currently there is no real way to do that now - the tree arragement with the virtual folders and everything is all in the database and would be shared betwen users.

regarding the nodes i was thinking of it like this
at top level root nodes would be databases,
then each database has its own subtree of nodes that act exactly like the current chs system.

so the tree would look like:

* database 1
-*ALL
--*NEW
--*OLD
--*Favotires
--*Recyle Bin
* database 2
-*ALL
--*NEW
--*OLD
--*Favotires
--*Recyle Bin

database1 and database 2 would be totally independent database files - you couldnt (easily) drag and drop between databases, or create virtual views that combined them, they would be firewalled from each other really.

but within a database node youve got the subtree underneath which can hold different phsysical and virtual groups, you can drag and drop betwen groups, etc.

i could let the user create their own virtual groups local to their hard drive and not associated with the database, but you would still not be able to create a virtual view that combined multiple databases.  thats the price for having the ability to have different columns in different databases.  the idea is, different databases would not mix.  its basically you can only be working in one database at a time - its just a convenience that you are shown the different databases as root nodes in the tree, to make it easier to navigate between them.

one advantage of rewriting the group tree node code is if i do completely rewrite it to provide that option we discussed before of showing records within the left sidebar tree if desired...

still a lot to think about it, but its fun to brainstorm ideas and see if we cant make an app out of this.

kfitting:
Yeah, that makes sense.  While it would be cool to be able to filter through all databases I can see where that would be almost impossible.  Really, CHS is almost what we're talking about, all you have to do is take out the clipboard monitoring and add a few tiny features.  Not that this means it's trivial to code, however! 

So right now nodes are kept with the database?  I thought you said multiple files would be needed for different views.  Granted, views and nodes may be two different things, I was just using them as synonyms.  If they are in different files, user/file trees arent too big of a deal.  If they are in the database, they kind of lose most of their usefullness.  THe whole point is so some views stay with the file and whoever opens it sees those views, but if I want a certain view for a task I'm doing, I dont necessary clutter other people's view with my garbage.

I think being able to show records in the tree would be a cool thing... more for clipboard stuff than a generic database.  THough, if you can figure out a way to do it you may as well give the ability everywhere. 

Database-wise I think you have 95% of the functionality already in CHS.  The biggest change is in the tree structure.  The database still needs:
- editable cells
- adding/deleting columns
- method for scripting (possibly the hardest, I dont know)

The Tree structure should have (not needs, the program would still be awesome if only one database could be opened at a time!)
- user/file nodes
- Multiple databases in one tree

GUI wise... I dont know.  The current GUI would get you 90% of the way there I think.  Granted, the pane that shows the clip itself isnt needed, or the modify button.... unless you wanted to allow people to store large amounts of text.  How are the actual clipboard contents contained now?  Are they merely a field in the database presented in a textbox instead of a cell?  If so, the GUI from CHS may not need to be changed at all.  All you would need to add are the things stated above (along with all the other stuff you already have on your plate!!) and make a way to turn clipboard capturing/spellcheck etc on and off.  You can already change the view if you dont need to see the clip pane.  You already want to make it so that different nodes correspond to different column arrangements.  If you add the ability to have the program change views on database change, you would be fine.

Ideas, ideas, ideas.  Hopefully it's possible!

Kevin

Navigation

[0] Message Index

[#] Next page

[*] Previous page