[kwin] [Bug 485266] Feature Request/Question
https://bugs.kde.org/show_bug.cgi?id=485266 --- Comment #2 from LinG --- Cool, thank you for the explanation. Then based on your description, name is unique enough for my use case. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485267] New: Window output readonly
https://bugs.kde.org/show_bug.cgi?id=485267 Bug ID: 485267 Summary: Window output readonly Classification: Plasma Product: kwin Version: master Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- SUMMARY The output property of the window class is readonly https://invent.kde.org/plasma/kwin/-/blob/master/src/window.h#L109 . However there is a method to change this property on the workspacewrapper https://invent.kde.org/plasma/kwin/-/blob/master/src/scripting/workspace_wrapper.h?ref_type=heads#L370 it would be nicer if the api just allowed setting the output property on the window class instead of having to use this wrapper method. Side note: this workspace wrapper still has a lot of "client" everywhere, whereas the rest of the code base seems to have shifted from "client" in KWin 5 to "window" in KWin 6 (at least from my experience from what I've seen). So for consistency purposes it would be nice to rename all references to client in this file to window as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485266] New: Feature Request/Question
https://bugs.kde.org/show_bug.cgi?id=485266 Bug ID: 485266 Summary: Feature Request/Question Classification: Plasma Product: kwin Version: master Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- VirtualDesktop provides a unique identifier https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktops.h?ref_type=heads#L37 However Output does not? I assumed that the `serialNumber` property was unique but apparently it is not. I'm now assuming the `name` property https://invent.kde.org/plasma/kwin/-/blob/master/src/core/output.h?ref_type=heads#L136 to be unique, is that a correct assumption? If not then I would suggest to implement a unique identifier to the Output class for KWin scripting purposes in a similar fashion as VirtualDesktop provides. This allows Scripting developers to more easily distinguish between Outputs and find them back later again. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #17 from LinG --- I am currently not running Kate for my dev work, so I don't have it installed anymore. However, if I do in the future start using Kate again, then I can always file a new report if the problem still persists. Probably best to close this issue for now, unless someone else wants to test this. Thank you for taking the time to reply to this old issue. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 452154] New: File xfer with kdeconnect starts fatal plasmashell memory consumption
https://bugs.kde.org/show_bug.cgi?id=452154 Bug ID: 452154 Summary: File xfer with kdeconnect starts fatal plasmashell memory consumption Product: kdeconnect Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: jsl4...@gmail.com Target Milestone: --- SUMMARY Plasmashell will begin to rapidly consume all available memory until system lock-up. (32GB w/ no swap enabled). This seems to immediately follow file manipulation between my phone using Dolphin and kdeconnect. For instance, copying photos from my phone to local storage on the computer. STEPS TO REPRODUCE 1. Copy files from android device to desktop using kdeconnect via Dolphin OBSERVED RESULT The plasmashell process will then begin to consume all available memory until crash. Killing the kdeconnect process will halt the memory consumption, but not release the consumed memory. EXPECTED RESULT File xfer with kdeconnect should not initiate plasmashell to consume all available resources SOFTWARE/OS VERSIONS Operating System: Arch Linux kdeconnect Version 21.12.3-1 Dolphin Version 21.12.3-1 Android kdeconnect Version 1.19.1 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.32-1-lts (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 431020] New: kdeconnect-sms crashes when accessing a group SMS chat
https://bugs.kde.org/show_bug.cgi?id=431020 Bug ID: 431020 Summary: kdeconnect-sms crashes when accessing a group SMS chat Product: kdeconnect Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: messaging-application Assignee: si...@ergotech.com Reporter: jsl4...@gmail.com Target Milestone: --- SUMMARY kdeconnect-sms works as expected for two party messaging. Attempts to interact with a group SMS chat (4 members) produce a segmentation fault and kdeconnect-sms will crash. STEPS TO REPRODUCE 1. Select SMS Messages from the menu 2. Select a group conversation to interact with 3. Attempt to interact through the group SMS chat OBSERVED RESULT kdeconnect-sms will invariably seg fault EXPECTED RESULT kdeconnect-sms will allow browsing and replies to a group SMS message chat SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Thread 1 "kdeconnect-sms" received signal SIGSEGV, Segmentation fault. 0x55569e85 in ?? () (gdb) backtrace #0 0x55569e85 in ?? () #1 0x5556a8ed in ?? () #2 0x7643de10 in ?? () from /usr/lib/libQt5Core.so.5 #3 0x77f84ba1 in ?? () from /usr/lib/libkdeconnectinterfaces.so.20 #4 0x77f85063 in ?? () from /usr/lib/libkdeconnectinterfaces.so.20 #5 0x771f4066 in ?? () from /usr/lib/libQt5DBus.so.5 #6 0x76433582 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #7 0x773b3752 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #8 0x76406a7a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #9 0x76409573 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #10 0x764600a4 in ?? () from /usr/lib/libQt5Core.so.5 #11 0x74e47a84 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #12 0x74e9b9b1 in ?? () from /usr/lib/libglib-2.0.so.0 #13 0x74e462b1 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #14 0x7645f6e1 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5 #15 0x764053fc in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5 #16 0x7640d894 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #17 0x5556014e in ?? () #18 0x75dd1152 in __libc_start_main () from /usr/lib/libc.so.6 #19 0x5556062e in _start () -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 LinG changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #15 from LinG --- Added info in previous comment -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429595] New: client.activitiesChanged signal triggered when desktop in menu changed to same desktop
https://bugs.kde.org/show_bug.cgi?id=429595
Bug ID: 429595
Summary: client.activitiesChanged signal triggered when desktop
in menu changed to same desktop
Product: kwin
Version: unspecified
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: scripting
Assignee: kwin-bugs-n...@kde.org
Reporter: lingtj...@hotmail.com
Target Milestone: ---
SUMMARY
When I change the desktop a client resides on to the one it's already on, using
the menu, that is accessible by the top left icon of the border. An
activitiesChanged signal is triggered instead of a desktopChanged signal (which
is not triggered).
STEPS TO REPRODUCE
1. start konsole
2. run this kwin script, that prints whenever the activitiesChanged signal is
triggered
```
var clients = workspace.clientList();
for (var k in clients) {
var c = clients[k];
if (String(c.resourceName) === 'konsole') {
c.activitiesChanged.connect(function () {
print('activitiesChanged');
});
}
}
```
3. click top left icon in konsole client border
4. move to desktop
5. select the same desktop the client is already on
OBSERVED RESULT
print of the activitiesChanged signal is triggered
EXPECTED RESULT
print of the desktopChanged signal is triggered
SOFTWARE/OS VERSIONS
latest ArchLinux packages
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #13 from LinG --- (I just checked out the kate source code from github and compiled it and am testing by running the kate binary in the bin directory) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #12 from LinG --- It doesn't even enter this method. I tried to std::cout the numTargets int but it never printed to the terminal, then I put a std::cout before the cg.readEntry in this function but it never printed that either I then grepped the method and I guessed the katepluginmanager.cpp to handle this in line 126 where it does interface->readSessionConfig(group) I put a std::cout before the if (auto interface = qobject_cast ...blablabla...) and a std::cout after this if statement, and I see the one before the if statement printed 9 times whereas the one inside the if statement that's supposed to call the readSession called 0 times. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #10 from LinG --- Yeah I found it. I did this: 1. start kate 2. change the build plugin command to xelatex %f and name to test 3. close kate 4. open ~/.local/share/kate/sessions/*name* [Plugin:katebuildplugin:MainWindow:0] 0 BuildCmd build=xelatex %f 0 BuildCmd clean=make clean 0 BuildCmd config=cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/local ../ 0 BuildPath= 0 Target=Test 0 Target Default= 0 Target Names=build,clean,config Active Target Command=0 Active Target Index=0 NumTargets=1 Show Marks=false 5. start kate 6. build plugin information is reset again to default 7. close kate 8. open ~/.local/share/kate/sessions/*name* [Plugin:katebuildplugin:MainWindow:0] 0 BuildCmd build=make 0 BuildCmd clean=make clean 0 BuildCmd config=cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/local ../ 0 BuildPath= 0 Target=Target Set 0 Target Default= 0 Target Names=build,clean,config Active Target Command=0 Active Target Index=0 NumTargets=1 Show Marks=false So it seems like the data from the session is not loaded correctly at startup and it loads the default, and then when I close kate, then those default setting are written back to the session file -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #7 from LinG --- Yes, but they all disappear and return tot the default values, once I close Kate and start it up again. Where does kate save this build plugin information (so I can check if it's in there while kate is still open)? Also, all the settings of the external plugins save/load fine between closing and restarting. So I put my build commands in the external tools for now... but I would like to use the build plugin to define multiple targets (C++, LaTeX, VueJS, etc...) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #8 from LinG --- (It's a new laptop, that I just received last week and just installed Arch Linux on, so it's a fresh install with barely any history in it (1 week of history max) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #5 from LinG --- Created attachment 133354 --> https://bugs.kde.org/attachment.cgi?id=133354=edit full debug log I turned on all debugging in kdebugsettings and wrote the output to this log file. I then did these steps: 1. open kate with a file from terminal `kate catering.tex` 2. open build plugin bottom window and add a debug with name XeLaTeX, then change the default build command from `make` to `xelatex %f` 3. build once 4. save session as `new test` 5. close kate 6. start kate again (not in this log file) and observe de default build configuration -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #3 from LinG --- Created attachment 133259 --> https://bugs.kde.org/attachment.cgi?id=133259=edit kate_build_plugin.mp4 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 --- Comment #2 from LinG --- I tried it with a session as well and it didn't work either. I attached a recording -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 428989] New: When are build plugin settings saved, if at all?
https://bugs.kde.org/show_bug.cgi?id=428989 Bug ID: 428989 Summary: When are build plugin settings saved, if at all? Product: kate Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- SUMMARY I'm trying to use the build plugin to compile my LaTeX documents. It works fine, but whenever I close Kate and start it up again I lose all my build targets that I configured STEPS TO REPRODUCE 1. Enable build plugin 2. open build output section (bottom) 3. go to target settings tab 4. add a new target 5. change the build command from the default (make) to xelatex %f 6. close kate 7. open kate 8. open build output section (bottom) 9. go to target settings tab OBSERVED RESULT Build targets are all reset to default EXPECTED RESULT My custom build targets are saved when kate is closed SOFTWARE/OS VERSIONS Latest ArchLinux packages ADDITIONAL INFORMATION I tried to add the custom build targets in a kate session, but that didn't save and restore the custom build targets either when re-opening kate -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 401025] Focus loss on menu entry `Bookmarks` and set to main window
https://bugs.kde.org/show_bug.cgi?id=401025 --- Comment #3 from LinG --- I just tried it and it seems to have been fixed, the bookmark entry is passed by normally and I can also enter it normally. Thanks for looking into it :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 426988] New: Client unresponsive when geometry changes if both signals are connected
https://bugs.kde.org/show_bug.cgi?id=426988
Bug ID: 426988
Summary: Client unresponsive when geometry changes if both
signals are connected
Product: kwin
Version: unspecified
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: scripting
Assignee: kwin-bugs-n...@kde.org
Reporter: lingtj...@hotmail.com
Target Milestone: ---
SUMMARY
When you set the same geometry in both the clientStepUserMovedResized and
clientFinishedUserMovedResized signals the client becomes unresponsive until
you can force a new geometry, such as by changing the border property (it feels
like a deadlock, because CPU usage does not go up, it's just no longer takes
input)
STEPS TO REPRODUCE
1. open a konsole application
2. run this small kwin script that illustrates the problem, this example
connects both client geometry change signals to a running konsole application
and forces a certain geometry (100,100, 200, 400)
```
var clients = workspace.clientList();
for (var i = 0; i < clients.length; i++) {
var client = clients[i];
if (client && client.resourceClass.toString() === 'konsole')
{
client.clientStepUserMovedResized.connect(function(c){
c.geometry = {
x: 100,
y: 100,
width: 200,
height:400
};
});
client.clientFinishUserMovedResized.connect(function(c)
{
c.geometry = {
x: 100,
y: 100,
width: 200,
height:400
};
});
}
}
```
3. resize the konsole application by dragging one of the borders
OBSERVED RESULT
client becomes unresponsive to input
EXPECTED RESULT
client should be responsive to input
SOFTWARE/OS VERSIONS
latest archlinux packages (Plasma 5.19.5/Framework 5.74.0 at the time of
writing this report)
ADDITIONAL INFORMATION
If you comment one of the two signals then it works fine and the client doesn't
become unresponsive.
I remember in older versions of KWin, this would result in weird visual
artificats, this is now resolved but now the client becomes unresponsive.
Origin of report: https://github.com/lingtjien/Grid-Tiling-Kwin/issues/83
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 416093] client screen property now readonly?
https://bugs.kde.org/show_bug.cgi?id=416093 --- Comment #12 from LinG --- (In reply to Vlad Zahorodnii from comment #11) > (In reply to LinG from comment #10) > > Alright, where can I find the most recent documentation about the methods > > and properties that I should use? > Unfortunately, only source code. API dox is not generated for KWin since KDE > Plasma 5. Alright, could you point out to me where I can find the code that is related to the KWin::client and KWin::toplevel (assuming client still inherits from toplevel as in 4.9). The scripting/workspace_wrapper.h is very readable so I'm fine with working with that but I didn't find a client_wrapper.h or something in this directory -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416093] client screen property now readonly?
https://bugs.kde.org/show_bug.cgi?id=416093 --- Comment #10 from LinG --- (In reply to Vlad Zahorodnii from comment #8) > (In reply to LinG from comment #7) > > I've always used this screen property of the client the same way as I have > > been using the desktop property and am still using. So it's interesting to > > me that you say that this property has never been writable. > You shouldn't actually use that property, it's deprecated. Alright, where can I find the most recent documentation about the methods and properties that I should use? (What method should I use to send clients to different desktops and is there also something available to send clients to different activities?) > > > Question 1: What would be the reason to not make the screen property > > writable like the desktop property on a client? I'm fine with using your > > proposed method as well, but isn't the former more in line with the rest of > > the API? > It matches what KWin is doing whenever it needs to send a client to another > screen. That's fair, keeping the API as close to the internals seems like the best way to me as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416093] client screen property now readonly?
https://bugs.kde.org/show_bug.cgi?id=416093 --- Comment #7 from LinG --- (In reply to Vlad Zahorodnii from comment #3) > (In reply to LinG from comment #0) > > The screen property of a client is now readonly? I'm pretty sure it used to > > be read and write, thus allowing me to change the screen on which a client > > resides but now I can't? How do I change the screen on which a client > > resides through the scripting API now? > As far as I know, it has always been read-only. I've always used this screen property of the client the same way as I have been using the desktop property and am still using. So it's interesting to me that you say that this property has never been writable. Question 1: What would be the reason to not make the screen property writable like the desktop property on a client? I'm fine with using your proposed method as well, but isn't the former more in line with the rest of the API? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416093] client screen property now readonly?
https://bugs.kde.org/show_bug.cgi?id=416093
--- Comment #1 from LinG ---
Here is a MWE
var clients = workspace.clientList();
for (var i = 0; i < clients.length; i++)
{
if (clients[i] === null) {continue;}
if (clients[i].resourceName.toString() === 'konsole') // or any other client
that you have open
{
var pre = clients[i].screen;
clients[i].screen = 1;
var post = clients[i].screen;
print(pre, post, workspace.numScreens); // output: 0 0 2, expected output 0
1 2
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 416093] New: client screen property now readonly?
https://bugs.kde.org/show_bug.cgi?id=416093 Bug ID: 416093 Summary: client screen property now readonly? Product: kwin Version: 5.17.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- The screen property of a client is now readonly? I'm pretty sure it used to be read and write, thus allowing me to change the screen on which a client resides but now I can't? How do I change the screen on which a client resides through the scripting API now? Additional question regarding the documentation (https://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9): the desktop property has the description to prefer the use of `isOnDesktop()` method over accessing this variable directly, however this method is not documented in the kwin scripting documentation. Latest packages on ArchLinux -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kpackage] [Bug 386509] No Settings Icon
https://bugs.kde.org/show_bug.cgi?id=386509 LinG changed: What|Removed |Added Component|libplasma |default Version|5.39.0 |5.55.0 Product|frameworks-plasma |frameworks-kpackage --- Comment #2 from LinG --- This problem also exists with `kpackagetool5` just as with `plasmapkg2` -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 403172] client geometry can not be changed in desktopPresenceChanged callback when using the action menu or virtual desktop grid view
https://bugs.kde.org/show_bug.cgi?id=403172 --- Comment #4 from LinG --- `qdbus org.kde.KWin /KWin supportInformation` ``` KWin Support Information: The following information should be used when requesting support on e.g. http://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like http://paste.kde.org instead of pasting into support threads. == Version === KWin version: 5.14.5 Qt Version: 5.12.0 Qt compile version: 5.12.0 XCB compile version: 1.13.1 Operation Mode: X11 only Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 12003000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0 decorationButtonsRight: 3, 4, 5 borderSize: 0 gridUnit: 10 font: Noto Sans,10,-1,5,50,0,0,0,0,0,Regular smallSpacing: 2 largeSpacing: 10 Platform == Name: KWin::X11StandalonePlatform Options === focusPolicy: 1 nextFocusPrefersMouse: true clickRaise: true autoRaise: false autoRaiseInterval: 750 delayFocusInterval: 300 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5015 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777250 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 glSmoothScale: 0 xrenderSmoothScale: false maxFpsInterval: 1666 refreshRate: 0 vBlankTime: 600 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 0 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Multi-Head: no Active screen follows mouse: no Number of Screens: 1 Screen 0: - Name: eDP-1-1 Geometry: 0,0,1920x1080 Scale: 1 Refresh Rate: 59.9339 Compositing === Compositing is active Compositing Type: OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 940MX/PCIe/SSE2 OpenGL version string: 3.1.0 NVIDIA 415.25 OpenGL platform interface: GLX OpenGL shading language version string: 1.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 415.25 GPU class: Unknown OpenGL version: 3.1 GLSL version: 1.40 X server version: 1.20.3 Linux kernel version: 4.20.1 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --- kwin4_effect_maximize kwin4_effect_dialogparent zoom kwin4_effect_frozenapp kwin4_effect_logout kwin4_effect_morphingpopups kwin4_effect_fade kwin4_effect_fadedesktop kwin4_effect_login kwin4_effect_translucency kwin4_effect_windowaperture slidingpopups screenshot desktopgrid colorpicker presentwindows highlightwindow blur startupfeedback screenedge kscreen Currently Active Effects: - blur Effect Settings: kwin4_effect_maximize: kwin4_effect_dialogparent: zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 kwin4_effect_frozenapp: kwin4_effect_logout: kwin4_effect_morphingpopups: kwin4_effect_fade
[kwin] [Bug 403172] client geometry can not be changed in desktopPresenceChanged callback when using the action menu or virtual desktop grid view
https://bugs.kde.org/show_bug.cgi?id=403172 --- Comment #2 from LinG --- Interesting, I assumed that they would use the same call to send the client to a different virtual desktop (Workspace::sendClientToDesktop()) but then only add an additional call in case 5c where you call a method to change the current virtual desktop. I can only give you my point of view as an API consumer, but it seems inconsistent to me that connecting to the same signal sometimes does and sometimes doesn't allow changing the geometry of the client. Especially since changing any of the other properties such as opacity is picked up by KWin without a problem. As far as I'm aware, the geometry is currently the only client property that can't be changed when the desktopPresenceChanged(KWin::Client *client, int desktop) signal is invoked in cases 5a/b. In my personal opinion, it would be better if the API did allow changing the geometry in case 5a/b since they are all handled by the same signal from an API consumers point of perspective. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 403172] New: client geometry can not be changed in desktopPresenceChanged callback when using the action menu or virtual desktop grid view
https://bugs.kde.org/show_bug.cgi?id=403172
Bug ID: 403172
Summary: client geometry can not be changed in
desktopPresenceChanged callback when using the action
menu or virtual desktop grid view
Product: kwin
Version: 5.14.5
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: scripting
Assignee: kwin-bugs-n...@kde.org
Reporter: lingtj...@hotmail.com
Target Milestone: ---
SUMMARY
desktopPresenceChanged(KWin::Client *client, int desktop) signal does not allow
changing the client geometry when using the action menu or by dragging the
client between virtual desktops in virtual desktop grid view but it does work
correctly when moving clients between virtual desktops using global shortcuts.
STEPS TO REPRODUCE
1. open WM console
2. run this small demonstration script
```
workspace.desktopPresenceChanged.connect (function (client)
{
print('current geometry: x=' + client.geometry.x + ', y=' + client.geometry.y
+ ', width=' + client.geometry.width + ', height=' + client.geometry.height);
var geometry = {x: 100, y: 100, width: 200, height: 200};
client.geometry = geometry;
client.opacity = 0.8;
});
```
3. open a terminal
4. resize and move the terminal such that it's x, y, width and height are not
100, 100, 200 and 200
5a. move the terminal to a different virtual desktop by opening the action menu
(default top left corner) and selecting `move to desktop` and move it to any
other virtual desktop
DIFFERENT SCENARIOS
5b. move the terminal to a different virtual desktop by opening the virtual
desktop grid view (default shortcut Ctrl+F8) and then dragging the client to a
different virtual desktop
5c. move the terminal to a different virtual desktop by using any of the global
shortcuts such as `Switch one desktop down`
OBSERVED RESULT
1. if you do step 5a or step 5b you will see that the client does accept the
opacity parameter and takes on an opacity of 0.8 but it does not accept the
geometry of 100, 100, 200, 200
2. if you do step 5c instead of 5a or 5b you will see that the client correctly
accepts the geometry of 100, 100, 200, 200
EXPECTED RESULT
1. expect the client to accept the new geometry supplied just like the opacity
but it ignores the geometry when moving clients between virtual desktops using
the action menu or virtual desktop grid view
SOFTWARE/OS VERSIONS
latest ArchLinux packages
--
You are receiving this mail because:
You are watching all bug changes.
[kded-appmenu] [Bug 401109] New: GTK global menu shortcut not working
https://bugs.kde.org/show_bug.cgi?id=401109 Bug ID: 401109 Summary: GTK global menu shortcut not working Product: kded-appmenu Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: top menubar Assignee: plasma-b...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. set the keyboard shortcut of the global menu widget to something (such as `Meta+Tab`) 2. open a GTK application (such as GIMP) with global menu enabled 3. press keyboard shortcut OBSERVED RESULT global menu is not activated an opened EXPECTED RESULT global menu should open and put the focus on it as with normal KDE applications. SOFTWARE/OS VERSIONS Latest Archlinux packages -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 401025] Focus loss on menu entry `Bookmarks` and set to main window
https://bugs.kde.org/show_bug.cgi?id=401025 LinG changed: What|Removed |Added Summary|Focus loss on menu and set |Focus loss on menu entry |to main window |`Bookmarks` and set to main ||window -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 401025] New: Focus loss on menu and set to main window
https://bugs.kde.org/show_bug.cgi?id=401025 Bug ID: 401025 Summary: Focus loss on menu and set to main window Product: kate Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. open kate with global menus active 2. active the global menu 3. go from left to right through the items starting from `File` all the way to `Help` OBSERVED RESULT As you pass the menu item `Bookmarks` the menu closes and the focus returns to the kate main window. The `Bookmarks` entry seems to be empty on my system also EXPECTED RESULT That the focus stays on the menu and that you can move all the way from the entry `File` to `Help` but now you can only move from `File` to `Projects` and then if you want to access the other items by keyboard you have to manually select the `Sessions` entry and then you can use the arrow_right key to navigate to the right to the `help` entry. SOFTWARE/OS VERSIONS Latest packages on Archlinux -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 397397] New: No access to the client that changed desktop in KWin::Client.desktopChanged() signal
https://bugs.kde.org/show_bug.cgi?id=397397 Bug ID: 397397 Summary: No access to the client that changed desktop in KWin::Client.desktopChanged() signal Product: kwin Version: 5.13.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- I'm trying to let my script hook into the default KWin methods to change client desktops but I can't seem to get access to the client that is changing its desktop. The API describes for the KWin::Client object the desktopChanged() signal without arguments whereas I would expect it to be similar to any of the other signals such as clientStartUserMovedResized(KWin::Client *) which gives the user access to the client that changed by its argument. I tried to get access to the client that switches desktop using the active client (workspace.activeClient) but this return null in this method. I'm not sure if this is intended behavior or if it's a bug, but either way I would like to get access to the client which had its desktop property changed. How do I do this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 397397] No access to the client that changed desktop in KWin::Client.desktopChanged() signal
https://bugs.kde.org/show_bug.cgi?id=397397
--- Comment #2 from LinG ---
Yes, I understand that at the moment when I'm connecting to the signal I have
access to the client, but I don't understand how I get access to the client
inside the callback method that I provide for when the signal gets triggered.
My current understanding is:
```
client.desktopChanged.connect(function () {
// how do I get the client inside this callback?
})
```
Here I provide a method (callback/lambda) that gets triggered whenever the
desktop of this client changes.
The gap in my knowledge is then, how I would get access to the client inside
this callback?
You refer to capturing the client in this lambda, could you please give a small
example of how I would go about doing this?
--
You are receiving this mail because:
You are watching all bug changes.
[latte-dock] [Bug 396751] New: Global shortcut new instance for entry 9 missing
https://bugs.kde.org/show_bug.cgi?id=396751 Bug ID: 396751 Summary: Global shortcut new instance for entry 9 missing Product: latte-dock Version: 0.8.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: lingtj...@hotmail.com Target Milestone: --- I seem to be missing a global shortcut in the latte global shortcuts section. I have all the shortcuts ranging from: `new instance for entry` 1 till 19 but I don't have one for entry 9, I do have an `active entry 9` shortcut but not one to create a new instance I tried to kill latte and then delete the shortcuts to reset them to default when I started latte up again, but that didn't solve it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392840] Can't seem to use print() multiple times
https://bugs.kde.org/show_bug.cgi?id=392840 --- Comment #8 from LinG <lingtj...@hotmail.com> --- Ah okay, so it seems to be purely a console thing. Btw I've only ever used the "wm console" to write my kwin scripts, could you explain to me how to use and set this "KDebugSettings" variable? That would make my kwin scripting a lot easier for now as long as this bug exists. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392840] Can't seem to use print() multiple times
https://bugs.kde.org/show_bug.cgi?id=392840 --- Comment #5 from LinG <lingtj...@hotmail.com> --- you can test that you are not on "kwin" because you can't use the global `workspace` for example if you try this, when you first open the console: print(workspace.desktopGridWidth); but if you switch to "plasma" and back to "kwin" then you access to these globals. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392840] Can't seem to use print() multiple times
https://bugs.kde.org/show_bug.cgi?id=392840 --- Comment #4 from LinG <lingtj...@hotmail.com> --- That's because of a different bug (which I should probably report as well...). But if you open "WM console" it shows the default state as "kwin" but it's actually on "plasma" because you don't have access to some of the kwin globals. You need to manually switch to "plasma" and then back to "kwin" to actually be able to run the script as a kwin script. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392840] Can't seem to use print() multiple times
https://bugs.kde.org/show_bug.cgi?id=392840
--- Comment #2 from LinG <lingtj...@hotmail.com> ---
just javascript, everything works fine when I only use the print() method once.
But when I start to use the print() method multiple times in quick succession
then it won't print() some of the print() methods. When I use the "plasma"
option to execute the script it will print both but when I use the "kwin"
option it will skip some print() statements.
It seems to depend on how long kwin is busy with executing the commands between
the consecutive print statements.
for example, if I put a long loop between the two print() statements then both
will execute, like this example:
print('hi');
var a = 0;
for (var i = 0 ; i < 1000; i++)
{
a += i;
}
print('hihi');
but doing only:
print('hi');
print('hihi');
seems to be too fast and kwin will not print the second statement to console.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 392840] New: Can't seem to use print() multiple times
https://bugs.kde.org/show_bug.cgi?id=392840
Bug ID: 392840
Summary: Can't seem to use print() multiple times
Product: kwin
Version: 5.12.4
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: scripting
Assignee: kwin-bugs-n...@kde.org
Reporter: lingtj...@hotmail.com
Target Milestone: ---
When trying to use the print() method multiple times in a kwin script using the
wm console only the first print() statement is printed to the console.
example:
script:
print("hi")
print("hihi")
output:
hi
expected output:
hi
hihi
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 386509] New: No Settings Icon
https://bugs.kde.org/show_bug.cgi?id=386509 Bug ID: 386509 Summary: No Settings Icon Product: kwin Version: 5.11.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- When I install a kwin script using: plasmapkg2 --type kwinscript -i test It works fine but for some reason I don't get the gear icon that allows to interact with the ui. To reproduce: 1. copy the default videowall kwin script that is located here /usr/share/kwin/scripts/videowall to somewhere 2. rename all the names (Name, X-KDE-PluginInfo-Name, X-KDE-PluginKeyword and X-KDE-ParentComponents) inside metadata.desktop to something else such as "test" 3. install the test package using: plasmapkg2 --type kwinscript -i "name" 4. open kwin scripts and observe that there is no gear icon for the test script while the default videowall script does have a gear icon. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 386148] New: Can not apply gtk theme
https://bugs.kde.org/show_bug.cgi?id=386148 Bug ID: 386148 Summary: Can not apply gtk theme Product: systemsettings Version: 5.11.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_gtk Assignee: aleix...@gmail.com Reporter: lingtj...@hotmail.com Target Milestone: --- When I try to adjust the gtk2 theme and I click apply afterward. If I then restart system settings the themes in gtk2 and gtk3 are back to default. (had the same behavior also for gtk2 and gtk3 on KDE Neon on a different machine) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of applications consistently inside clientAdded() signal
https://bugs.kde.org/show_bug.cgi?id=386021 --- Comment #9 from LinG <lingtj...@hotmail.com> --- I've taken a look at those at first but they did not satisfy my needs. Regardless of that, don't you think that a window manager API that is not able to change the geometry of applications that are started kinda defeats the purpose of a "window manager"? Basically, one of the simplest things one could do is: - Set the geometry of an application that is started to some geometry But right now that only works for a handful of applications that don't set their own geometry... Feels like I don't even have control of my own window manager... (If only there was a "force" option...) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of applications consistently inside clientAdded() signal
https://bugs.kde.org/show_bug.cgi?id=386021 --- Comment #7 from LinG <lingtj...@hotmail.com> --- my main problem is that you're basically setting up default settings for the application in kwin and then you pray to god the application does not define its own settings which override your default settings. A more expected behavior would be that you let the application decide on the default behavior and then you can adjust these settings using kwin. (settings = geometries, minimized, etc...) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of applications consistently inside clientAdded() signal
https://bugs.kde.org/show_bug.cgi?id=386021 LinG <lingtj...@hotmail.com> changed: What|Removed |Added Summary|Can not adjust the geometry |Can not adjust the geometry |of Kate |of applications ||consistently inside ||clientAdded() signal -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of Kate
https://bugs.kde.org/show_bug.cgi?id=386021 --- Comment #6 from LinG <lingtj...@hotmail.com> --- Or is there a way to call clientAdded() after the application has started up instead of before? Right now it goes: - apply settings in kwin - startup application -> applies settings from applications result = applied settings in kwin are overwritten by application itself Shouldn't it be? - startup application -> applies settings from applications - apply settings in kwin -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of Kate
https://bugs.kde.org/show_bug.cgi?id=386021 --- Comment #5 from LinG <lingtj...@hotmail.com> --- Also the workspace.getClient() function does not work for newly added clients until the workspace.clientAdded() routine is finished, the client is not added internally to the workspace. Which means that kwin does not manage newly added applications yet until they are started up? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of Kate
https://bugs.kde.org/show_bug.cgi?id=386021 --- Comment #4 from LinG <lingtj...@hotmail.com> --- that was intentional in this example, if I had not done that and the second script would work (which it doesn't) then you would not notice a difference in the geometries. Anyways, while trying out other applications I noticed that kate is by far not the only application that does not listen to the settings that you apply (spotify, inkscape, etc...) My observation is that whatever you do inside the workspace.clientAdded function does not always work, for a lot of applications they just ignore whatever you tell them to do and create a geometry set by the application. This only happends during the startup of the application once it has already been started up you can do whatever you want with the geometry using the API that kwin provides. Shouldn't the clientAdded function overrule whatever the application itself tries to achieve in terms of geometry and what not? Right now creating a Kwin script that manages my newly added applications *consistently* is simply impossible because most applications have their own predefined geometries. Or is there a way to force the applications to adjust to the settings you apply to it, that I'm unaware of? -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 386031] New: Can not adjust the geometry of Kate on startup
https://bugs.kde.org/show_bug.cgi?id=386031 Bug ID: 386031 Summary: Can not adjust the geometry of Kate on startup Product: kate Version: 17.08.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- see: https://bugs.kde.org/show_bug.cgi?id=386021 explanation -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386021] Can not adjust the geometry of Kate
https://bugs.kde.org/show_bug.cgi?id=386021
--- Comment #2 from LinG <lingtj...@hotmail.com> ---
But there are two different scenarios in which the application behaves
differently. Allow me to provide two small examples which illustrate what I'm
experiencing to be weird
case 1.
- open application: kate
- execute this piece of code in Kwin
var clients = workspace.clientList();
for (var i=0; i<clients.length; i++) {
if (clients[i].resourceClass.toString() === "kate") {kate = clients[i];};
}
kate.geometry = {x: 5, y: 100, width: 400, height: 800};
- succes, kate now takes on this geometry
case 2.
- close application: kate
- execute this piece of code
workspace.clientAdded.connect
(
function(client)
{
client.geometry = {x: 100, y: 5, width: 800, height: 400};
return 0;
}
);
- open application: kate
- fail, kate takes on some random geometry
I don't understand why these two cases generate different results, but as you
said this may be kate related... In which case I report it in the kate section
I suppose? (Just checking to be sure that it is kate related and not kwin.)
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 386021] New: Can not adjust the geometry of Kate
https://bugs.kde.org/show_bug.cgi?id=386021 Bug ID: 386021 Summary: Can not adjust the geometry of Kate Product: kwin Version: 5.11.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: lingtj...@hotmail.com Target Milestone: --- Using the kwin scripting interface, I can change the client.geometry property of Kate and if I check the geometry afterward it has been correctly set. But for some reason Kate does not want to take on the new geometry you assign to it. It works fine for every other application I use (from konsole to texstudio etc...) only for Kate is it not possible to let it take on the new geometry that you assign to it. -- You are receiving this mail because: You are watching all bug changes.
