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.
