Support for overriding automatic path configuration

Bug #538478 reported by Razzloss on 2010-03-13
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Steven Sheehy

Bug Description

There's at least one case where the automatic path setting done by Util::initialize isn't desirable. That is when user want's to run multiple instances of (Linux)DC++ or temporarily wants a different config for testing etc.

The patch adds optional map parameter for Util::initialize from which the non-empty paths are used instead of autodetected ones. Also provides protection against dcpp::startup for resetting explicitly given values (which apparently isn't really needed with 7.60 core since startup isn't doing it anymore).

Patch only affects non-_WIN32 and common blocks.


Related branches

Razzloss (razzloss) wrote :
Steven Sheehy (steven-sheehy) wrote :

Besides wanting to allow multiple config dirs, another reason for overriding default paths is that some of the paths in the core for *nix are non-standard nowadays (e.g. $HOME/.dc++) as seen in bug #329805 and bug #316358. But to change them would require calling a linux library that differs between distros, which is not feasible from within the core.

In addition to the overrides map Razzloss suggests, two alternative approaches that I can also suggest:

1) Add setPath(Paths type, string path) to Util so the UI can manually override the defaults of the core when needed.
2) Store all paths inside SettingsManager instead of inside Util. This would allow the UI to override them and even allow the user to override some of them, if that is desired. It also would remove the awkwardness of storing some paths both in Util and in SettingsManager like the download directories.

With either of these approaches, some mechanism would be needed to "refresh" the core to make use of the updated paths (i.e. reload config xmls, etc).

Changed in linuxdcpp:
importance: Undecided → Medium
status: New → Confirmed
tags: added: core
Steven Sheehy (steven-sheehy) wrote :

Would appreciate a response dcpp team ... we have to have this for i18n support.

Steven Sheehy (steven-sheehy) wrote :

I'll assume by the silence that you loved the patch so I went ahead and committed a modified version of it.

Changed in dcplusplus:
assignee: nobody → Steven Sheehy (steven-sheehy)
importance: Undecided → Low
status: New → Fix Committed
poy (poy) wrote :

Fixed in DC++ 0.780.

Changed in dcplusplus:
status: Fix Committed → Fix Released
Tehnick (tehnick) wrote :

> Fixed in DC++ 0.780.

Not fixed yet. You code is not working as we need.

Util::initialize() called from dcpp::startup() without parameters overwrites all previously overriden paths

initDone variable from original patch is not present in your commit. So all this code is unusable...

Steven Sheehy (steven-sheehy) wrote :

Util::initialize() is not called in dcpp::startup() in latest dcplusplus bzr code. You are probably not using the latest dcpp core. You need to call it yourself from your main class. You can see how to utilize it here:

Tehnick (tehnick) wrote :

Ok. Now I see. Thanks.

Steven Sheehy (steven-sheehy) wrote :

Offtopic, but have you considered submitting patches to upstream linuxdcpp for your changes to eiskaltdcpp's gtk UI (which is a clone of freedcpp which is a clone of linuxdcpp)?

Tehnick (tehnick) wrote :

I really do not know what patches you might be interested. And unfortunately I have not got a lot of free time to prepare patches for LinuxDC++. You can read changelog in English to find something useful. It is quite detailed and transparent.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers