https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #83 from Arash B ---
But there's a satisfying alternative solution: Add "Current Activity" to the
attribute "Activity" in an applications "Special Application Settings".
I'm specifically talking ab
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #85 from Arash B ---
How come that KDE Plasma can restrict all windows of an app to a specific
activity (by using its Special Application Settings) but it isn't possible to
restrict them to the *current* activity?
KDE Plasma can di
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #86 from Arash B ---
Assuming specialSettings represents an instance of a Special Application
Settings, then logic dictates that somewhere in KDE Plasma's source code the
following if-statement *already* exists
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #79 from Arash B ---
How come you say there's no easy way to fix this when the user can manually
restrict a borderless window to the current activity? If this can easily be
done manually, then it should be doable programatically.
Ev
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #81 from Arash B ---
But KDE Plasma can detect if a borderless window is a Plasma window (such as
application launcher or notification). Thus, if a borderless window appears and
IS a plasma window then KDE Plasma does NOT have to apply this
https://bugs.kde.org/show_bug.cgi?id=274931
Arash B changed:
What|Removed |Added
CC||ara...@gmail.com
--- Comment #50 from Arash B
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #51 from Arash B ---
And what do you mean you have to do this since "novice users don't know of
alt+f3 when there's no border"?! If you wan't to move a borderless window
between activities then you simply and gently
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #53 from Arash B ---
My comment is perfectly helpful in that it explains system expected behavior in
this particular case and points out the flaws in your rationale for not doing
anything about this over many years when it has been pointed
https://bugs.kde.org/show_bug.cgi?id=384293
Bug ID: 384293
Summary: plasma-nm fails to correctly import from an openvpn
config file
Product: plasma-nm
Version: 5.10.5
Platform: Neon Packages
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=384293
--- Comment #1 from Arash B ---
It is noteworthy that in the openvpn connection's advanced settings the setting
"Cipher" isn't set to anything. The advanced settings can be reached by
clicking the "Advanced..." button once
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #55 from Arash B ---
@martin @smldis
The solution that has been implemented is wrong and should be removed. When the
user opens a borderless window then that window should be placed in the current
activity where it was opened.
The reasons
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #58 from Arash B ---
Ok but I have cloned the kwin git repo (https://github.com/KDE/kwin) to have a
look for myself. I was wondering if you could show me where the function body
of
bool WindowRules::checkNoBorder(bool noborder, bool
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #62 from Arash B ---
@martin @tom
So this is my assessment of the situation: the border property is incorrectly
used to determine if a window should be placed on all activities, when in fact
other indicators should be used instead to make
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #63 from Arash B ---
On a different point, I would advice that full function definition is written
as a comment above where macros are used to write function header and body. It
would for instance look like this in rules.cpp line 856
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #65 from Arash B ---
@Martin
Ok then but we should create such a complete list for the purpose introducing
logic that allows us to discern different window elements from each other (for
instance for the purpose of determining whether if or
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #66 from Arash B ---
But if you agree with this then first we have to establish that list, and
gather input from others on KWins e-mail-list
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #69 from Arash B ---
@Martin
Well then we go a step further out; some part of some api/interface (class
constructor, public function, etc.) is used by others to signal to KWin that a
window element should be created. Calling this api
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #70 from Arash B ---
Aha! Workspace::createClient is part of Kwins public Api, correct? You can
overload it and add enum var clientType. Its default value is NORMAL_APP but
there will also be enum values such as PLASMA_WIDGET
18 matches
Mail list logo
