[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
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: if specialSettings.position.activity is set then if specialSettings.position.activity is set to "All Activities" then make window to appear on all activities else if specialSettings.position.activity is set to specific activity then make window to appear on specified activity only Now a new else if branch needs to be added to the inner if-statement (for when activity is set to "Current Activity"). Or could you please explain how KDE Plasma works so fundamentally different from this, because it makes no sense at all! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
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 discern what application a newly appeared window belongs to (otherwise the Special Application Settings wouldn't work) and it can do this *even* if the window is borderless. KDE Plasma can also discern what is the currently selected activity (since it manages to correctly put newly appeared windows with borders in the current activity). So the two pieces of logic are already in place and working, now they need to be used to add a new small feature. Of course *some* source code must be added to add the option "Current Activity" to said drop-down list and make it work. But besides from that how could it possibly be so that KDE Plasma is too fundamentally flawed that adding this feature would require redoing KDE Plasma from the ground up? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
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 about the settings you see when you from a window navigate this way: Click its icon to the top left on its title bar (or press Alt+F3) >> More Actions >> Special Application Settings >> the Size & Position tab >> the Activity attribute >> Drop-down list. Add "Current Activity" to said drop-down list. It's self explanatory what the option should do. This way the user can for instance for the app "google-chrome" fix this undesirable behavior. It's not a perfect fix but still very good and convenient, given the circumstances. Currently I've tested this for Google Chrome when you choose a specific activity from the drop-down list. The Google Chrome will only appear in that activity, even if the window is borderless when it opens. The only scenario that is a down-side to this solution (and it's a far-fetched scenario) is that the chosen setting will apply itself to some *other* application also named "google-chrome" (this is the far-fetched part, that some other random app is also called "google-chrome"). But what will happen then is that that other application too will be restricted to the current activity, which is most likely the user's desired system behavior anyway. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
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 fix. If however a borderless window appears and is NOT a plasma window then KDE Plasma can apply this fix. If a borderless window is created then If the borderless window is a Plasma window then Do nothing Else Execute Alt+F3 on the window (but don’t show the menu on the GUI) Enter sub-menu Activities Select the current Activity -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
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. Even if an app opens in a borderless window (and thus the window appears in all Activities), then I can through KDE Plasma’s GUI (manually) make it to only appear in the current Activity. I just have to follow these steps: Press Alt+F3. Click sub-menu Activities. Choose the current activity. My question is if this can immediately be done manually on a borderless window, then why can’t it be done programmatically and automatically by KDE plasma? At least the silly solution to programmatically do the above three steps is available. I.e. KDE plasma is programmed to execute the following steps If a borderless window is created then Execute Alt+F3 (but don’t show the menu on the GUI) Enter sub-menu Activities Select the current Activity What is the problem that makes this solution not applicable? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #70 from Arash B <ara...@gmail.com> --- 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, PLASMA_EXTENDER, etc.. In time, we can ask other devs to set clientType appropriately when calling createClient. Is this a good approach? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #69 from Arash B <ara...@gmail.com> --- @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/interface part further leads to the creation a Client class instance, correct? Then add kwinWindowType to this api/interface part but give it a default value of UNKNOWN if the corresponding arg isn't passed on when the api/interface part is called. Then further pass on the value of kwinWindowType to the Client constructor (or Client::manage() which seems to serve instead of a constructor). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #66 from Arash B <ara...@gmail.com> --- 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.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #65 from Arash B <ara...@gmail.com> --- @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 not a window element should be on all activities). In the end they are all represented by an instance of the class Client, is this correct? I propose that a new instance variable is introduced in the class Client called kdeWindowType. Its value is decided by an enum with as many possible values as there are discernible types of kde window elements (hence why we need that complete list). But the enum also has an extra value called UNKNOWN. By default, every time a Client instance is created kdeWindowType is simply put to UNKNOWN. No further changes are introduced in your repo at the time. This way this change doesn't break KDE or introduce any new bugs at all, because kdeWindowType is only written to, never read. Then I can hunt down all other KDE git repos where instances of your Client class are created, and ask the devs to correctly set the value of kdeWindowType by passing on the correct argument value (determined by the enum) when making the call to create a Client class. And then in the future, determining the type of a window element will just be a getKdeWindowType() call away... This change will take lots of time but solve many of your problems in the future. Things will have to get messy before they get any better... Do you agree with this? All you have to do is to introduce the class instance variable kdeWindowType and the enum. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #63 from Arash B <ara...@gmail.com> --- 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: // Function body declaration of bool WindowRules::checkNoBorder( bool arg, bool init ) const CHECK_RULE(NoBorder, bool) This way the function name will actually be searchable with a tool like grep. I spent the better part of an hour trying to locate this, and was at last thinking that the function body declaration is somehow linked from a library or another repo of code. It will take some time to add such comments but it will be worth it and save time in the end. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931
--- Comment #62 from Arash B <ara...@gmail.com> ---
@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 this assessment. This is
because using the border property will place certain windows (such as chrome)
on all activities when they shouldn't be.
I'm therefore trying to make a complete and distinct list of types of windows
that should be placed on all activities. I want to use this list to try to
create logic (in the code) that correctly determines if a window element should
be on all activities. I will create such logic on my own and then present them
in this thread for review and discussion, but someone else would have to
finally incorporate them in the software.
Here is a highly partial and vague start of the list of types of window
elements that should be placed in all activities when created:
* plasma extenders
* applet browser
* activity manager
Could you help me with two things? Firstly, could we complete this list by
adding all types of window elements that should be placed on all activities?
Secondly, could we make the list more granular by dividing each list item into
subcategories? For instance I'm thinking plasma extenders is a broad category
encompassing many different *types* of things. I don't need to know every
conceivable plasma extender that there's, but only relevant *types*.
If certain types of window elements require different method of procedures to
determine their type, then it would be very appreciated if they are mentioned
distinctively as a separate subcategory. For instance maybe a different set of
function calls has to be made to determine their type, while other functions
are used for other window element types.
I'm assuming each of these window elements of this list are represented by an
instance of the class KWin::Client, and that for all of them it is determined
in manage.cpp on line 234 by the following statement
...
if (Activities::self() && !isMapped && !noborder && isNormalWindow() &&
!activitiesDefined) {
...
Are these two assumptions correct? Or is it (possibly further) assessed
somewhere else whether if or not the window element should be placed on all
activities?
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #58 from Arash B <ara...@gmail.com> --- 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 init = false) const is. I've found its definition in rules.h but the function body is nowhere to be found in the repo. Is it correct that the function WindowRules::checkNoBorder is called from line 184 in bool Client::manage(xcb_window_t w, bool isMapped) in clients.cpp? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #55 from Arash B <ara...@gmail.com> --- @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 for this are twofold. Firstly, this is (by the user) the expected system behavior. This is the expected bhavior because all other windows that have a border are placed in the current activity when opened. In nearly every workflow almost all windows have borders, and so when it happens nearly every time that the window is placed in the current activity then this becomes an expected behavior. Secondly, even if the user would like to change the window's activity settings then there's a very easy way even if there's no border; the user simply locates the window's entry in the task manager at the bottom of the screen and right clicks it. Then the user selects the entry "Move to activity >" from the menu. >From there the user can select "Show on all activities", and thus the user has easily accomplished what you're concerned he won't be able to do without a window border. Is there anything in this argument that you regard incorrect? -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 384293] plasma-nm fails to correctly import from an openvpn config file
https://bugs.kde.org/show_bug.cgi?id=384293 --- Comment #1 from Arash B <ara...@gmail.com> --- 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 you have selected the openvpn connection from the configuration window. The "Cipher" setting is under the "Security" tab. The dropdown menu of the "Cipher" setting is blank, while the attached openvpn config file clearly states "cipher aes-128-cbc" on a line. So this is probably a minor but separate bug. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 384293] New: plasma-nm fails to correctly import from an openvpn config file
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 Status: UNCONFIRMED Severity: normal Priority: NOR Component: editor Assignee: jgrul...@redhat.com Reporter: ara...@gmail.com Target Milestone: --- Created attachment 107657 --> https://bugs.kde.org/attachment.cgi?id=107657=edit Contains an openvpn config file and a crt file plasma-nm fails to correctly import settings from an openvpn config file. Specifically it doesn't correctly import the security settings in the advanced properties. Connecting to the VPN server through the widget fails afterwards. PREPARATION FOR REPRODUCING THE BUG Download the two attached files from this bug report and put them in the same folder STEPS TO REPRODUCE THE BUG 1. Open the "Networks" widget from the Task Manager by clicking on the widget (the widget's icon on the Task Manager is a wifi-symbol on most systems) 2. Click the "Configure the network connections..." in the top right of the widget window 3. Click the "Add new connection" in the bottom left of the new window 4. Select the "Import VPN connection..." from the bottom of the list and click the "Create" button 5. Browse to the file "UK London.ovpn" and click the "Open" button 6. Click the "No" button in the "Copy certificates - System Settings Module" window that pops up 7. Fill in a random username and password in the text fields "Username" and "Password" in the "Connections - System Settings Module" window 8. Click the "Apply" button in the same window 9. Open the "Networks" widget from the Task Manager 10. Click the "Connect" button next to the VPN connection "UK London" EXPECTED RESULT Connection to the VPN server is established (given that a valid username and password are provided) ACTUAL RESULT The procedure fails silently and without any GUI indication of failure at all. The command "journalctl -u NetworkManager -b 0" in a terminal shows the following lines in the end of the log file: sep 02 19:36:16 usernameXYZ NetworkManager[1104]: [1504373776.3486] audit: op="connection-activate" uuid="cc6019ad-9e98-4b18-a9f5-e09695491b53" name="UK London" pid=1667 uid=1000 result="success" sep 02 19:36:16 usernameXYZ NetworkManager[1104]: [1504373776.3562] vpn-connection[0x123f610,cc6019ad-9e98-4b18-a9f5-e09695491b53,"UK London",0]: Started the VPN service, PID 29771 sep 02 19:36:16 usernameXYZ NetworkManager[1104]: [1504373776.3799] vpn-connection[0x123f610,cc6019ad-9e98-4b18-a9f5-e09695491b53,"UK London",0]: Saw the service appear; activating connection sep 02 19:36:16 usernameXYZ NetworkManager[1104]: [1504373776.4004] vpn-connection[0x123f610,cc6019ad-9e98-4b18-a9f5-e09695491b53,"UK London",0]: VPN connection: failed to connect: 'Invalid HMAC auth.' sep 02 19:36:16 usernameXYZ NetworkManager[1104]: [1504373776.4014] vpn-connection[0x123f610,cc6019ad-9e98-4b18-a9f5-e09695491b53,"UK London",0]: VPN plugin: state changed: stopped (6) lines 1057-1080/1080 (END) WORKAROUND 1. Select the VPN connection in the "Connections - System Settings Module" window (open it by clicking the top right button in the widget) 2. Click the "Advanced..." button 3. Click the "OK" button in the new window 4. Click the "OK" or "Apply" button in the "Connections - System Settings Module" window WORKAROUND RESULT Now you can connect to the VPN server through the VPN connection in the widget. The workaround procedure clearly overwrites faulty values that were written during the importing of data values from the config file. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #53 from Arash B <ara...@gmail.com> --- 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 out time and time again but been met by comments such as "Please don't add further 'me too'.". The tone of my comment is a result of seeing this thread that spans six years and understanding the lack of computer human interface design knowledge in the design of KDE, something that plagues me in my day to day work. If you want to use that as an excuse to not fix this problem for another few years then please be my guest. You clearly know how to proceed to achieve that. I seriously came here expecting this to be an unnoticed bug needing reporting. Seeing that it's a "feature" spanning six years and being protected... wow now that was a real eye opener in need of some venting. You can at least have appreciation for me taking time from my Saturday evening to point out this problem that shouldn't have been a problem over half a decade, despite my tone. And if you do not wish to do so then again proceed as you wish. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 --- Comment #51 from Arash B <ara...@gmail.com> --- 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 right click on its entry in the TASK MANAGER, and from the right-click menu you go to "Move to Activity >" and choose whatever you desire. So your rationale that "there won't be an easy way for the the novice user to place a borderless window on all activities" is further incorrect. But heck it was incorrect from the start because right now by the same token there's no "easy" way for the novice user to restrict the borderless window to the current activity only! And the latter mentioned state will be desired much more often by a novice user. Placing windows on all activities by default BREAKS the purpose of using activities! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 274931] Windows with no border (decoration) are visible on all activities
https://bugs.kde.org/show_bug.cgi?id=274931 Arash B <ara...@gmail.com> changed: What|Removed |Added CC||ara...@gmail.com --- Comment #50 from Arash B <ara...@gmail.com> --- "programs like chromium - since there's no border, there is no obvious way of moving them between activities. (alt+f3 menu is not commonly known)" (quote from the commit that Martin Flöser uses as rationale to not fix this problem) Oh my freaking God! Is this the reason why I've endured this plague? So I shouldn't think of this as a bug but is actually supposed to be a kind and benelovent **coughing coughing** feature that I should be grateful for? You place the borderless window in ALL activities because you're being so considerate and kind towards the novice user since they won't otherwise know how to place the window in all activities by themselves? Did it every freaking occur to you that the same user will by the same reason be clueless as to how restrict the window to only the current activity!?!?!? If that novice user won't know how to place the borderless window in all activities since the window border isn't there, then how how do you freaking suppose he will be able to restrict the window to only the current activity when you are being so smart as to splash it over all activities? Do you know anything at all about computer human interface design?? Like anything at all, or are you just working at random!?! If you know some then you should know that one of the holy grails of this topic is FREAKING USER EXPECTED SYSTEM BEHAVIOUR and that you DO NOT mess with this unless you have an extremely good reason, something which you have clearly lacked for the last six years since you were as kind to introduce this nice "feature". What is the user's expectation of system behaviour when he opens a borderless window/app? It is that the window/app should be placed in the CURRENT ACTIVITY only! Why is this the correct answer? Because this is the DEFAULT BEHAVIOUR when the user opens a window/app that has a border! Since a window/app with a border is placed in the current activity, and since 99.999% of all windows/apps that the user opens have a border (and this applies especially to novice users), this makes the user's expected system behaviour to be that ALL windows/apps are placed in the current activity where they were opened! How much more clearly does this have to be stated? -- You are receiving this mail because: You are watching all bug changes.
