Would like links should open Firefox in current Activity

[Brady Trainor]

Thank you Duncan! I have a better sense now. It was not crucial for me, but asking the question kept popping up on my TODO list. Thank you for the explanation!

--
Brady


Duncan <1i5t5.duncan at cox.net> writes:

> Brady Trainor posted on Fri, 28 Nov 2014 19:30:09 -0800 as excerpted:
>
>> Is there a way to open a link in web browser in current activity?
>> 
>> Currently, if there is a browser open in a different activity, and not
>> one in current activity, then if I click on a link, say in Emacs, it
>> will head to the other activity and open link in that browser.
>> 
>> Then, I have to separate the tab from the this browser, and right click
>> to switch the browser to the activity I was working in, and switch to
>> that activity.
>> 
>> I could not find a setting to change this, even in the browsers Special
>> Application Settings.
>> 
>> This seems to go against the concept of having various resources being
>> topic specific in Activities. I do not have a special activity for
>> Firefox, I have special activities for topics/projects, and any one of
>> them may need a browser for related surfing, and with browsers existent
>> or nonexistent at any moment.
>
> The problem is that firefox is normally single-instance (and normally 
> single-process at this time, altho that's supposed to change shortly to a 
> chromium type model where each tab is its own process, with a single 
> controlling UI process as well; it's there already in either the alpha or 
> beta channel, I'm not sure which but the plugins are testing/updating for 
> it now).
>
> Since activity assignment is normally at the instance level, in the usual 
> circumstance you'll get exactly the activity routing you describe.  You 
> can either have it open in whatever activity the first firefox window 
> happens to be open in, or you can specifically setup firefox to appear 
> in /all/ activities (via window rules, which is where you were looking, 
> but this isn't quite what you wanted), but then all firefox windows will 
> be in all activities.
>
> There /is/, however, one possible workaround that I've not tried, because 
> I use activities differently.[1]
>
> If you type firefox --help in a terminal window (like konsole), it'll 
> spit out a list of its various command-line options.  Among them is the
> -new-instance option.  This should start a new firefox instance, which at 
> least in /theory/ should come up on your current activity, instead of 
> some other activity with an older firefox instance.
>
> Of course, to get this to work when you click a link, you'll need to add 
> the -new-instance switch to your configuration for opening a new link.  
> Since kde defaults to konqueror as its browser and you figured out how to 
> get it to use firefox instead, however, I'll assume that you can figure 
> out how to get the -new-instance switch on it too.
>
> The complication, of course, is that each firefox instance has a lot of 
> memory overhead and is slower to start than another window or tab in the 
> current instance, etc.  So if you add -new-instance to your default 
> browser settings and go clicking a bunch of links, you'll get a bunch of 
> new instances each using that overhead, instead of a single instance 
> sharing it, thus increasing your memory usage, etc, dramatically.  If 
> you're running an 8-gig or 16-gig memory machine and aren't using most of 
> the memory most of the time anyway, that shouldn't be a big problem and 
> may well actually be much more stable, since a crashing instance won't 
> take down all other instances/windows along with it.  But if you're on a 
> 1 GiB memory machine that's already using swap rather heavily, this isn't 
> going to help matters any, and you may well find it unworkable even if it 
> does give you the desired activity independence.
>
> Of course there's the chance there's some other catch to having it work 
> correctly in practice as well, that I've not seen since I've not actually 
> tried it.  All I'm doing is pointing out the option, since that's the 
> first thing I'd try here, if I were trying to get it to work.
>
> ---
> [1] At least in kde4/plasma1, activities only affect the desktop itself, 
> not the panels.  If changing activities changed the panels as well, I'd 
> find them *MUCH* more useful.  As it is, I only have a couple activities 
> configured, my main activity with picture-of-the-day backgrounds that are 
> otherwise uncluttered by desktop plasmoids, and a plasmoids activity, 
> with a bunch of YaWPs (yet another weather plasmoid) and a comic-strip 
> plasmoid configured.  Once a day I switch to it to read the daily comics, 
> and I switch to it to check the weather occasionally, but the rest of the 
> time I stay on my uncluttered-desktop main activity, with the picture-of-
> the-day backgrounds.  I do use standard X multiple desktops however, and 
> have plasma set to switch them when I scroll on the bare desktop, and 
> group my tasks by desktop to some extent.  Additionally, I have three 
> monitors (full-HD 1920x1080 each) so my single-desktop/activity area is 
> 3X that of a normal full-HD monitor, and two of the monitors are actually 
> 42-inch TVs, thus giving me /lots/ of room to spread out my work even on 
> a single desktop/activity.
>
> I never could understand why activities didn't include the panels, so I 
> could have a whole set of different panels and just switch activities to 
> activate the ones I wanted, in addition to switching the stuff on the 
> desktop background.  Well, maybe with kde-frameworks5/plasma2, which I've 
> tried a couple times but kwin5 doesn't seem to like my system and 
> immediately crashes so I've never gotten far, and since so many parts of 
> 5/frameworks are named identically to the kde4 versions, having both on 
> the same system is difficult without a chroot/VM, so I've never had the 
> ability to leave it there and troubleshoot, I've always had to delete the 
> 5/frameworks stuff and reinstall the kde4 stuff.  Oh, well, hopefully 
> they fix kwin5 not to crash on my system by the time they say it's ready 
> for normal users...
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.