English > Feature Suggestions

Loading database when program is launched

<< < (2/3) > >>

patch:

--- Quote from: rick.ca on January 28, 2010, 10:29:27 pm ---Anyone who is confused about which database is loaded when appears right in the titlebar is unlikely to be any less confused having to open one on their own.

--- End quote ---
The title bar shows file name without path making it ambiguous.

Anyhow, that is not the point. The issue is pvd could appeal to a wider audience if it was less confusing. And Rick you are a power user with experience which is unlikely to be replicated by most other users, which raises the possibility things you find second nature may not be obvious to others. We could find out by being open, you could remain unaware of the possibility if you are not.

On another note. The main problem with pvd not always opening the last database is how to handle connection via a server. It works well now as you connect once then pvd remembers. Needing to reconnect each time manually would be a big step backwards. A short cut to the database is not going to work as although pvd may be able to invoke a sever for remote databases, the need ia ambiguous for local databases

rick.ca:

--- Quote ---The title bar shows file name without path making it ambiguous.
--- End quote ---

You've got to be kidding!


--- Quote ---Anyhow, that is not the point.
--- End quote ---

But what is your point? That I know the program too well and I spend too much time here helping other users to have a clue what might improve its usability?  ::)

buah:
All of us posting here were deeply comitted to PVD, and all of us strongly want to contribute to improve it. That's the thing I never lose sight of.

AimHere:

--- Quote from: rick.ca on January 28, 2010, 10:29:27 pm ---
--- Quote ---Sorry, I guess I'm not making myself clear. I just thought it would be good for PVD to behave like most other Windows apps in that regard
--- End quote ---

You were perfectly clear. I don't think the behaviour of "most other Windows apps" is appropriate for a database application like this. My personal information and media managers don't behave that way. I doubt any of their competitors do either. The vast majority of users use only one database for such things. Most of the rest would still want one loaded at startup—either the MRU, or they would create multiple shortcuts so they could choose which one to load.

--- End quote ---

Which is why I want it as an option, which is turned off by default. That way, power users can turn it on if so desired. Some of us just prefer to work in an application-centric way (e.g. launch an app, then open a document) instead of a document-centric way (launch a document shortcut, the associated app opens). It's all a matter of user preference.

For me, the real issue is database size. I've only got part of my video collection cataloged so far, and already my database is around 500 megabytes. (Mind you, I embed all images in the database, rather than referencing them from disk, because I really don't want to have to keep a bazillion JPEGs stored alongside the main PVD database.) Once I add the rest, the database could easily swell to three times that size. So I split the database into separate files for functional categories (e.g. movies, TV shows, etc.), and again, I prefer to work in an application-centric way (see above) and don't want the MRU database opened when I launch the app.  I'm sure that if I kept everything in one monolithic database, I wouldn't mind the auto-open-MRU behavior.

Aimhere

rick.ca:
As I've explained here, I don't believe there's any reason to be concerned about the size of a database due to the images stored in it. I think you've created a huge inconvenience for yourself by splitting your database—at least the separation of movies and series. The program is carefully designed to handle these two video types together in one database. It's obviously much easier to maintain one database than two.

A good reason for spitting a database is to separate a particular type of video that is so different from the rest (e.g., home movies) they require different custom fields, skins, plugins, etc. But this doesn't require just a separate database. It would require a separate configuration file, and a completely separate program installation if plugins and their configurations need to be different. So this would have to be handled using separate shortcuts to start different configurations/databases.

Another might be you're using a very old/slow computer. Until recently, I was, and it was obvious it was struggling, in part, because I had a large number of "wish list" items in my database. I considered splitting them into a separate database, but didn't. I decided the pain of having to maintain two databases and switching back and forth was not worth the modest performance improvement I'd realize by doing so.

Navigation

[0] Message Index

[#] Next page

[*] Previous page