Hi,

currently, K-Meleon always uses the settings of the prefs.js file located in the user's application data directory defined by Windows itself. This makes it impossible to start K-Meleon with alternative settings. Therefore it would be very useful to be able to start K-Meleon with a command line argument stating the settingsDir to be used, such as

kmeleon -settingsDir C:\path_to_my_own_directory

This should force K-Meleon to read C:\path_to_my_own_directory\prefs.js instead of the preferences file mentioned above.

What do you mean - how can this be realized?

thanks,

rob.

Rob,

Can you give an example of why you wouldn't use the K-Meleon prefs. js file?

Andrew

Rob,

This can also be accomplished by changing the SettingsDir preference either in the interface or using the user.js file as documented here:

http://kmeleon.sourceforge.net/docs/custompref.php

Andrew

Andrew,

sure I would use K-Meleon's prefs.js file, but not limited to use the same for all cases. One of the greatest things of K-Meleon is that someone could use a customized set of MENUS.CFG, ACCEL.CFG, Menuicons.cfg + TOOL1.BMP + TOOL2.BMP + TOOL3.BMP and THROBBER.AVI. The settingsDir preference set in user_pref("kmeleon.general.settingsDir", "PATH"); which can only be set via the interface points to the location of these files, but the location of prefs.js cannot be influenced since K-meleon *always* looks for it in a directory defined by Windows.

If you want to be able to start K-Meleon with two separate such configuration sets within the same operating system, that would fail since the location of prefs.js which defines the location of the "configuration set" cannot be separated.

The fact that K-Meleon always looks for pregs.js inside the directory defined by Windows is OK, but it would be a big enhancement if you allow K-Meleon also to look at other locations, eg. first in the directory where kmeleon.exe resides or in a directory given by a command line parameter as I originally have suggested.

Looking truly for a solution - thanks,
rob.

This is what the profiles are for, each profile has it's own set of prefs, bitmaps, and config files.

Brian,

I think Rob's problem is that even if he creates a separate profile, K-Meleon doesn't recognize it unless it is located in the standard location for Profiles.

For example:

Rob creates a profile called "Jimbo" and moves that profile to C:\Jimbo. He edits all of the references in Jimbo's prefs.js to point to the new location. He then tries to start K-Meleon with the the -P Jimbo command-line option. However, K-Meleon can't find the profile "Jimbo" because it's not located in \Application Data\KMeleon\Profiles\. So, it just goes ahead and loads the default Profile.

I think what Rob wants is the ability to tell K-Meleon on start-up where to find "Jimbo" if it is not located in the standard location. I'm assuming that this is something that is currently "hard-coded" into the app.

Rob - correct me if I got any of that wrong.

Andrew

Andrew,

this is exactly what I mean. K-Meleon is so great in customizing on run time level - the only customizing thing that is still on compile time level is the \Application Data\KMeleon\Profiles\ location (which also depends on the Windows version).

If this one setting could be moved to the run time, K-Meleon gets fully customizable without the need of recompiling. This would allow to run two different kmeleon.exe files (that might be two different versions) with two completely different settings within the same operating systems.

rob.

Rob,

The command line profiles location is a good idea, and a very necessary feature for anyone wanting to run kmeleon in a networked environment where the profiles would be stored on a server while the executable is installed on a client. I'll be sure to add it to the next version of k-meleon.

You still won't be able to run multiple instances of k-meleon (at the same time), as it is, kmeleon looks for existing instances, and if it finds one, simply spawns a new window off of that.
-- Jeff

Thanks a lot, Jeff, for picking up this suggestion!

:-)

rob.

Rob,

Thanks for making the suggestion! That helps this browser gets better and better each release!

Andrew