View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000107 | MMW v4 | DB/FileMonitor | public | 2003-02-18 04:57 | 2007-06-08 16:58 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | feature | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Summary | 0000107: Support for configurable library location | ||||
| Description | The user should be able to configure the database's name. When MM is run for the first time, a default name can be chosen for the db, however, the user should have the ability to create or load a new database from scratch (File|New Library), or open one database or another (File|Open Library), provided the user has such rights. This is fairly important for making MediaMonkey portable (which also implies that relative paths should be supported for this). Note: There is no longer a major need for multiple libraries to be open at once (each having its own Library hierarchy) since the new Filtering functionality serves much of the same purpose. Additional Information http://www.songs-db.com/forum/viewtopic.php?t=660 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Similar to http://www.jirihajek.net/mantisnew/bug_view_page.php?bug_id=0000673 And http://www.jirihajek.net/mantisnew/bug_view_page.php?bug_id=0000826 if not same I think it can be done as a single feature. |
|
|
Not sure I understand your logic, but it's low priority so we can defer discussion. |
|
|
Raised to 'High' since this may become an OEM issue. |
|
|
Since it doesn't seem that this would be a feature implemented anytime soon, I guess that we can set it as Resolved. |
|
|
Re-opening for discussion. I would like to see MM3 be usable in portable mode. Are you saying that portable mode should be deferred? or just that configurability of the DB location (though in truth I think that we _need_ configurability of the library location _unless_ MM's installer sets up a db/profile sub-directory for portable usage--but that would require significant changes to the installer). |
|
|
Since questions like 'Where do you want to install DB file' seems to me to be unnecessary in the standard MM installer, I wonder whether another portable installer of MM wouldn't be better. It would have all these things related to ini file/DB file properly configured and could even have other differences - e.g. be smaller, don't include >1 skin, etc. |
|
|
I've been using portable apps quite a bit recently, given my travelling and need to use different machines. Many apps _do_ have different installers for portable versions of the app, so this is definitely a possible approach. The main issues then are: -would upgrades work? -having multiple versions of the app can complicate distribution (e.g. on DL.com we'd have MediaMonkey and MediaMonkey Portable) Let me know what you think... |
|
|
1. It depends on how would we like upgrades to work, the easiest would probably be to make them separate applications. 2. Two versions would possibly also mean more visibility, we could e.g. make MM compatible with PortableApps.com and try to get to their suite (but it's possibly for open source apps only). |
|
|
The best approach I've seen is where the app has an option (e.g. in Tools > Options) to: '[ ] Portable mode (store DB/config in application directory)' That way the user can install MM normally, and, if they wish, change the config on the fly. I suppose, though, that the larger question is what is the best usecase for portable use. I would expect that we would want to support both of the following scenarios: a) user operates exclusively from the USB key. This case is easy to support. b) user operates from the main machine but synchs periodically (both the db and the music) with the usb key. This case would probably best be supported via some sort of Virtual Device (i.e. where MM on the main machine synchs music to the portable device and synchs the MM db on the main machine with the MM db on the device). I don't know if this is possible or not using our existing Synchronization technology, but the way I'd envision this is that in the Synchronization Options, the user could choose 'MediaMonkey USB Key' as an option. When the user synchs with a USB Key, MM would: i) synch the content ii) synch the db iii) MediaMonkey directory and config to a specified location on the USB key Do you have another idea about how scenario b) could be supported? Re. inclusion of MM in Portable Apps, that's unlikely (since it's not open source), but I do think we can do a lot of marketing regardless of how we package it. |
|
|
isn't this proposed almost the same as I described in bug 0002439 except Setup Flag that will open Dialog to user to select destination for MM portable (much better and user friendlier aprach)? I agree on marketing part as beside portable version it gives proof that MM is not AD/Spy/Bloat/... Application but clean and simple that leave no Artifacts. From MM design I think that 90% of feature is already in MM, but Jiri is more competent to confirm that. Edit: Think that this will also resolve at least most part if not completely bug 0001420 |
|
|
You're right. This discussion probably belongs in 0002439. It began as a discussion of the need for configurability of location and evolved into a discussion of the need for a 'portable mode'. Note: the reason for making this configurable via the client is that then users can change an installation to portable (I don't know how we'd manage this if it was just installed via a portable installer). Setting to 'high' since 0000107 covers the issue of Portable use, and this (configurability of the location) is really an implementation issue as far as 0000107 goes. |
