Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Monday, 20 February 2023 18:27:46 GMT jon danniken wrote: > Personally I would prefer that virtual desktops were essentially > "firewalled" from each other (at least from the user's perspective), > as if they were running on another computer altogether. No > notifications, no automatic switching, nothing unless I specifically > tell the machine to do so. That's a me-too from me. KDE's trying altogether too hard to be clever. -- Regards, Peter.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Personally I would prefer that virtual desktops were essentially "firewalled" from each other (at least from the user's perspective), as if they were running on another computer altogether. No notifications, no automatic switching, nothing unless I specifically tell the machine to do so. Jon On Sun, Feb 19, 2023 at 8:24 PM Roberto Ragusa wrote: > > On 12/16/22 13:25, René J.V. Bertin wrote: > > On Friday December 16 2022 04:20:50 Duncan wrote: > > > >> Of course besides being confusing it's just harder to clearly explain in a > >> short form similar to the above choices, and it'd certainly be the most > >> esoteric choice, so I can't really blame them for losing it, but it's > >> still lost behavior that some people might miss... > > > > What's confusing about it? It just means "don't change desktops unless the > > user really wants it". Or, call the option "don't change desktops" and > > leave it to change the desktop via one of the actions designated for that > > particular purpose. It'd be debatable in that case whether clicking on a > > window representation in the panel could be included *) > > > > What I am seeing on older versions is that the desktop is not switched, > the window appears in the taskbar (which is set to only show windows in > the current desktop) and suggests me to click there to switch desktop > and reach the activated window. > This is perfect, because it doesn't interrupt your "sequence of link clicks", > but gives you a fast way to reach the browser when you want to. > It looked to me very smart and well thought. > > So this is now gone away? > > Regards. > > -- > Roberto Ragusamail at robertoragusa.it >
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Sunday February 19 2023 21:24:25 Roberto Ragusa wrote: >What I am seeing on older versions is that the desktop is not switched, >the window appears in the taskbar (which is set to only show windows in >the current desktop) and suggests me to click there to switch desktop >and reach the activated window. >So this is now gone away? This is more or less how things always worked for me too, until a recent Firefox update a while back. So not as a result of some change in KDE! I haven't verified if that change has been reverted. R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On 12/16/22 13:25, René J.V. Bertin wrote: On Friday December 16 2022 04:20:50 Duncan wrote: Of course besides being confusing it's just harder to clearly explain in a short form similar to the above choices, and it'd certainly be the most esoteric choice, so I can't really blame them for losing it, but it's still lost behavior that some people might miss... What's confusing about it? It just means "don't change desktops unless the user really wants it". Or, call the option "don't change desktops" and leave it to change the desktop via one of the actions designated for that particular purpose. It'd be debatable in that case whether clicking on a window representation in the panel could be included *) What I am seeing on older versions is that the desktop is not switched, the window appears in the taskbar (which is set to only show windows in the current desktop) and suggests me to click there to switch desktop and reach the activated window. This is perfect, because it doesn't interrupt your "sequence of link clicks", but gives you a fast way to reach the browser when you want to. It looked to me very smart and well thought. So this is now gone away? Regards. -- Roberto Ragusamail at robertoragusa.it
Browser security improvement suggestion (Was Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?)
On 2023-01-23 18:01:05 Duncan wrote: > Duncan posted on Mon, 23 Jan 2023 19:21:17 - (UTC) as excerpted: > > Consider the possible security side-effects. As an example, consider a > > browser password dialog (say for firefox's master password, if you have > > it setup). Often you want it raised so you see it and can enter the > > password, but the browser folks ultimately had to change their behavior > > a bit because bad sites were trying to trigger popups without browser > > chrome and setup to appear just like the default password dialogs, in > > ordered to steal people's passwords. > > Realized on reading that as posted that it implies the browser folks had > to change their behavior regarding raising the password dialog. That > wasn't intended and (AFAIK) isn't necessarily accurate (I unintentionally > made a statement I can't initially verify one way or the other). > > What I /intended/ to say was that in my chosen example, they had to change > both password dialogs and their general web-page-popup behavior, primarily > web-page-popup appearance, to ensure that web-page-popups were distinct > enough from system dialogs (password and other, browser and not) that > there was no confusion, and that while raising and focus behavior may in > the abstract be different from that, be careful that any changes to focus > behavior rules you make, don't inadvertently neutralize behavior they may > have instituted due to security concerns that might be unrelated to the > particular example I named. > > IOW, just be aware that a browser is arguably the most security exposed > sensitive app most people commonly run, and that any changes you make to > its default behavior, including apparently security-unrelated changes, may > have unintended consequences in terms of its security posture. With that > awareness and assuming a reasonable security sense that unfortunately many > folks don't seem to have (but just the fact that someone's posting/reading > here suggests a higher likelihood they do, due to self-selection meaning > the least security-aware wouldn't be here in the first place), proceeding > cautiously should be reasonable, but be particularly alert for unusual or > unexpected behavior for awhile after that, just in case. Maybe the browser folks could provide a way for the user to replace e..g. an icon on such sensitive popups, with their own custom image, that couldn't be matched by malware? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Duncan posted on Mon, 23 Jan 2023 19:21:17 - (UTC) as excerpted: > Consider the possible security side-effects. As an example, consider a > browser password dialog (say for firefox's master password, if you have > it setup). Often you want it raised so you see it and can enter the > password, but the browser folks ultimately had to change their behavior > a bit because bad sites were trying to trigger popups without browser > chrome and setup to appear just like the default password dialogs, in > ordered to steal people's passwords. Realized on reading that as posted that it implies the browser folks had to change their behavior regarding raising the password dialog. That wasn't intended and (AFAIK) isn't necessarily accurate (I unintentionally made a statement I can't initially verify one way or the other). What I /intended/ to say was that in my chosen example, they had to change both password dialogs and their general web-page-popup behavior, primarily web-page-popup appearance, to ensure that web-page-popups were distinct enough from system dialogs (password and other, browser and not) that there was no confusion, and that while raising and focus behavior may in the abstract be different from that, be careful that any changes to focus behavior rules you make, don't inadvertently neutralize behavior they may have instituted due to security concerns that might be unrelated to the particular example I named. IOW, just be aware that a browser is arguably the most security exposed sensitive app most people commonly run, and that any changes you make to its default behavior, including apparently security-unrelated changes, may have unintended consequences in terms of its security posture. With that awareness and assuming a reasonable security sense that unfortunately many folks don't seem to have (but just the fact that someone's posting/reading here suggests a higher likelihood they do, due to self-selection meaning the least security-aware wouldn't be here in the first place), proceeding cautiously should be reasonable, but be particularly alert for unusual or unexpected behavior for awhile after that, just in case. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Frank Steinmetzger posted on Wed, 18 Jan 2023 14:15:08 +0100 as excerpted: > In which other use case do we not want to auto-raise the window? If, > say, we double-click an image in Dolphin and want it opened in gimp, > which sits on another desktop. > > And this made me test it: I opened gimp on Desktop 1, Dolphin on Desktop > 2, right-clicked an image and selected Open with… Gimp. And voilà: it > showed the old behaviour: the gimp entry appeared on the taskbar and > flashed. I clicked on it and was moved to Desktop 1. > > So the problem we have with firefox is either a firefox problem, or the > setting “Switch to that desktop” didn’t work. And with “Bring window to > current Virtual Desktop”, the Gimp window has moved Desktop, but was not > raised to the top. So I suspect a Firefox problem here, not Kwin. Reading that, seems to me the difference in behavior could be focus- stealing related. I'd suggest: 1) Check that neither gimp nor firefox have a kwin window rule affecting focus-stealing, and adjust/experiment with it if so. 2) Reexamine your general focus-stealing settings (under window behavior, focus); perhaps testing strengthening them a notch or two and see if that triggers other unwanted behavior. 3) If necessary (presumably because strengthening the general focus- stealing prevention setting in #2 triggers other unwanted behavior), experiment with a firefox anti-focus-stealing kwin window rule. General notes on window rule focus rules: There are two window rule settings affecting this, focus stealing prevention, and focus protection, basically the inverse of stealing prevention. Hover over them in the property-add dialog to get descriptions. They interact with each other and the general setting based on the window that has focus and the window that's attempting to get it, so the extreme case for a single window would be setting one to extreme while the other is set to none, but that would of course still interact with the setting on the other window. It is of course possible to set a fairly generic rule by adjusting the window match wide enough, thus allowing the "other window" to have a window rule matching it as well even when it could be any other app, but keep in mind that in my experience, such general rules often require possibly multiple specific exception rules as well, since they're interfering with behavior as designed. (As an example, I have a general window rule that forces most windows to my default activity, but had to set exceptions for plasmashell windows to allow them to still appear on the otherwise-blank non-default activity. Example 2, a rule that sets active/inactive opacity, that requires exceptions for various windows where that's inappropriate. Altho in this case that's not much more of a bother since they really are exceptions that I want to treat differently, so even without the generic rule I'd likely have exception rules for them anyway.) Of course the overall result is a proliferation of window rules due to generic rules, exceptions, and in some cases exceptions to exceptions. But ultimately it works and I'm happy with it and that kde/ plasma makes such overrides possible in the first place. =:^) And a caution: Consider the possible security side-effects. As an example, consider a browser password dialog (say for firefox's master password, if you have it setup). Often you want it raised so you see it and can enter the password, but the browser folks ultimately had to change their behavior a bit because bad sites were trying to trigger popups without browser chrome and setup to appear just like the default password dialogs, in ordered to steal people's passwords. It's thus worth considering this case if interfering with normal browser behavior, in case it might allow a popup to mimic too closely the behavior of the password dialog. (OTOH, my settings at least, tend to be customized enough that it'd pretty much take someone who already had access to have enough information to properly mimic behavior and fool me. A window that looks like a default Windows dialog is going to stick out like a sore thumb! Unfortunately, based on the number of people getting taken which must provide at least enough reward for the bad guys to keep trying, many just blindly type and click without thinking...) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Wednesday January 18 2023 14:15:08 Frank Steinmetzger wrote: > So I suspect a Firefox problem here, not Kwin. I agree, and you'll notice that my question was whether KWin would be able to prevent such behaviour ;) R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Am Fri, Dec 16, 2022 at 07:56:11AM -0500 schrieb rhkra...@gmail.com: > On Thursday, December 15, 2022 11:20:50 PM Duncan wrote: > > Options: > > > > * Bring (existing) window to current virtual desktop > > > > IIRC this is the new default, and seems to be the behavior you're > > describing as unwanted. > > > > * Switch to that virtual desktop (and raise the existing window there) > > > > This is what I chose as it makes more sense to me. > > > > Old and definitely confusing but arguably could-be-useful behavior, now > > missing option: > > Definitely useful / preferred behavior for me. As I'm going through my > emails, > I click on links that I want to read later (usually after getting through > some > portion of my emails). > > With my old versions of firefox (still in use) I am not distracted from my > email reading. > […] > Very distracting / aggravating. Sorry, I’m a bit behind with ML reading. But I’ve also noticed this behaviour with firefox a while ago and it irks me as well. I just composed an issue on BKO, but now that I wrote down the essence of this thread, I couldn’t just send it and whine, because it made me ponder. In which other use case do we not want to auto-raise the window? If, say, we double-click an image in Dolphin and want it opened in gimp, which sits on another desktop. And this made me test it: I opened gimp on Desktop 1, Dolphin on Desktop 2, right-clicked an image and selected Open with… Gimp. And voilà: it showed the old behaviour: the gimp entry appeared on the taskbar and flashed. I clicked on it and was moved to Desktop 1. So the problem we have with firefox is either a firefox problem, or the setting “Switch to that desktop” didn’t work. And with “Bring window to current Virtual Desktop”, the Gimp window has moved Desktop, but was not raised to the top. So I suspect a Firefox problem here, not Kwin. -- Grüße | Greetings | Salut | Qapla’ Smileys are footnotes for the stupid. ;-) signature.asc Description: PGP signature
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Monday December 19 2022 06:56:56 Duncan wrote: Was there an answer to my question in that essay (about the version range where KWin had a setting to control raising behaviour)? >But low-Q or not, old computer backing up the fancy if low-q display or >not, how many have such a display "wall" at all? That's /something/. And >it /does/ change the way you work. I also have a Macbook with a big enough external display and even there I wouldn't want to have to work around the fact that a window supposed to be on another virtual desktop might come cover the window I'm working in, be it as a result of something I just did or of some automatic behaviour. That rig runs OS X (sic, because that's what the version in question was called) and desktop-hopping isn't an issue there. Because that's the thing: windows can be raised for multiple reasons, direct user request being just one of them (albeit a priori the most frequent one). AFAIK websites can ask that their window be raised, for instance. R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
rhkramer posted on Fri, 16 Dec 2022 07:56:11 -0500 as excerpted: > As I'm going through my emails, > I click on links that I want to read later (usually after getting > through some portion of my emails). > > With my old versions of firefox (still in use) I am not distracted from > my email reading. > > On my most recent installation of (Debian Jesse / Firefox (yes, I > know)), when I click on a link in an email it immediately switches me to > the firefox desktop and "raises" that window. Chuckled at the sig. FWIW, while I can agree the new behavior could be annoying, not to brag (well... sort of... but see the compromises below) I don't have the particular problem you describe due to my layout, two 4K 75-inch TVs side- by-side for 7680x2160 overall resolution, 130x36 inch (3.3x0.9m). The left-hand monitor often runs firefox PnP mode fullscreen youtube, with the right hand monitor being divided into four 1860x1080 working panes (sized so there's a narrow 120-px wide strip left on the far right for my conky system monitors) in 2x2 layout. I use kwin window rules to default my usual windows to the working pane size. So matching to your scenario the left monitor would still be a full- monitor firefox PnP video window, with the regular ff window in one pane on the right, and email in another pane. That would leave two other panes open for say an email reply and a konsole window. Clicking email links would open new tabs in the existing ff main window, obscuring the youtube page tab, but the video would still be playing unobstructed full-screen on the other monitor and with the tree-style-tab extension side-bar open in the firefox main-window, switching tabs there is a non-issue. All windows still visible, and with appropriate kwin focus policy and focus-stealing-prevention, the email window retains focus if that's what the mouse is over. And even if the ff window gets focus, scrolling scrolls the window its over not the window with focus, so would scroll the mail window. And clicking another link would of course raise the email window and pass the click, opening the link in firefox as expected even if the email window didn't have focus when the link was clicked. Such a big workspace really changes the way you work. With the exception of full-screen videos, you don't /want/ most things maximized or full- screened, for instance, because it's just /too/ big. 1/4 screen (half vert, half horiz) for a 2x2 layout on one monitor, is /much/ more practical, of course leaving the other panes of the 2x2 open for other things without obscuring anything. Tho I do still use multiple desktops, but they tend to be for really different tasks, like one for games, one for online (rss feeds, email, etc), and one for upgrades (a bunch of konsole windows, keeping in mind I run gentoo and actually build the upgrades from sources, plus run live-git for some things like most of kde, tracking various git logs as part of my upgrade process, so a bunch of konsole windows and a ff window to read logs while upgrading while troubleshooting and investigating/filing bugs makes sense), not for different bits of the same task (clicking links in an email client to open them in the browser for your example, or the different konsole windows and browser window for the upgrade task example). But while it's a dream in many aspects, there have been compromises. The cpu/mobo are a decade old now, a six-thread AMD fx6100 from 2011, the graphics a half-decade-old AMD Radeon rx460 (polaris 11 baffin), and while I did upgrade to ssds and it has a then sizable now middling 16 gig RAM, it really struggles to play full 4K 3840x2160@60Hz web videos (50Hz is better, only an occasional frame-freeze with nothing else going, 25 or 30 Hz much better with middle-duty additional tasks, or downgrade to full HD 1920x1080 if I'm doing something heavy like a gentoo upgrade build). And the TVs are low-end, some of the first 75" 4Ks to sell under $1000 each and now several years old, so are dimming and showing edge-lit-LED artifact banding, not to mention the "percussive maintenance" I have to do on the one to get it to turn on if I leave it off long enough to cool down. But low-Q or not, old computer backing up the fancy if low-q display or not, how many have such a display "wall" at all? That's /something/. And it /does/ change the way you work. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Friday December 16 2022 07:56:11 rhkra...@gmail.com wrote: >Definitely useful / preferred behavior for me. As I'm going through my >emails, >I click on links that I want to read later (usually after getting through some >portion of my emails). Exactly the use-case I tried to describe. FWIW, you don't even have to want to go through a list of links and/or emails. Often enough there is/are link(s) in a longish email that you're reading through that you want to click on when you come across them (so as not to have to go through all that text again) but without stopping to read that email. So you don't want to get another window in your face. It should not be necessary to lock your browser to a different, fixed desktop in that case. In fact this is another instance where a desktop/laptop computer should NOT behave the same as a phone/tablet!! R
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Thursday, December 15, 2022 11:20:50 PM Duncan wrote: > Options: > > * Bring (existing) window to current virtual desktop > > IIRC this is the new default, and seems to be the behavior you're > describing as unwanted. > > * Switch to that virtual desktop (and raise the existing window there) > > This is what I chose as it makes more sense to me. > > Old and definitely confusing but arguably could-be-useful behavior, now > missing option: Definitely useful / preferred behavior for me. As I'm going through my emails, I click on links that I want to read later (usually after getting through some portion of my emails). With my old versions of firefox (still in use) I am not distracted from my email reading. On my most recent installation of (Debian Jesse / Firefox (yes, I know)), when I click on a link in an email it immediately switches me to the firefox desktop and "raises" that window. (Aside: on that machine (not the one I use for most email) I have two firefox installations -- one the original with Jessie, another much more recent version for web sites that doesn't work with -- as I write this, I don't remember which version of firefox has the described behavior -- maybe the newer one). Very distracting / aggravating. Please keep / restore the old behavior. As a workaround, I copy the links while I'm reading email on that computer, then paste them into Firefox later. -- rhk (sig revised 20221206) If you reply: snip, snip, and snip again; leave attributions; avoid HTML; avoid top posting; and keep it "on list". (Oxford comma (and semi-colon) included at no charge.) If you revise the topic, change the Subject: line. If you change the topic, start a new thread. Writing is often meant for others to read and understand (legal documents excepted?) -- make it easier for your reader by various means, including liberal use of whitespace (short paragraphs, separated by whitespace / blank lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and references. If someone has already responded to a question, decide whether any response you add will be helpful or not ... A picture is worth a thousand words. A video (or "audio"): not so much -- divide by 10 for each minute of video (or audio) or create a transcript and edit it to 10% of the original. A speaker who uses ahhs, ums, or such may have a real physical or mental disability, or may be showing disrespect for his listeners by not properly preparing in advance and thinking before speaking. (Remember Cicero who did not have enough time to write a short missive.) (That speaker might have been "trained" to do this by being interrupted often if he pauses.) A radio (or TV) station which broadcasts speakers with high pitched voices (or very low pitched / gravelly voices) (which older people might not be able to hear properly) disrespects its listeners. Likewise if it broadcasts extraneous or disturbing sounds (like gunfire or crying), or broadcasts speakers using their native language (with or without an overdubbed translation). A person who writes a sig this long probably has issues and disrespects (and offends) a large number of readers. ;-) '
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Friday December 16 2022 04:20:50 Duncan wrote: Thanks, but >be the default (or only available behavior as it was before) because it >/is/ confusing. Sorry, your entire answer is a little confusion to read through. >Old and definitely confusing but arguably could-be-useful behavior, now >missing option: Can you tell what version of KWin introduced the setting and in what version range the option is/was present? I'm using KWin 5.12.x (probably ancient but it does the trick for me just fine) and I cannot seem to find the entire setting in the "Window Behaviour" KCM. And, supposing my KWin version only has that "old and [...] arguably could-be-useful behaviour", how come FF manages to get the window to the current desktop - is there a specific call that can be made just to change the desktop a window is displayed on? (AFAIK virtual desktops are not an X11 concept!) > >* Only switch to that desktop if manually activating a window, via alt- >tab, taskbar, etc. If an existing window on a different virtual desktop ... >Of course besides being confusing it's just harder to clearly explain in a >short form similar to the above choices, and it'd certainly be the most >esoteric choice, so I can't really blame them for losing it, but it's >still lost behavior that some people might miss... What's confusing about it? It just means "don't change desktops unless the user really wants it". Or, call the option "don't change desktops" and leave it to change the desktop via one of the actions designated for that particular purpose. It'd be debatable in that case whether clicking on a window representation in the panel could be included *) In theory it sounds fine to switch to the target desktop, but in practice that can be just as annoying as having to switch manually. How often does it happen that you read through an email with a list of some kind of offers and you just want to process that list first, opening the links as a stack that remains in the background? KDE was always great for power users with methods like that ... losing them really feels like laziness on the part of the devs carrying on the torch... R. *) Or not be debatable, once you realise that that too is an action that could well have multiple effects. Already the effect depends on whether or not the widget represents what resumes to a single window or an application with multiple windows open. PS: for anyone wondering about the same FF thing, there may be a workaround in https://bugzilla.mozilla.org/show_bug.cgi?id=1805766 . It works for me, and now I have to dig out the window myself, but that turns out to be much less invasive/production-inhibiting than I thought.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Duncan posted on Fri, 16 Dec 2022 00:19:44 - (UTC) as excerpted: > René J.V. Bertin posted on Thu, 15 Dec 2022 14:21:36 +0100 as excerpted: > >> Firefox 109 has a new trick up its sleeve: opening an URL from, say, >> KMail cause the FF window that will host the new tab to raise itself >> (as before) >> AND now also to switch to the current virtual desktop. >> >> I don't want that; is there a way to disallow this behaviour in KWin? >> (I haven't found ...). > > Punting ATM [but] IIRC yes, there's an option for it[...] > Will try to post a followup FWIW couldn't find the git commits for it again but *DID* find the config option... Well, sort of. There's two settings available while the old behavior was a third that doesn't seem to be available any longer in that exact form. I can see why it was confusing and they changed it, and had been hit by it myself a couple times, but still, the old behavior did have its uses and should therefore arguably still be an option, even if it really shouldn't be the default (or only available behavior as it was before) because it /is/ confusing. Anyway, option location: (Plasma) systemsettings > workspace > window management > window behavior > advanced > virtual desktop behavior: Alternatively command line: kcmshell5 kwinoptions (brings up window behavior, go from there). Alternatively keyword "behavior" in krunner (brings up several options including window behavior, select that and go from there). Actual setting: When activating a window on a different virtual desktop: Options: * Bring (existing) window to current virtual desktop IIRC this is the new default, and seems to be the behavior you're describing as unwanted. * Switch to that virtual desktop (and raise the existing window there) This is what I chose as it makes more sense to me. Old and definitely confusing but arguably could-be-useful behavior, now missing option: * Only switch to that desktop if manually activating a window, via alt- tab, taskbar, etc. If an existing window on a different virtual desktop is activated automatically (like when clicking a link opens a new tab to the linked URL in an existing browser window on a different virtual desktop), raise that window on its existing virtual desktop but do NOT switch desktops. Of course besides being confusing it's just harder to clearly explain in a short form similar to the above choices, and it'd certainly be the most esoteric choice, so I can't really blame them for losing it, but it's still lost behavior that some people might miss... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
René J.V. Bertin posted on Thu, 15 Dec 2022 14:21:36 +0100 as excerpted: > Firefox 109 has a new trick up its sleeve: opening an URL from, say, > KMail cause the FF window that will host the new tab to raise itself (as > before) > AND now also to switch to the current virtual desktop. > > I don't want that; is there a way to disallow this behaviour in KWin? (I > haven't found ...). Punting ATM as I'm dealing with another live-git bug (klipper popup throwing plasmashell into and endless loop and crash, restarting plasmshell only loops/crashes again, going to try clearing klipper history...). In the mean time... I saw that go into git (I run live-git kde and follow many of the component git logs) and IIRC yes, there's an option for it, but I've got my hands full ATM and can't go looking... Will try to post a followup in a few minutes to a few days, depending on how badly my current bug continues to bite. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Hi, Firefox 109 has a new trick up its sleeve: opening an URL from, say, KMail cause the FF window that will host the new tab to raise itself (as before) AND now also to switch to the current virtual desktop. I don't want that; is there a way to disallow this behaviour in KWin? (I haven't found ...). At least I assume that KWin is the application that handles the virtual desktops and either way I'd like to restrict window/desktop changes to KWin. Thanks, R.
