Wishlist: Possibility to import/export hub favorites

[MWW]

Well... I am not sure whether I should post such an idea here, but I didn't really know where else.

It occured to me that it would be brilliant if you could import/export hub favorites and maybe even user favorites. So that you can easily back-up your favorites.
Due to all my downloading I have to format my computer quite frequently (probably like once a year), I reckon I'm not the only one who has to do that. Evenso, every time I format my computer I have to search for my favorite hubs all over again, while it would be so easy just to have a file backuped with all that information, that could be imported.

I hope you like my idea. Would save a lot of time for (frequent) users and wouldn't be to hard to implement I think (eventhough I'm not a hardcore programmer).

If there is another very easy solution to my problem, like copying a specific file (or part) in the directory structure then please let me know.

Kind regards,

[eMTee (realprogger)]

There is a complete FAQ covering what file(s) you can/need to backup in these cases. Its in the built-in help file of DC++ (or you can browse it in the web based copy of the help at http://dcplusplus.sourceforge.net/webhelp/faq_settings_files.html)

The backup/restore settings function is a good idea though, that'd help inexperienced users to move all settings to another Windows installation...

[MWW (sllcs)]

Great to see that you like my idea. Would be cool to see it in future dc versions.
Thanks a lot for your quick and accurate feedback, and if I come up with more ideas, I'll be sure to post them.

Kind regards,

[Toast (swetoast-deactivatedaccount)]

proposed this to poy awhile back ago but nice to see a wishlist of it also forgot to add it to the tracker

[Fredrik Ullner (ullner)]

This patch adds the ability to reload configuration files from a plugin. I am unsure the management of the actual reloading, as it seems kind of convoluted (also, with the lack of progress screen).

[Crise / MW (markuwil)]

The above patch breaks compatibility as is, so the version number for that struct would have to change at least, however, the nifty thing about C structs is that they are open ended so if the function pointer is added at the tail end of the struct then binary compatibility doesn't have to be broken for older plugins.

Also worth to note that considering reloading settings can take significant amount of time the load calls should be queued and ran outside the API call itseld and then plugins should be notified when the reload has actually happened. This would need a token to be assigned to each request so individual plugins can track which response corresponds their own reload request or have a callback bound when making a request.

Out of the two approaches the one with separate event for when reload happens is more flexible because then a plugin (that did not necessarily make the request itself) can react to it if it needs to load some arbitrary configuration files or otherwise react to this operation.