Using two or more profiles means not being able to have Pale Moon set as default browser, to be fed URLs remotely?

[yellowfinch]

For a couple of years I have been using two profiles in parallel, one window for each. In order to implement that, I simply added the options --no-remote and --ProfileManager to the launcher, per the official instructions. This arrangement has served my needs very well.

But there are more and more apps that make their documentation available only on the Web, and when I click on Help in their menu, I get (after a few seconds) “Pale Moon is already running, but is not responding. To open a new window, you must first close the existing Pale Moon process, or restart your system.” I imagine that this is precisely the expected effect of the --no-remote option, but I tried without this option and it was totally unworkable. (Which is why it always accompanies --ProfileManager in the instructions, I suppose.)

The closest discussion I could find on this subject is this thread from about a year and a half ago: ¿How can I make PaleMoon always ask for Profile when launching a new instance? It ended without a solution.

Are the two principles (using two profiles and feeding URLs to Pale Moon remotely) really, utterly and hopelessly incompatible?

For now, I’ve set another browser as my system default so that, in such a situation, I can at least find out what the URL is, copy it to the clipboard and then go back to Pale Moon. But I find this rather wonky.

[Moonchild]

You can only set ONE of the profiles to handle being default.
That is the one where you'd omit -no-remote so have it respond to remote signals (= DDE and system calls). Any secondary profile must always be started with -no-remote or it will open a new window in the primary session.

[yellowfinch]

You can only set ONE of the profiles to handle being default.
That is the one where you'd omit -no-remote

Having only one profile handle all DDE calls would be fine, but I don’t know how to achieve that. There is only one launcher per app per user and that’s where the --no-remote option is, so it is already set before the profile manager pops up. How could one profile not be subjected to the option?

[Moonchild]

You cannot centralize it through the profile manager; you can only do this by making sure you launch the profiles directly from the command-line, meaning using the -profile command-line parameter either with or without -no-remote depending on which profile you are launching.

i.e.:
one shortcut which launches "palemoon.exe -profile {path1}" to be the default handler listening to system calls
one shortcut which launches "palemoon.exe -profile {path2} -no-remote" to launch the secondary profile that will not be listening to system calls.

Potentially you could launch the profile manager from the second shortcut for selection upon startup of one of the secondary profiles.

As an alternative setup you could also use one system-installed version and one or more portables to handle multiple profiles -- the system-installed version would be working as the default browser, and the portable would be standalone secondary profiles.

[Lunokhod]

Perhaps look at /usr/share/applications/palemoon.desktop, you could make a modified copy /usr/local/share/applications/2palemoon.desktop and perhaps reboot for it to be found. Modify the exec line with the command you want and add %u as before to append any other args, and change the name and possibly icon fields to distinguish it. Then you would have 2 Pale Moon apps in your desktop menu you could drag to a bar to make a launcher, both starting Pale Moon but with different commands. So one would run on the standard profile and you can point the other to the second with no remote, something like:
Name=2Pale Moon
Exec=palemoon -no-remote -profile "/path/to/2profiledir" %u
Not sure if that is quite what you want to achieve and I haven't tried it (who knows, may need extra quotes in the Exec or something ) but I think there should be no problem, the .desktop files integrate with the desktop to run a command when clicked in a menu or launcher. Virtually all Linux desktops use the same spec.

[therube]

and when I click on Help in their menu, I get (after a few seconds) “Pale Moon is already running, but is not responding. To open a new window, you must first close the existing Pale Moon process, or restart your system.” I imagine that this is precisely the expected effect of the --no-remote option

Correct.

but I tried without this option and it was totally unworkable

Why?
Explain your setup & "shortcuts" (or whatever they may be in Linux).

External links (& speaking from the Windows end) will always open whatever Profile is defined as "Default" (Default=1) in profiles.ini.
If "Default" is your -no-remote'd session, then you'll get the message you've stated.
If "Default" is your non-no-remote session - be it open or closed, when external app says open PM, it will open as wanted.

Create a desktop shortcut that points to "palemoon", to act as your "Default", non-no-remote instance.

Create a desktop shortcut that points to a -no-remote instance. With that instance, you can use (-no-remote combined with) --P to point to a particular Profile defined in Profile Manager, or -profile to point to some arbitrary location where you want a Profile opened at, or you could use --ProfileManager to select a particular Profile (say, if you had more then 1 -no-remote Profile) - but, do not choose your "Default" (non-no-remote'd) Profile (cause if you choose that, you'll end up with your aforementioned message).


It is possible, with what you're doing currently, depending on settings & how you're going about things, that whichever Profile you last "ran" is being set as your Default Profile.
(The StartWithLastProfile= in profiles.ini can have a bearing on that.)
So if you fire up your "non-no-remote", then fire up your -no-remote, then close the non-no-remote, then close your -no-remote session, depending on that switch, your defined Default=1, i.e. "default" Profile could be switching between your non-no-remote & your -no-remote instances - depending on how you close the instances.

[yellowfinch]

[...] make a modified copy /usr/local/share/applications/2palemoon.desktop and [...] modify the exec line with the command you want and add %u as before to append any other args [...], something like:
Exec=palemoon -no-remote -profile "/path/to/2profiledir" %u

Thank you! Yes, this is what I needed. In Windows, I would play with shortcuts all the time, but in the three years since I’ve been on Linux I had never had to deal with launchers yet, except a few times to add an option to the “Command” field in the “Properties” GUI. I didn’t know where that info was written.

Nor did I know that there is a profiles.ini file for Pale Moon even on Linux. I turned off StartWithLastProfile there.

For the record: my DE is MATE, in Linux Mint, and I suppose this is why modifying the palemoon.desktop file in /usr/share/applications/ had no effect. I found an almost identical file in ~/.local/share/applications/ and that’s the one that has priority, so I created an altered copy of that one per your suggestion. It worked instantly; I didn’t even have to restart the session.

I still wish the profile manager would handle variable options per profile. I find it an otherwise excellent tool. But it looks like it comes from Mozilla, so...

[bgstack15]

The XDG menu specification depends on the XDG Base Directory specification, whose defaults say that the /usr/share/applications directory is the default system-level directory for .desktop files. But per-user overrides go in ~/.local/share/applications (again, by default, but this can be changed). So yes, since you have a ~/.local/share/applications/palemoon.desktop file, that one takes precedence. MATE will fall back to the /usr/share/applications file if your ~/.local/share/applications one goes away.

It is possible that you manually created this user file, or some installer mechanism you used did, or editing the menu entry within MATE's panel using any sort of built-in MATE tool or 3rd-party tool (like MenuLibre) would have copied the system-default file, and let you save any local changes you had made.

Also on the topic of desktop files, if you want to make things even more confusing, you can have just the one menu icon, but with alternative actions, per the desktop entry spec. Most DEs choose to grant access to these additional actions through a right-click of the entry, and some DEs don't support them.

Code: Select all

[Desktop Entry]
Name=Pale Moon Web Browser
GenericName=Web Browser
Comment=Browse the World Wide Web
Exec=palemoon %u
Terminal=false
Type=Application
Icon=palemoon
Categories=Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
StartupNotify=false
Actions=NewPrivateWindow;

[Desktop Action NewPrivateWindow]
Name=Open new private window
Exec=palemoon -private-window